There is a lot of debate among developers, product managers and project owners alike around the shift from Agile to Continuous Delivery as a process of software development and delivery.
Important nuanced thing to understand here is that both of them are not exclusive concepts and in-fact Continuous Delivery is something which can be very well done along with Agile process your team already follows.
Idea of Continuous Delivery is that the code should be 100% release ready with every single commit. In agile people often attach a notion that there will be some time required to make the code ‘ready’ after the end of a sprint. This is where CD comes into the picture, what if your code is already release ready all throughout the sprint.
By keeping code release-ready doesn’t necessarily mean that you have to ship it to your end customers, it simply means that code gets pushed down into a pipeline which mimics the conditions of production — from testing to devops scripts to production like environment.
Some people associate the idea of shorter release cycles in agile development with continuous delivery, but that is not the case, as CD is more about setting up the right process around code commits, testing and devops. For doing CD there has to be a build server, a build script and automated tests and integration process in place. Tooling and environment has to be same which will be there in production.
Older build tools like Maven etc don’t do great amount of justice to CD as they are architected around the concepts of ‘Snapshot builds’ and ‘Release builds’. In CD all builds are release builds. So this calls for new tools like CircleCI or Jenkins which are architected around the concept of keeping tab on your code base and triggering build scripts based on any system changes.
This level of automation requires development teams, QA teams and DevOps team to work really closely with each other. QA teams and DevOps teams act more like engineers on an industrial oil rig, constantly analysing data and flows and taking action only when the things break down. So CD doesn’t replace the DevOps or QA, but instead require them to have a higher analytical role in the process. Continuous Delivery Embedded in Agile workflow is becoming a standard in how software gets build and is delivered to the end users faster.
So CD can be thought of as an additional good practice which can be integrated in the overall agile flow of things. A rapid virtuous feedback process for everyone involved created by CD helps to make shipping code more predictable and less marred with ‘continuous frustration’ or surprises.
Uber revolutionised transportation by helping us hail a cab with just a push of button, Amazon changed the game of retail by delivering us our products at the click of button similarly Continuous Delivery intends to make delivery of software to end customers as simple as push of a button for the developers.