Cherry-picking our way to production
Releasing to production is an important step for us. At first, we had to check that everything on our staging branch was production ready, the product owner had to go over every recent changes to validate it, we had to be careful not to merge anything into the staging branch before we merged it into our production branch. As our productivity increased and we tackled different issues in parallel, we had to come up with a different solution to have an easy, painless and reliable way to release in production. Here is how we did it.
Our precise needs
To be clear about our process, we listed our needs:
- Be able to select what features we want to release
- Be sure about the list of features we are about to release
- Feel relaxed when releasing
- Keep track of what was released (for bug tracking, release notes and demo)
- Keep track of what still needs to be released at some point
Our tools were github and zenhub, which provides a board of User Stories, and we wanted to avoid having to develop too many things to set up our release process.
The cherry-pick process
The feature-switch development was considered for a moment but it looked like it would lengthen our development cycle, introduced complicated code and a need for cleanup once the feature is fully ready. We also considered only merging to our development branch once we were sure we wanted to release the feature but that meant having staging environments for each feature.
Finally we decided to use the cherry-pick command between development branch and the branch to deploy to select only the commits for the features we wanted. This is not too tedious since we squash and merge every pull request, each feature has only a limited number of commits. We also added an intermediary branch in which we cherry-pick the features before it is merged into the production branch. This way, we can double check that only the proper features are released.
To help us with this process, we use the following tools:
- A spreadsheet with all the commits of development branch that are not yet in production (we use the
git log --cherry-pick --right-only --pretty=format:%H_%s release...developcommand to regularly check if it’s correct). This is a temporary solution since we did not want to invest too much time on building the perfect tools before using the process for real - Two specific columns in our agile board (to release, released) to track the issues we want to release
This way, the key points of the regular flow are:
- Decide we want to do a release,
- Check in the spreadsheet for all the commits related to the issues in the “to release” column,
- Cherry-pick them into release branch,
- Make a pull request from release branch to production,
- Deploy to the production server
- Finish the release process, clean the spreadsheet and move the issues to released column.
Our limits
Sometimes we cannot cherry-pick what we want because of conflicts. Therefore we must release the depending features or decide to postpone releasing the features we wanted to. Most of the time this is not an issue because our code is properly separated and we can anticipate the dependance between features but conflicts on our schema.rb for the version of the database is a real pain we would like to address at some point.
Wrapping up
We were not satisfied with the rigidity of our release system, postponing release because some features could not be released yet was no longer acceptable. We opted for a workflow based on some tracking tools (a spreadsheet and our agile board) and the cherry-pick command. We can now select the features we want to release, as long as they do not conflict with other waiting features.
We are currently satisfied with this workflow and the limit is acceptable since the situation is way better than the previous one. However that is still a lot of manual process, so the next step will probably be to add some automation to make the whole deployment process easy and streamlined.
We are recruiting, apply if you like the way we work
