Release management
In a recent blog post Rhodri Pugh, one of our Senior Developers, described how at Box UK we are starting to change our code management strategy from a stable release branch model to a stable trunk model.
As Rhodri was writing from a development perspective I thought it would be useful to look at these techniques and see how they fit in with release management, as well as how clients will benefit from us using this strategy.
Tagging code from trunk
In the stable trunk model, projects are completed on feature branches and then committed to trunk; from there the code is tagged and deployed to live. Basically, only good code goes into trunk, and if it’s in trunk it will be going live when a tag is next created and applied to the production environment.
This seems to work particularly well for those of our clients running multiple projects at any one time, as these can be developed in feature branches with the onus being on the developer to update each branch regularly from trunk in order to keep things in sync. Multiple feature branches can be created which all use the same trunk code as they are pulling it from the same baseline. As this is the code that is actually live and has been pulled from when the last tag was created we can be sure it is current and up-to-date. Testing (both internal QA and UAT) is completed on a feature branch and only then is it merged back into trunk ready for deployment.
We also have a staging server which runs from trunk code with releases to live only signed off from that environment. Having this environment limits the chance of any nasty surprises because the code is exactly what will be running on live. If you get this “mirror” environment set up it can prevent many early life issues, benefitting both the client who will have reduced risk of defects being released to live and also the production team by reducing support items, freeing up developer time to work on creating new client features rather than patching existing code.
The last point falls into the realm of “Configuration Management” but this goes hand in hand with good release management anyway, and ultimately delivering a quality outcome for the client is the name of the game. In an Agile company such as Box UK it is not uncommon to have to wear various different hats be that Release, Change or Configuration Management.
Deployment pipeline
The above strategy falls in nicely with our longer term aim of embracing “Agile Release Management” as typified by the ThoughtWorks white paper “Agile Release Management – Towards Frequent Low Risk Releases” which advocates the use of a deployment pipeline and automating much as possible.
Where that fits in with the tagging from trunk strategy is on the staging server described; it should be achievable to have fully automated end-to-end testing employed on the server before a tag is created and pushed to live. While we are not at the stage at the moment where we have a fully automated deployment pipeline, it is something we are working towards and our developers have made significant steps to achieving this for the Amaxus Content Management System.
What I particularly like about the concept of the “Deployment Pipeline” are the quick feedback loops from testing. In a traditional testing environment, testing time is booked in with the QA team and tests are run manually with the results distributed to the Project and Release teams and go live decisions made from there.
With more automation the feedback loops are much quicker, the tests are being run by a machine and you can see its output as soon as this is complete. Therefore you can quickly see if there are problems with code at each quality gate, i.e. check in, unit test, acceptance tests, giving a big efficiency gain and a step towards achieving our ultimate goal of an automated deployment pipeline. In fact this approach is recommended in the book “Continuous Delivery” by Jez Humble and David Farley as in reality it’s difficult to completely adopt automation in its entirety so a more pragmatic approach is to adopt the concept piecemeal.
Frequent low risk releases
The other concept raised in the Thoughtworks white paper is the move towards frequent low risk releases, which dovetails nicely with the Agile approach to working we have. The longerbetween releases usually means the greater the differences between live and what is about to be released (mitigated admittedly by good Configuration Management of pre –production environments) and, speaking as a release manager, an increased element of risk in deployment. It also makes the release more of an “event” and therefore more likely to be surrounded by bureaucracy, whereas if we are releasing code regularly it demystifies the whole process by making it a regular occurrence and part of our “business as usual” work.
Conclusion
In the world of waterfall development, the ability to have regular deployments was always constrained by the development cycle, which by its nature led to longer cycles and the rounds of testing they required. For companies used to working in this way, the move to regular releases can seem quite a big jump and something to be treated with caution; however with rigorous testing, strict configuration management of environments and increased automation all parties will see benefits.
Some of the themes raised here would require a blog of their own to fully investigate their effect and how they can be implemented pragmatically, but hopefully this provides a useful discussion point. There is a wealth of resources online relating to these topics, but the links below provide a good place to start.
Links
About the author
Where next?
Show similar blog posts:
Add your comment