Agile Deployment

Deployment is the end goal of any software development activity. Whether it be to the desktop, a server or app stores, why write software if the ultimate aim isn't to deploy it so it can be consumed and used.

Methods and strategies for deployment are widely debated and although the technologies used are important the overriding factor governing success is the mindset that's adopted towards shipping the code.

If asked what deployment should be like in an agile environment many teams would use variations on the concept of continuous integration. But this concept can sometimes be quite intangible how do you actually know if your achieving continuous deployment?

Continuous is Different from Regular

An unfortunate consequence of us using the word continuous to describe an ideal deployment strategy is that it implies a regular cadence is the only thing we should be judged by.

A more descriptive phrase of what we should be aiming for would be unrestricted deployment.

While a regular cadence of deployment brings with it many benefits, no matter what the frequency maybe if any of your processes enforce that deployments can only be made at that cadence then this will still cause you and your team problems.

An effective deployment strategy enables you to release whenever you want or need to. It means the only factor in deciding whether or not to deploy is whether or not the code is ready.

An ultimately effective strategy stops this even being a decision that needs to be consciously made, your systems and processes deploy code whenever it reaches the state of being done.

Deploy Code Not Features

Not every change to a code base results in something that is visible to the user. The introduction of new features can take time to come to fruition and require many changes to the code base.

If we view value as only coming from completed features this can easily lead to big bang deployments that drop a large amount of change into production.

If we can derive value from the stepping stones in getting to a complete feature then we can break this single potentially disruptive deployment into many smaller safer changes.

These small deployments will, via a cumulative effect, still get us to the desired outcome but because the surface area of change was always kept to small increment our risk of breaking something will be greatly reduced.

The user may not see any visible difference until the final deployment that fully enables the feature but they also haven't seen errors or been frustrated by a large deployment that changed many things.

This approach of deploying code when its ready will also encourage us to architect our code to be formed of distinct, separate and well defined blocks, this has many benefits for our overall code quality as well as making our deployments less stressful.

Not Wrong for Long

Many aspects of software development can be an inexact science. This is not just down to the complexity of building software but also the unpredictable nature of trying to predict how users will interact with it.

The concept of failing fast in an agile environment acknowledges this and attempts to make it ok to try things even if they will sometimes fail to have the impact you'd hoped for because we learn by the experience.

It is also, no matter the level of testing employed, virtually impossible to deliver bug free software. While we may hope to reduce these inevitable defects to the smallest and least impacting sometimes one will slip through the net.

Both these aspects means rolling back or fixing production will always be something that a team has to face. If the team doesn't have faith or confidence in its deployment process, or has to wait to deploy in the next available slot, then stress levels will rise.

This can easily lead to a reluctance to try things or conduct worthwhile experiments around what users want or need.

All of the points that have been made here link back to the fact that deployment should be easy, repeatable and in no way onerous or stressful.

The long slow build up of stress towards release day should be put to bed in favour of an automated and flexible approach that puts code into production whenever it serves the purpose it was originally intended for and meets our definition of done.

Code it, ship it and move on.