Today, we’re happy to have this guest post written by Andrew Taylor, Community Engineer at Pantheon, about their experience migrating to our 2.0 platform. Read on for their tips and takeaways.
I work at Pantheon, a WordPress and Drupal development and hosting platform, where a large part of my role is to help developers take advantage of our platform by creating examples of complex workflows. In February 2016 I started an Advanced WordPress on Pantheon repository with the goal of setting up an enterprise grade WordPress workflow.
The project has source files committed to GitHub, with production versions and dependencies ignored. I needed a way to turn the source code into production code, deploy it to Pantheon and run automated testing. Naturally, I used continuous integration to solve this problem.
I chose CircleCI due to their generous free tier, allowing 1 worker for private projects and 4 workers for open source projects. Since I created a public project this was perfect - I was able to adopt CircleCI for my build, deploy and test steps. A lot has changed since 2016 when I first added CircleCI to my project. I’ve been continually updating the project to add new features and kept a close eye on CircleCI 2.0, which entered beta in late 2016 and was released publicly in July of 2017. Since this project is a framework for WordPress work I recommend using in production, I had been waiting until after the beta period to fully adopt CircleCI 2.0. Now that I’ve been using CircleCI 2.0 for a while, I wanted to share what I’ve learned.
Faster Job Execution
CircleCI 2.0 individual jobs run fast. Really fast. For example, installing Composer dependencies runs in 10 seconds - including the time it takes to initialize the environment. This took some tweaking to achieve, mainly setting up caching properly so that the Composer cache persisted between builds.
With CircleCI 1.0, I was using a lot of conditional statements to do different things inside a single, monolithic job. CircleCI 2.0 Workflows allowed me to create individual jobs for each step. For example, I can install PHP dependencies with Composer in one job and have a completely separate job for compiling front end assets with gulp.
Parallel Job Execution
Not only can I have jobs dedicated to specific tasks, but I can even run them in parallel. This means I can compile front end dependencies with gulp at the same time as another job runs code sniffing and unit tests on PHP. With CircleCI 1.0 I could only do one thing at a time. With CircleCI 2.0 I was only limited by my imagination (and available workers). Jobs can also require other jobs, making sure deployment doesn’t happen before build, for instances where I needed some synchronous tasks.
Conditional Job Execution
With separate jobs and workflows, conditional execution becomes much easier. In CircleCI 1.0 I had a lot of conditional logic at the start of each step, failing if something didn’t go right in the previous step.
With workflows you can simply fail one job in the workflow and any jobs that require the failed job won’t run. You can also hold a workflow for manual approval which is great when you need human intervention, such as stakeholder approval.
With CircleCI 1.0 I had to use an external cron service to trigger jobs via the API if I wanted anything to run on a schedule. Now, with CircleCI 2.0, I can have specific workflows run on a cron natively. This is great for having a separate workflow and jobs for things like backups or updates, which will run while I sleep.
CircleCI 1.0 had artifacts but I never really explored them. As I dug more into CircleCI 2.0 I found artifacts, which are a way to store files after a job runs so they can be accessed later: very useful. They have been great for storing things like test results. Combining that with APIs from other services and now I have test results showing up in my pull requests or reporting back to Slack.
Custom Docker Images
In CircleCI 1.0 I got a base virtual machine and had to install everything the CI process needed on each build. This was a time-consuming process that has been solved with custom Docker images. With CircleCI 2.0 I can create custom Docker images for each job, making the environments my jobs run in as minimal as possible while already having global packages I need, such as gulp for building front end assets, installed. With installation and setup moved to the Docker image for the environment my CircleCI jobs can focus on their tasks rather than handling a bunch of installation and setup on each build.
One of the biggest things that helped me make the transition was the CircleCI 2.0 docs. They are very thorough and well-written. If you plan on trying out CircleCI 2.0 make sure you check out the docs and example projects.
The UI Needs to Catch Up
Workflows are amazing but the CircleCI UI hasn’t kept up. By default it still takes you to the builds summary when logging in or clicking links and you have to manually find your way over to workflows and I’ve seen this confuse folks. Once there though there is a great roll up view of all the jobs in that workflow.
Similar to the UI, pass/fail email alerts are tied to individual jobs, not the whole workflow. If a single job fails I get an email alert. After pushing another commit all the jobs in a workflow run again and, if the first job passes, I’ll get a “fixed” email even though later jobs may fail. It would be nice if the emails were tied to entire workflows and I only got the fixed email when the entire workflow began passing again.
There have been a few things I expected to work that didn’t and weren’t documented, despite the docs being great. One example is CircleCI environment variables, such as the current branch, not being evaluated when used inside custom environment variables defined in the configuration file. I eventually found some mention of this on the forums, but some ‘known limitations’ or other documentation would be nice.
CircleCI 2.0 makes it easy to setup jobs and configure your workflow exactly the way you want it. Since I got rolling on CircleCI 2.0 I have been able to quickly tweak or expand my workflow, adding new processes with ease.
Even with a few quirks it’s a huge step forward from CircleCI 1.0 and I can’t imagine using anything else for CI processes in the future. If you plan on making the switch as well check out the CircleCI 1.0 to CircleCI 2.0 migration doc.