Working with Environment branches

The platform was built with the understanding that changes to sites are often deployed to a series of environments before being deployed to Production. We anticipated that with each set of site changes, there may also be some corresponding changes required to how applies caching, optimization, and security rules to the site. The platform handles this by using multiple branches within a single git repository per site, i.e. Application.

Let’s use and Varnish Cache as a demonstration. Typically, you start with a Application for with a Production branch in the git repository. This branch would initially contain a varnish directory with your Varnish Cache VCL files and a section.config.json file in the repository root with details about the Production origin server.

On the Aperture portal’s Overview page for the Production environment, you will see a Create environment button. Clicking this will prompt you for the name of the new environment and the name this environment domain. For this example, I’ll use “Staging” as the new environment name. Upon clicking Create a new branch named “Staging” is created in the same Application git repository based on the existing “Production” branch. Additionally, the section.config.json file is modified to contain a copy of the Production origin details for your new Staging environment.

At this point, you can edit the Origins page in the Aperture portal to update the Staging configuration to refer to your Staging origin server. Then use the DNS page to find what DNS records you will need to change to make your Staging site use

With your Staging site now live on, your team can test how your new features in Staging will work with in front of it. You may discover, for example, that a new feature page which should be served from cache is not. You can edit the Varnish Cache VCL in your Staging branch to correct this and test that it now works as expected, without any impact on your Production site.

When you have determined that your new Staging origin changes are ready to go to Production, you can follow your usual internal process for deployment and promote your configuration changes from the Staging environment to the Production environment.

Promoting changes across branches in is currently done via client-side git tooling. You may prefer GitHub Desktop, Atlassian Sourcetree, Axosoft Gitkraken, or any of the many other clients. I’m going to use the git command line here since it is universal but your chosen git client may have a simpler equivalent workflow.

If you haven’t already cloned your Application, you will find the git clone command on the Developer PoP page in the Aperture portal. It will something similar to:

git clone

Typically this will have checked out your Production branch by default, which is convenient here since this is the target environment for this example. Just to be sure,though, we can explicitly check out the Production branch with:

git checkout Production

You can then merge all of the changes from the Staging branch into your local Production branch with this command:

git merge origin/Staging

Optionally, if you have setup the Developer Pop locally, you could test these changes against the Production domain and origin in isolation before deploying globally.

When you’re ready to deploy the merged Staging changes to the platform, you can push with this command:

git push origin Production

Within moments your configuration changes, previously tested in Staging, will be applied to your Production site, and your new feature page will be effectively served from cache, and provide a faster experience to your users.

Blog Categories

Interested in articles about a specific topic? Click on a category to see all related content.