7 Tips On Continuous Delivery
Continuous Delivery is all about setting up your development processes such that you can deliver into production much more frequently than is typical, perhaps with multiple releases per day.
This is a topic I’ve been interested in for a long while having worked on projects with very long release cycles in the past.
There’s a lot being written about continuous delivery and I’ve read a lot of it, but usually the same companies are held up as examples of the practice – Facebook, Twitter, LinkedIn, Flickr – the trendy consumer web companies. With that said, I was really interested in hearing more about how it was being done in the real world in a smaller company.
I took away these points from the presentation:
People & Process – are more important than tools. There’s a lot of talk about tools such as the cloud, PAAS, puppet, virtualisation etc in this conversation. These tools can you save you time, but much more important is getting the team in line such that the good people are trusted and empowered to do it.
Ruby – Rob and his company have clearly come around to the idea of Ruby as a tool to manage their infrastructure and continuous deployments. The Ruby community has generated some very high quality testing tools such as Rake, RSpec and Cucumber which are very elegant and efficient tools for carrying out continuous deployments. Ruby is also a great elegant scripting and glue code for building CD infrastructure.
Virtualisation – Virtualisation and cloud is key to all of this and tools such as Vagrant & Chef can help to bring up environments quickly and release software in a repeatable and scalable way. Don’t be afraid to bend virtualisation to your own needs as some of the literature out there is quite prescriptive.
REST & SOA – A service based model has helped with continuous deployment goals as it means they can keep the whole architecture loosely coupled and deploy and rollback components quickly and independently. REST and SOA can be a real boon for continuous deployment.
Minimise Branching – Most changes and features are small enough that it’s not worth building seperate feature branches. Heavy branching is slightly orthogonal to continuous delivery as it keeps work and changes off of the deployed mainline.
Artifacts – Be careful with code artifacts such as JARs and Ruby dependencies. Once we’ve tested something, we need to make sure those same artifacts move through the testing and deployment pipeline in a locked down and repeatable way.
Continuous Deploys – It helps if you can architect for continuous delivery by allowing for some form of canary release or blue green deployment so that we can deploy without impacting the code base. Considerations such as avoiding server side session state can help here.
It’s clear that to get to the point of being able to do continuous delivery reliably implies huge change over the above the average development team – processes, people, code quality, quality control etc.
However, it’s equally clear that Robs startup is benefiting from Continuous Delivery and have demonstrated to their business that it was worth the investment.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)