How Populate uses CircleCI to implement a nice continuous delivery workflow
At Populate we design and develop projects related with civic tech and civic engagement, mainly in Ruby on Rails and Javascript. For the last year we have started our own transparency and open government platform called Gobierto.
Gobierto is an open source project, built in Ruby on Rails with a few parts in Javascript (mainly jQuery, Vue.js and D3.js). From the beginning of the project we have had in mind good practices such as testing, code reviews, and of course a workflow for continuous delivery. We like to release small changes very frequently.
Last week we enabled automatic deployments thanks to CircleCI deployment integration. Our scenario is quite common in the Rails ecosystem and we are sure that many other Rails projects can get inspiration and tips from this post.
Development workflow
Let’s review quickly our development workflow. It’s heavily inspired in many others we have been reading in the last years, specially in the one implemented at BeBanjo, a company in which some us have worked in the past.
First of all, a summary of our main git branches:
- master: this is the branch with the stable code, the one that is released to production environemnt.
- staging: this is the integration branch, the one that is released to staging environment, where all the topic branches get merged.
Every time a developer picks a new issue from our backlog, a new topic branch is created based on the stable code (master branch). All the work related with that issue will be done in that topic branch.
Once the issue is ready (or almost), it can be merged in staging branch and released to staging, for testing purposes:
- if it works as the developer would expect, a new pull request (PR) is created against master with a description
- otherwise, the developer needs to iterate a bit more
We have integrated CircleCI in a way that is integrated with Github PRs, so we get the results of the test suite run inside the PR. If tests are green, CircleCI will take care of releasing the code to our staging environment using a custom script. We’ll get back later to this.
Once the PR is created, another developer will pick it up for review (we are a small team so we can have just another developer to review it).
When the PR is merged, CircleCI will run the tests again in the master branch and will release it to the stable environment.
CircleCI deployment integration
CircleCI provides a few ways to integrate the deployment with your build process. Because we use our own cloud and our own deployment tool, called deploy-bot, we only needed to create simple bash script to deploy and add it to the deployment section of the circle.yml file to enable deployments.
# circle.ymldeployment: production: branch: master commands: - ./script/production_deploy.sh staging: branch: staging commands: - ./script/staging_deploy.sh
deploy-bot is an internal tool (heavily inspired in atmost/heaven) that we use to deploy our projects. It provides a simple API that can be requested to release a project in any of the environments configured.
Consequences of enabling automatic deployments
Automatic deployments was the last missing piece of our workflow. Thanks to our testing coverage, code review process and deployment bot we are pretty confident when we release code that nothing is going to break.
Anyway, automatic deployments forces us to think a bit more carefully on which code we are introducing in production, and be very careful with data migrations and database migrations, because now we don’t control when the code is going to be released, and it needs to be fully automatic, and written in a way that if necessary a rollback can be done to restore the previous version.
If you are considering automatic deployments, you really need to think about it and be sure it fits with your team way of working. Thankfully, tools like CircleCI make it really easy.
If you wanna to discuss about this or other topics, or just say hi drop us a line at lets@populate.tools or follow us at @Populate and @gobierto.