Wednesday 12 March 2014

Why should your organization Automate and adopt Continuous Delivery ?

Waterfall projects consists in sequential phases. Notably: Development and Release phases. 
While the first has often been carefully planned, the second is a lot more hazardous and unpredictable.
(scroll down to the bottom of the page if you are only interested in the big picture)

UNPREDICTABLE INTEGRATION AND RELEASE PHASE

Most of the time, things start to go wrong in the integration, deployment and release phase (in red below). Having waited months to put things together, technical difficultes arise:
  • integration issues
  • deployment issues
  • dependencies and compatibility issues
On top of this, there is potentially a lot of rework to be done, once the team starts receiving feedback from testers. It is always challenging to release a huge chunk of work all at once:
As we can see in the image above, the development phase (in blue) is planned and limited (in scope, cost or duration). The second phase (in red) is almost impossible to predict. It consists in the following activities:
  1. manual deployment
  2. manual testing
  3. fixing integration issues
  4. re-deploy
  5. re-test
  6. go back to 1 until good enough
  7. finally release to production
This phase can be short (rare) or extend undefinitely. The history have seen integration phases take longer than the initial project duration.

THINGS GET BETTER WITH A LITTLE BIT OF AUTOMATION

What about automating some of the steps above ? 
In theory everything can be automated:
As you can see things got better with automation:
  • the deployment, testing and releasing phase always takes the same time
  • most likely the process is much faster: it is possible to increase the amount of computing resources to go even faster
  • the process is repeatable and predictable

ADOPTING CONTINUOUS DELIVERY

What if your organization decided to release often, small changes, rather than going for a big-bang release ?
Here is what is happening:
  • the development steps (in blue) consist in small changes developers make to the source code or configuration
  • for every code or configuration change, a deployment and automated test is triggered
  • depending on the organization, the change might even get automatically deployed into Production

THE BIG PICTURE

To summarise all of the above, here is a complete diagram:

No comments:

Post a Comment