Working with managed hosting platforms is a great way for agencies to stay focused on their core competencies. At Digital Polygon, we leverage managed hosting providers such as Pantheon every day to deliver a higher level of value for our clients. Today I want to talk about git workflows and some ways to handle them on Pantheon's opinionated platform.
How does Pantheon's Git Workflow work?
Pantheon has a unique git workflow as part of its managed hosting offering which enables organizations both large and small to operationalize their development processes. For those not familiar with Pantheon, they provide a 3 tier environment model by default consisting of Dev -> Test -> Live.
Pantheon 3-tier Environment
Behind the scenes, when utilizing the Git workflows, the main Pantheon workflow is controlled by a single "master" branch on the Pantheon git repository system. Any commits pushed up to the Pantheon platform on the master branch are automatically deployed to the dev environment. From there, tags are created and deployed to test/production respectively in order to ensure only approved changes move through the stack.
This workflow works well for many teams and depending on the size of your team and how much active development you are doing, it might be all you need. For larger teams, especially those using a traditional Gitflow workflow, this could be a source of hesitation and frustration. There is good news here! Pantheon can fully support a Gitflow workflow if we leverage its full platform capabilities. Let's dive in a little bit more - first we need to do a quick introduction to Pantheon's multidev environments.
Pantheon Multidev Environments
Pantheon introduced multidev environments over a year ago and they have many use cases for development teams. Here are a few of the ways we have used multidev environments with our clients:
- Multidev environments can be leveraged by teams running Kanban to do feature-based development workflows and on-demand releases.
- Multidev environments can be leveraged by sprint teams looking to use on-demand environments for individual tickets enabling automation and testing right on the Pantheon platform.
- Multidev environments can be leveraged by teams looking to leverage Gitflow workflows on the Pantheon platform.
In this blog, we are going to focus in on #3 here and discuss in more detail how to set up the Multidev environments to run Gitflow.
Pantheon Multidev Setup for a Gitflow workflow
So today we are going to talk about using Multidev to support your development workflow to keep the main Dev -> Test -> Live lane clear for deployments.
The setup:
- Create 2 new Multidev environments:
- dev-build (develop is a protected branch on Pantheon so we cannot use that)
- uat
- Create 2 new branches on your GitHub - dev-build, uat
When you create a new Multidev on Pantheon, it creates a new branch on the Pantheon git repository with the name of that environment. In this case, we just created the dev-build and uat branches on Pantheon to mirror the ones we created in GitHub.
With this setup, we can follow a normal Gitflow workflow against these Multidev environments, and we can use dev-build for our integration environment and uat for our testing environment.
Once the sprint is complete, and the UAT branch is approved - we can merge it to master and execute our deployment/automation on the main dev -> test -> live stack.
Hotfixes Utilizing the Pantheon Multidev Approach
Hotfixes become very simple in this scenario since your dev -> test -> live lane is clear unless you are already moving the approved code through. If you run into a scenario where you need to hotfix an issue or patch a security vulnerability, you can create a new branch off of the master branch which should mirror your production environment. We would still recommend spinning up a new multidev for your hotfix branch and testing before merging into master, but this process does not disrupt your normal sprint operations.
An Alternative Approach without Multidev
Without utilizing Multidev environments, you could still execute hotfixes on the Pantheon environment. This process would require you to tag your deploy commits in your current repository (we recommend doing this anyway as a best practice) or you could pull the tags directly off of Pantheon and work against them (not recommended since our source of truth for our team is GitHub). Pantheon's UI does not give you a visual indicator of what tag is deployed on your environment, but it's pretty safe to say the most recent live tag is what's on your live environment.
Once you have your starting commit, you can create a branch from that and perform your hotfix. Once this is done, you will need to force push your hotfix branch to overwrite the master branch on Pantheon - effectively rewriting the history of that branch to remove all of the in-progress sprint work you have done and replace it with your new fork (production + hotfix). Once you go through your testing, you can move it through the dev -> test -> live workflow.
The downside to this approach is it can have serious impacts on your in-progress sprint work. You will need to hold off on all development integration and testing for your current sprint until the hotfix has made it to production, and then redeploy your current sprint changes and restore or redo any content staging required.
We hope this article has helped you in your journey to get the most out of the Pantheon platform. Managed hosting providers such as Pantheon may be opinionated, but if your teams are open to the possibilities there is usually a way to achieve your goals! Looking for help with your DevOps practice? Contact us today and talk with one of our specialists!