Always Deploying

Within most development teams we're becoming used to most things being continuous.

The adoption of Continuous Integration (CI) has given us tooling that can ensure the effort of developers can be combined at the earliest opportunity, and an increasing emphasis on shifting left has made it possible for us to ensure quality is a default position.

But ultimately software has to be deployed to be of any value and despite all the tooling available to smooth this transition into production for many teams this final push is still something thats feared.

If your fearful of deploying code this will become a self fulfilling prophecy and things will go wrong, your fear will grow and you will deploy on an even more infrequent basis.

Break this cycle of fear and move to a situation where deploying to production requires little effort and is something that is a natural consequence of your team delivering.

Not Wrong for Long

The likelihood of an issue occurring after a deployment is proportional to the amount of change being deployed.

If you deploy large change infrequently not only do you need to be confident in your testing regime but its likely that if you do face difficulties you'll find it harder to roll back your changes to your last known good state.

If you deploy small change frequently the chances of an issue arising are reduced but also the fast route into production you've developed means rolling back is simply another deployment accomplished quickly and with little fuss.

This ensures that if the worst happens your not wrong for long.

A long drawn out deployment process is an attempt to make sure nothing ever breaks in production. While that's an admiral intention mistakes will happen and ultimately all this achieves is complicating the recovery from these unavoidable mishaps.

Continuous MVP

A misunderstanding of the concept of a Minimum Viable Product (MVP) is probably the biggest barrier to teams becoming truly Agile in their approach.

Infrequent deployments can exacerbate the tendency to try and squeeze more scope into each release because of the limited opportunities to deliver features.

When features can be deployed at will it becomes much easier to move people to a mindset of shipping a true MVP, they know the next release can be whenever some value has been added to the journey rather than the next scheduled window of opportunity. 

Reducing the time between an idea and a deployment into production also increases the opportunity for user feedback to have a real influence on the direction of a product. 

Feedback is received early meaning large amounts of effort isn't wasted on functionality that users don't find valuable, and once again if need be removing the functionality entirely is just another deployment. 

Don't Break It

Regular deployment of code will also encourage people not to break things.

Large gaps between deployments tends to encourage an acceptance towards parts of the code base being broken, inevitably leading to an increasing feeling of panic when release day does eventually bear down upon us.

When code is to be shipped as soon as its finished not only does code have to be maintained in a working state but this continual green light has to demonstrable, this leads to an increasing effort being put into effective automated testing and good documentation of what the code base working actually means.

Here a distinction can be drawn between Delivery and Deployment, even when operating a Continual Deployment strategy it isn't necessarily the case that every build has to be pushed to production, but it certainly should be the case that it could.

Aside from wanting to deploy new features at the earliest opportunity we can also never predict when an emergency, such as security vulnerability, forces into a deployment we weren't planning on.

In this situations it is definitely advantageous to know everything still works.

Continuous could be described as the mantra for modern development practices, all the activities we value should be happening all the time.

As the last step in the chain that connects us to our users this should also apply to deployment.

As with so many things its good advice to confront your fears, if release day currently comes with feelings of dread then give yourself the impetus to confront these fears and find a solution by having more and more release days.

Delivering into production should never be taken lightly, and quality should always be maintained, but its possible to do this while also trying to give users the value the instant its achieved by your development team.