The case for Continuous Delivery

The case for Continuous Delivery2017-10-12T22:05:27+00:00

Whatever the professional appeal of a smooth, seamless, rapid, reliable flow, Continuous Delivery is only likely to be supported by an organisation’s management if it also has a convincing business case.

Such a business case does not need to be exclusively financial, but it must be clear that, on balance, investing in CD would pay.

So what is the case for (and against) CD?

The benefits of Continuous Delivery

Whether taken as a whole or in its successive parts, Continuous Delivery promises:

Improvements to the delivery process

  • Defects are reduced, so both the frustration and the costly delays due to rework are reduced.
  • Clashes between multiple changes (as everyone tries to build and integrate at the same time) are avoided.
  • Bugs are given no time to conceal one another or to create the kind of multi-layer effect that is especially hard to understand and repair.
  • Later development will not be based on mistaken ideas about faulty code elsewhere in the system.
  • The software is healthier, so you always know where you are starting from.
  • The process as a whole is faster and more reliable.

Benefits to the team

  • Only small parts of the system change between builds and integrations, so you know where to look, and the answer should be pretty simple.
  • Bugs are probably caused by something you did very recently, so its cause should be fresh in your mind and relatively easy to find.
  • There has been little time for defects to interact or propagate, so it should be easy to compare the buggy version of the code with the one you know works (i.e., the previous version). A simple diff will tell you where to start.
  • The cleanness of the resulting code makes it much easier to build and/or automate reliable and effective tests.
  • Testing will throw up far fewer defects based on trivial errors or incorrect assumptions.
  • Broken code is actively demoralising, leading to falling standards and demotivated developers (the ‘Broken Windows’ syndrome).
  • At any given moment there are fewer untested assumptions (e.g., about environment variables).
  • There will be fewer unintended consequences of mistakes.
  • ‘White knuckle’ integrations become a thing of the past.
  • Developers grow in confidence.
  • Developers are relieved of a whole range of repetitive, dull, error-prone tasks, and so freed to concentrate less on cost-adding tasks such as debugging and retesting and more on value-adding tasks like design and coding.
  • It’s a lot easier to keep the team’s promises.

Benefits to the organisation

  • There are no more late, long, high-risk, unpredictable integrations.
  • Work (both status and progress) become more visible, and what is visible is more accurate.
  • Decision-making is simplified.
  • It is literally a single simple step from completing the code to delivery to the user.
  • Frequent deployments are more feasible, so users get new features and a more enriched experience more quickly.
  • The speed and simplicity of delivery encourages an open development culture, ready communications and collaboration.
  • Metrics such as cycle time, throughput, and code quality can be properly integrated into a single suite that creates a far more realistic understanding of the relationship between inputs (development effort, elapsed time, etc.) and outputs (stories implemented, code quality, etc.).
  • Everyone has – justifiably – greater confidence in the final product.

In short, Continuous Delivery offers to a delivery process that is not only faster but safer too.

The risks of Continuous Delivery

If the benefits of CD are clear, so are some of the risks.

  • The accelerated rate of change that follows from implementing CD can bring on change fatigue.
  • Any imperfections in CD – which will be unavoidable early on – will tend to undermine the process as a whole. It is essential that the CD team prepare well, track effectively and move to correct problems quickly and convincingly.
  • Especially when creating the Continuous Deployment phase, you may expose fault lines and breaks in your organisation that currently demand considerable management attention, and which can’t be fixed permanently without a good deal of unexpected effort and the expenditure of political and cultural capital.

The costs of Continuous Delivery

Unfortunately Continuous Delivery is not all roses. As the Philip Crosby, the quality management guru, once said, quality is free but it isn’t a gift. Likewise, although the long-term benefits of CD are potentially far greater than its costs, you have to invest and work hard to realise them.

Here are the main investments you will have to make to create a complete CD pipeline:

  • Tool licensing.
    • Many good tools such as Subversion are free and open source, however.
  • Installing, configuring, integrating and otherwise setting up an end-to-end delivery pipeline.
  • Building a central repository.
    • Plus the effort to track down, organise and migrate all the files into your repository.
  • Building automated test suites.
  • Training your teams:
    • To use the CD pipeline.
    • To use the individual CD tools and repositories.
    • To stop using local systems, tools, data and files.
  • Day-to-day running costs of a CD process and the supporting tool management function.
  • On-going maintenance and support.

These investments are not negligible, implementing them can be pretty disruptive, and they will certainly require a good deal of on-going management attention if they are to realise the potential benefit.

The limits of Continuous Delivery

If Continuous Delivery is so beneficial, why isn’t is more widespread? Well, many objections have been raised.

  • A basic requirement of CD is having a regular cadence (rate and pulse) of development. Stories need to be completed at regular high rate, so that the much improved CD process has something to feed on. From the outside at least, this is difficult to achieve and hard to maintain.
  • Continuous Build and Integration mean that everything is in the mainline, so nothing can easily be held back if it turns out not to work. In other words, it is difficult to easily exclude items. This makes it especially important to have clear rules for when integrations should take place – only when the code its clean, tested, and so on. Also, roll-back to a previous known state should also always be possible.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?