How does Continuous Delivery expedite the software development process for Agile team? Mr Anand Agrawal, a Lead Consultant at ThoughtWorks Singapore explains.
Agile taught us how build software so that it is always tested and approved by product owners to avoid any last minute surprises. It advocates working software over process to cut down any bottlenecks in software development and make it smooth. It emphasises on collaboration of all the roles that are needed to develop the software to enable quick decisions.
Continuous Delivery (CD) is Agile on Steroids. Continuous Delivery is about building software so that it can be released at any point of time. It brings in the deployments into the software delivery life-cycle. This empowers the team to make a small change and release it to production. How long does it take for your team and teams around you to make a small change and release to production? CD tries to cut the time between a developer making a change and getting that deployed to production.
Traditionally, there are release engineers who are responsible for releasing the software to production. They are typically disconnected with the development teams and have limited knowledge of what the development team is doing. Similarly, the development team knows very little about deployments. CD tries to bring in both roles together and work as one team.
Continuous Delivery pipeline:
A typical CD pipeline has the following stages:
Test: This stage can have dual purposes - running the tests and packaging the application. As soon as there is any change in the code, this stage is responsible for the running of the automated tests for the application (unit tests, integration tests, performance test, etc.). Different tests have different meaning and purpose. Unit tests test the logic and validate that the system works in isolation. Integration tests check if the application works with other applications it is integrating to. Once tests validate that the application is not broken, it packages the application so that other stages could deploy the binary.
UAT/Quality Assurance: This stage deploys the application into the User Acceptance Test (UAT) environment and runs acceptance tests to give quality analysts and product owners the confidence that no existing feature is broken.
Production: Single click deployment to production. This stage may also run a few tests to validate that the deployment went through successfully.
Depending on the need, stages could be further broken down into more stages. In more complex systems, the picture can become more complicated. The idea is that in each stage, one should run relevant tests and give quick feedback.
Infrastructure as code
Automating deployments is not complete without Infrastructure automation. If a machine crashes, how much time does it take to build a new one? What does it take to scale the system horizontally? If infrastructure is automated, these questions would be easier to answer. The advantage of scripting infrastructure is that it can be version controlled, easy to provision a new server, identical infrastructure in all the environments, and since everything is coded, it could be tested. It becomes very easy to audit any change in the servers if changes are enforced to be done by a version controlled script.
Impact of CD on culture of organisation
An organisation that starts its journey to implement a CD culture goes through a series of changes. CD changes the way software is built. It brings together all the roles responsible to successfully deliver the project and change the way they look at software delivery.
Developers start thinking that the code they write could go live as soon as they commit it to the main version control system. It encourages developers to test their code before check-in, hence increase the test coverage and ensure less bugs.
Quality Analysts: Like developers, quality analysts would start automating more and more tests to ensure quality of the application and avoid any repetitive work for the deployments. This includes user journeys, security tests, performance tests, etc.
Release Engineers: Since releases are more frequent with CD pipeline, release engineers would start thinking about removing any inefficiency in the release process.
Product Owners / Business Analysts: With the release cycle being cut down to a few minutes, decision-makers start thinking about what are the most important things to be done immediately than to wait for the features to go through a long release cycle.
Is this for me?
Well, my answer is yes in almost all the cases. If you are a small organisation, you want to keep releasing new features to adapt with market demands. If you are a big organisation, you don’t want to delay the problems with deployment and wait for weeks to get application deployed to production. It is always easier to deploy small changes than deploy and roll back huge chunk of changes.
At ThoughtWorks we have enabled many of our clients to do Continuous Delivery. We have various case studies on how it helped our clients and how deployments, from being a ceremony, became a business as usual. We believe that making small changes and deploying often is the best way to build software. Doing difficult things more often makes it easy.
By Anand Agrawal, Lead Consultant, ThoughtWorks Singapore, email aagrawal@thoughtworks.com
In collaboration with ThoughtWorks, ISS has introduced an NICF course - Agile Continuous Delivery course in 2013. It aims to provide participants with a 3-day in-depth understanding of Agile Continuous Delivery concepts so that they have the know-how to facilitate their organisations to stay lean, innovative and agile.
For more information on this course, visit
/executive-education/course/detail/nicf-agile-continuous-delivery/agile
This article is first published in NUS-ISS quarterly e-newsletter, Issue 6 (Apr-Jun 2014).