Continuous Delivery System

It is a new buzz word in software development process automation. concept is about reducing the cycle time between ‘idea’ and ‘Production software’.

Why do we need it?

If software professionals think about some new idea how soon we can deliver that to end users? The whole idea is to increase the automated co-ordination between build, deploy, test and release processes.

Foundation of this approach is Continuous Integration which keeps development teams in sync removing delays due to integration issues. But CI is just the first step. We still have to run an extra mile to make this integrated software, a “production software”. In various software product companies who do frequent releases, deployment is a big headache.

Let us ask a question to ourselves that, “How much time will our team take for our team to deploy a single change in code on production environment?”

If the answer to this question is, “3-4 hours” (which will be rarest of rare case), can you do it in a repeatable fashion? The answers will certainly a big NO. Right? Come on… you can be lucky on the time.  Above all release process is certainly not repeatable or reliable. As this process is manual and generally organizations have dedicated teams which handle releases.

But, it is possible to have a reliable, repeatable process which can take changes from various stages of build,  deploy, test and release process. “Automation” is the key.

Issues we face while deploying software manually

• We have to produce extensive documentation that describes the steps to be taken and the ways in which steps may go wrong.
• Reliance on manual testing to make sure that application is working fine.
• Frequent calls to deployment team to figure out why deployment is going wrong on the release date.
• Frequent corrections to the release process during the course of a release.
• Environments in the cluster that differ in their configuration. For example application server with different connection pool settings, file system with different layout.
• Release that takes more than few minutes to perform.
• Release that is unpredictable in its outcome that often has to be rolled back or run into unforeseen problems.
• Sitting bleary-eyed in front of monitor at 2 am the day after release day, and trying to figure out how to make it work.

How to avoid issues listed above?

Integrate testing, deployment and release activities into the development process. Make them normal and ongoing part of development so that by the time you are ready to release your system into production there is little of no risk, because you have rehearsed in many different occasions in a progressively more production-like sequence of test environments

Where to start?

The answer is Deployment pipeline. It is a pattern which lays down certain guidelines for taking software from development to release. This is the answer to following questions.

• What happened when requirements are identified, solutions are designed, developed and tested?
• How are these activities join together and coordinate together to make the process as efficient and reliable as possible.
• How can we enable development, testing, build and operations teams to work together effectively?
• How to reduce Team’s stress and nervousness on release day?

 

What is the AIM of deployment pipeline?

• To make every part of the process of building, deploying, testing and release software visible to all stake holders.
• To improve “feedback process” so that problems are identified and resolved as soon as possible in the process.
• It enables teams to deploy and release any version of software for any environment at will through a fully reliable and automated process

 

Principles of software delivery

• Create a repeatable, reliable process for software release.
• Automate almost everything
• Keep everything in version control
• If it hurts, do it more frequently and bring the pain in front.
• Build quality in
• Done means released
• Everybody is responsible for delivery process.
• Continuous improvement

Other good reference

http://www.informit.com/articles/printerfriendly.aspx?p=1621865

If it is repeatable, it can most certainly be automated.

Releasing software too often is an art; it should be an engineering discipline