Software delivers no value/revenue until it is in the hands of its users. For many businesses reducing the cycle time between an idea and usable software is critical. Usually the first iterative release contains the minimum amount of functionality providing value to the customer, thus Continuous Delivery of values is utmost importance for the competing businesses. Continuous deployment and delivery has gone from controversial to commonplace. Continuous Delivery is also a deployment methodology as customers of software see ideas rapidly turn into working code that they can use every day.
“Continuous Delivery”, it’s not just a deployment methodology, it’s a delivery thinking critical to doing business; is taken from the first principle of the Agile Manifesto:“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software“.
Continuous Delivery (CD) is the process that moves codes from Test environment to Acceptance environment to Prod environment, taking out dependency from human being and reassign dependency on process with high degree of automation where releasing software becomes routine.
CD is the ability to get changes into production, or into the hands of users, safely and quickly in a sustainable way bringing developers and operations teams together (DevOps movement). CD offers developers a way to get back to doing smaller, more frequent releases that are more reliable, predictable and manageable. CD is about making sure that every change developer is making can go through deployment pipeline and you can completely send it into the production. But at the end of the day it’s business decision which change should be deployed or not (not a technical decision). Business might not want that degree of churn and changes in the actual application, they might want to do it every week or two. So even if we can do CD but we might choose not to, but the technical people are still able to deploy every change.
Continuous Delivery makes it possible to continuously adapt software
- in line with user feedback
- shifts in the market and
- changes to business strategy
CD Pipeline requires high degree of Automation as well as very high degree of configuration Management to allow code move safely through those environments ultimately into production. You should feel confident if you flip the switch and put the changes into the production then everything is going to work fine, and if somethings breaks then you should be quickly be able to figure out what change caused the break.
CD Pipeline requires Configuration management of everything that makes up the environment like
- Source code
- db schemas
- deployment scripts
- parameters and
- all the environment variables that makes the particular environment
The foundation for the CD approach, at least for the development team, is Continuous Integration (CI). CI keeps the entire development team in sync, removing the delays due to integration issues. CI deals with the “last mile issues,” describing how to build the deployment pipeline that turns integrated code into production software.
Continuous Delivery (CD) – can deploy to production (influenced by business choice + practical reasons)
Continuous Deployment – do deploy to production
How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?”
The time from deciding that you need to make a change to having it in production is known as the cycle time, and it is a vital metric for any project.
Challenge: In many organizations, cycle time is measured in weeks or months, and the release process is certainly not repeatable or reliable.
Scenario: You have a critical bug in production. It is losing money for your business every day. You know what the fix is: A one-liner in a library that is used in all three layers of your three-tier system, and a corresponding change to one database table. But the last time you released a new version of your software to production it took a weekend of working until 2 A.M.,You know the next release is going to overrun the weekend, which means the application will be down for a period during the business week.
CD solution: After extensive re-engineering, teams were able to achieve a cycle time of hours or even minutes for a critical fix. This was possible because a fully automated, repeatable, reliable process with well-understood, quantifiable risks was created for taking changes through the various stages of the build, deploy, test, and release process.
There are certain Principles of Continuous Delivery
- Automation is the key – automate everything
- Done means “released”
- Invest in Quality Metrics (unit test coverage, code styling, rules violations, complexity measurements, etc)
- Continuous Improvement
- Quick and sustainable release/deployment process (DevOps) for everything like code, data, DB schema, etc
- Meaningful repository – keep everything in source control & simplified revision control and software configuration management (branching)
Benefits of Continuous Delivery
- Faster time to market
- Lower cost
- Low risk releases
- Higher quality-Better products
- Happier teams
- Happier customer
Smaller changes lowers the risks. With smaller changes it is easier to find problems and roll back.
Commonly used Tools for achieving Continuous Delivery
Open Source DevOps Tools
Continuous Delivery Workflow
Also check my blog on CI: In software engineering, Continuous Integration (CI) is the practice of merging and building (and automation testing) all developer working copies to a shared mainline several times a day or sometimes on every code checkin (if infrastructure supports that). CI keeps the entire development team in sync, removing the delays due to integration issues. Please see my blog on “Continuous Integration”.
@Mohammad Sami -Agile Transformation Coach
NOTE: Please note that due to some technical issues we have lost users comments until March 2019. My apologies. Please do comment and share your thoughts in the comments below
1,482 total views, 2 views today