Continuous Business

Continuous delivery is a term often spoken but its consequences are not always appreciated or understood.

Continuous delivery when combined with continuous deployment should create a situation where deployment to production is a complete non-event, it doesn't inspire feelings of either pleasure or dread it is simply a natural consequence of code being produced or modified.

While there is a technical element to building a pipeline to put this into practice, in order to succeed the whole business must be signed up to the process and be willing to let go of fear, control and ownership.

Out In The Open

When a pipeline into production is automated it should be done in such a way as to increase its visibility to all team members and stakeholders.

Rather than a software release being a process shrouded in mystery full of anticipation everyone sees the process from start to finish and more importantly sees the checks and balances being automatically enforced to ensure quality and fitness for purpose.

This openness reduces the feeling that the release is owned by anyone and the decrease in obscurity will increase the feeling that everyone is playing a part in delivery and can see the fruit of their labours.

Its often said that with enough eyes on a problem anything can be solved and the more people that have clear visibility of the route from code repository to production the bigger the likelihood improvements will be suggested and the faster they can be implemented.

Reduction of Risk

Automation can sometimes be a word that scares people, they associate it with a lack of control and sign off that can bring about anarchy.

In actual fact well implemented automation reduces risk, people make mistakes but an automated pipeline can be relied upon to always act in the same way and always apply the same rules and standards.

Automation also carries connotations of speed so even if occasionally a release goes bad automation can ensure we are "not wrong for long" by enabling us to quickly stand up new infrastructure, roll back changes or increase capacity.

That is not to say that badly constructed automation cannot lead to the kind of disorder and chaos that people fear but this is equally as likely with poorly conceived manual processes and the sluggishness of those processes will likely bite just when agility is required to rectify a situation.

Machine Throughput

There will come a point in the growth of any team or any system where the thirst for change cannot be meet without an automated approach.

People generally react badly and perform to a lower standard when they are put under pressure to deliver more in less time, attention to detail recedes and the probability of mistakes shorten.

Automation in the form of machines do not suffer from this problem they do the same job every time and can be relied upon to perform the same checks and balances regardless of deadlines.

In this regard to embrace automation is to embrace quality. It also embraces delivery, it places at centre stage the desire to deliver software and the features it implements into the hands of users as soon as they become available not because of a deadline.

In too many teams a software release is a long drawn out process resulting in a big bang when a large amount of change is delivered all at once with team members running for cover to avoid the fall out.

Instead we should strive to banish the concept of a release, it is not a process that need be paid any mind.

We have created a lean mean delivery machine, code enters at one end and usability exits at the other.

While the writing of software should never be compared to a production line the delivery of that software once its completed should be just as never ending and repeatable as any other factory.