The Section 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 Section applies caching, optimization, and security rules to the site. The Section platform handles this by using multiple branches within a single git repository per site, i.e. Section Application.
Let’s use www.example.com and Varnish Cache as a demonstration. Typically, you start with a Section Application for www.example.com 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 Section Console ‘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 Section 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 Section Console 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 Section.
With your Staging site now live on Section, your team can test how your new features in Staging will work with Section 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 Section 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 Section configuration changes from the Section Staging environment to the Section Production environment.
Promoting changes across branches in Section 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 Section Application, you will find the git clone command on the Developer PoP page in the Section Console. It will something similar to:
git clone https://aperture.section.io/account/1/application/1/www.example.com.git
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 Section 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 Section platform, you can push with this command:
git push origin Production
Within moments your Section 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.
