Story 4: Do it right away…or achieve continuous deployments step by step?

I am a big fan of automating everything possible – do not confuse it with everything, some things should still be done manually. One step that can help with this is the hero of today’s article – continuous deployments. I assume that most of you have already heard about this at one of the conferences, meetups or read in one of the many articles that can be found on the Internet.

For those who have not heard, I have prepared a short, theoretical introduction. Suppose there is a user story at the beginning. Developers start to implement it. They push changes – from this point on there is no more room for manual work. Then some automatic things are going on – testing, building, and other fun stuff. The work that is pushed, immediately affects the production environment.

And there you go! Customers are using the latest version of the software.

Well, how to achieve such a perfect state?

In the beginning, it will be a very difficult (and sometimes boring) task because you have to convince everyone interested (and those not). Is there one best path? Definitely not. It is influenced by many factors – the conditions you found, the openness of minds to change, infrastructure, budget, and others. But that does not mean you cannot use some ready-to-use steps. Depending on the type of software – greenfield or legacy – this will look different.

Let’s start with the first one because it will be less complicated. If you want to achieve full automation of deployments as soon as possible, it is a good idea to take steps towards continuous delivery (yes, it differs from deployment!) from the very beginning. Ok, but what does that mean?

Referring to the theoretical introduction example, I am going to split the mid part of the continuous deployment flow into a more detailed view:

Now, magical things have become clearer. In the above picture, everything is automated – no manual work after coding is finished. An alternative or intermediate step may be the previously mentioned continuous delivery:

In comparison to continuous deployment, there is one manual step that has to be done between “build is green” and deployment to production. This may be due to the company’s unreadiness for full automation, fear of blowing up production, and most of all, lack of confidence in such a solution. Someone who is used to manual testing may just require it and you will not be able to do anything about it. Fun fact – the staging environment to which the code is deployed to get approval is in fact creating a continuous deployment process internally!

However, after some time, once you have gained confidence, and successive versions of the software work without major problems, most will be convinced that it is a waste of time to manually click through the application. Trust is the key to achieving continuous deployment – you can have the latest technology, infrastructure, but when every new deployment introduces critical bugs, you can forget about agreeing to full automation.

How does it look from the legacy side? There is one difference – the path will be longer. And way longer if you are dealing with enterprise-class architecture as you have to convince multiple teams and be very careful about changes that you introduce that might affect integration between different systems.

A quite common situation in legacy systems is a nasty releasing process. Due to the multitude of problems that occur, releases are often postponed and there are only a few per year. This is mainly due to all the manual steps that need to be taken. And it is very easy to make mistakes at different points in the cycle. Not to mention the preparation time, which can be, for example, 5 weeks – manual testing, approval from different people, etc.

Do not worry – you can get out of it! There’s a saying – if a release every 5 weeks brings you problems, do one every 4. Then 3, 2, 1. Do it every third day. Then each day. Simple to say, harder to do. Steps that you can make are:

• During next release preparation, make notes of areas you find most problematic
• If problems are related to manual process of deployments, start automating steps one by one
• If problems are related to decision makers, then do together workshop, use e.g. event storming to find out events and hot spots in your process
• Recognize features in your software that are mostly used (analytics tools, make survey with your customers, look where most bugs are usually reported) are and write smoke tests for them
• Increase automation day by day, week by week, month by month

When you are ready to deploy every single day, then you are almost on the path to continuous delivery. And from there it is a straight path to continuous deployment. One important thing – even if you are not able to get there and you stopped at deployment that takes 3 days, you are the winner! You came back from 5 weeks to a couple of days. 🙂

In the end, it is time for a real-life example of what continuous deployment can look like. Going back to the second paragraph and the assumption that there is work that needs to be done (our user story). Let’s say it is divided into subtasks. Each subtask has its own branch. In each branch, the needed code is implemented. When the work in a branch is ready, the author creates a pull request. For each pull request there are several build steps:

• Unit tests are run
• New environment for PR is deployed
• Acceptance tests are run

After the approval of the code reviewer, the code is merged with the main repository. The repository can be monitored for changes and if any exist, then trigger the update of production (you can take a look at quite a nice tool that can help you with it). After the production is deployed, a set of smoke tests can be automatically run.

And that’s it – the newest release is visible to the world!