Continuous Integration! A process that can cause table-flipping levels of frustration, catch critical errors before code makes it to any environment, and make non-developer eyes glaze over when an engineer is lamenting about mismatches in NodeJS versions. The TAG Engineering Team recently made some operational improvements to our continuous integration (CI) workflow on Pantheon, but before we dive into what we did we should establish a baseline of the role of CI in a web software development agency.
Here’s how Amazon Web Services defines Continuous Integration:
Continuous integration most often refers to the build or integration stage of the software release process and entails both an automation component (e.g. a CI or build service) and a cultural component (e.g. learning to integrate frequently).
So the TL;DR on CI is that it’s a series of scripts and build steps to make sure things don’t break before they get to prod (or even dev). For example, a CI script may alert a developer that something has gone horribly wrong. In this example screenshot, the CI build failed because I failed to include an `npm install` in our build process before running a build script.
Whoops! But without CI this build would have brought down our dev server. As TAG Engineers, our “Own It” value means that we are responsible for “our words, actions, and results.” This applies to code too! So CI is a way for us to make sure we’re accountable for our code and that we’re protecting our websites from crashing, even when we make mistakes (and we all make mistakes).
A New Pantheon Workflow Powered by GitHub Actions
We needed a cleaner way of handling CI and we wanted to make things consistent across all of our Pantheon sites. So we developed a new workflow for Pantheon that leverages GitHub Actions. When we started planning for these workflow updates, we knew that our workflow needed to do the following:
- Create a Pantheon Multidev environment whenever we open a Pull Request.
- Deploy to the Pantheon dev server whenever we merge a PR to a specific branch.
- Deploy to the Pantheon test/live servers whenever we push a tag with a naming convention.
With these goals in mind, we put on our fingerless gloves like all hackers do and got to coding!
Pantheon Prerequisites and GitHub Secrets
For all of this to work, we set up our GitHub repository with a few different GitHub Secrets that we could pass to our GitHub Actions when we needed to deploy to Pantheon. For example, our `multidev_deploy.yml` file contains the following job:
We have a Pantheon Machine Token stored in a GitHub secret so that our actions can do all of the Terminus things we want it to do like deploy code, import Drupal config, and clear caches. We also store the Pantheon git repository info in secrets so we can use it as environment variables for our deploy job:
Then our deploy job pushes our branch to Pantheon git repository, which will trigger a multidev environment creation in Pantheon. And it works! When we create a pull request we create a multidev environment, which allows a developer to independently test their work before we merge into the main trunk of the codebase.
We also set up some rules so that if we tag the codebase with a certain naming convention and push, we’ll deploy code to the test or live environment. Our `test_push.yml` file contains the following specification:
This means if we push a tag with `test.` preprended we’ll get a deployment to the test server. So pushing `test.v1.0` will deploy our 1.0 tag to test. It works perfectly! The same convention is used for live, so everything can be consistent between the environments.
Putting it all together (and adding asset builds)
We’re standardizing on this workflow for all of our Pantheon sites and are also working on similar workflows for other platforms we work with. There are three key takeaways from this effort that we want to highlight:
- Continuous integration is essential for any modern software engineering project. It will help catch (most) errors before they make it to any environment and keep engineers accountable for their code.
- GitHub Actions is a powerful and extensible tool that can support many different CI workflows. If your workflow needs are slightly different, it is very likely that GitHub actions will be able to support it! The tool is less important here: what’s important is the process and how it can increase operational efficiency + team morale.
- Just because a process is something that you’ve “always done” or something that “nobody has the time for” doesn’t mean that it’s worth taking a step back and looking at what you’re actually doing. You may find that investing in CI will end up in a net savings of resources and developer headaches in the long run!
Get in touch to learn more about how Third and Grove can help you with your Pantheon Workflows and make your CI humming with maximum efficiency.
Join our mailing list and you can stay this informed all the time.
Don't be a stranger.
Keep up to date by signing up for our newsletter. It’ll be fun, we promise.