SoftwareYoga

Articles on Coding and Architecture

Are You Prepared for Continuous Delivery?

This post was originally written for TechTownTraining blog.

This is Part 2 in the series on Continuous Delivery. In Part 1, we introduced to you the concept of continuous delivery, how it is related to continuous integration and the advantages it brings to the table.

Continuous Delivery requires that every commit into the code base be built immediately and that any build can be deployed into the production environment.

So now that you have decided to implement Continuous Delivery practices, I thought I’d share a few ways in which you can begin making the transition to Continuous Delivery.

Automation

Automation is the first pillar of a well developed CD pipeline. We must eliminate as many manual activities as possible in order to achieve maximum benefit.

It is highly likely that your development teams are already testing their code before it is released to production. Some of it may be manual and some of it automated.

However, when moving to Continuous Delivery, the most critical aspect is about testing the code every time there is a commit to the code base. As discussed in the previous post, you should already have this setup if you already have an established Continuous Integration workflow.

Your teams should have a fiery attitude to “Automate every possible thing”

However, are you automating all the critical aspects? Do you, as a leader in the team know what tests are automated? Do you know the scope of automation in relation to the whole code base? Unfortunately, in many organizations, only the development teams can answer this question.

Remember that having a sound CD pipeline and process should not be confined to just the realms of the development team.

Automation of all important areas in the software is necessary and hence fall into a wide range of categories:

Commit often, Commit soon

A second most important foundation of CD process is the ability to deliver changes frequently. When delivering software, having fast feedback cycle can make all the difference.

Big bang development approach and deployments, unfortunately, are still a norm in the industry. In such a way of working, it is normal to release a large amount of code into production in a single shot, usually a few months apart.

Introducing huge amount of changes in the code and deploying then into a production system can have unexpected consequences. It’s hard to know exactly what went wrong, and it can be difficult to diagnose. Large systems updated this way are difficult to bring back to a working state as you cannot roll back easily.

Continuous Delivery demands that you integrate your changes with the master branch frequently. Any time you change the code, push the changes to version control.

If you do not commit all day, there is no way of telling how your work will fit in with the rest of the system or whether it has broken anything. If you are using a version control system, the developers have the ability to switch to the code of any given point in time in the past.

Another positive result of frequent commits is that you get faster feedback on the state of the project. You quickly discover others heading in the wrong direction with their solutions. Should something go wrong, you only have a handful of potential suspects to debug. Also, don’t forget that meaningful commit messages matter!

CD is impossible when developers work in isolation from each other for long periods of time. It’s not uncommon to see development cycles last a few months, especially in large companies. When development work happens this way, large amounts of testing are required at the end of the development phase. This results in long periods during which you have no clear picture of whether your application is working or not.

Avoiding this uncertainty would require that developers commit their work frequently, and therefore usable by others as soon as possible. In large teams this becomes vital, since merge conflicts and other problems arising out of a big commit become less frequent and more manageable to solve.

In the rare case (improbable but not impossible!) that you are not using any version control, know that a continuous delivery model cannot work without it.

Developers and Operations

If you are a software development company in 2018, you probably already follow at least part of the Agile/Scrum way of working. One of the rituals of Scrum is the daily standup, a meeting where everyone on the team discuss: what was done yesterday, what is going to be done today, and what is preventing you from getting your work done.

The purpose of the standup is to keep the whole team informed about the work that is being done.

An easy way to increase the knowledge of production environment in your development team is to have Ops engineers attend the standup. People working in Operations can provide information of their work to the Development team. This would enable the development teams to better appreciate the work done by operations.

In the long run, you would want these two silos i.e. the development team and the ops team to work together anyway i.e. DevOps. You are also fostering a work environment where Operations can help solve your team’s current production problems.

Knowledge of Production Environment

The final frontier of CD is to deploy into a production environment. The deployment into production need not happen for every commit that is made into the code base, but every build needs to be production ready.

Most development teams have only the faintest of ideas of the real production environment, the specifications of the hardware and software, configurations, security rules etc. On the contrary, the norm is that developers have no access to the production environment at all, unless requested by a red tape process.

The first step that needs to be taken in order to improve this situation is to have a staging environment that reflects the real production environment as close as possible. It should be possible to create and configure the staging environment using automated scripts. This will allow the staging environment to evolve and recreated as many times as needed.

Breaking Monoliths

A common obstacle for an efficient implementation of CD is overcoming the sluggishness of large monolithic code bases. Slow builds, brittle code base, complex code and architecture are some of the usual problems.

A common approach that is taken into re-architect the entire system. This obviously needs to happen after a buy in from the management as it involves significant time, resources and money, not to mention technical challenges.

For companies that are not focussed on software development, it is much harder to get this approval from management as this would need additional budget and effort allocated into something that may only being marginal benefit at best.

For other companies that are more software focussed, re-architecting the entire solution may just be the best approach in the long run.

A starter approach I recommend is to split the code base into multiple repositories, with each repository focussed on a smaller subset of the overall product. Each of these smaller repositories should be self contained in that they should have their own build scripts, tests etc.

This way, the benefits of the CD process could be realized sooner without needing the complete overhaul of the system. In the long run, these individual repositories should be further broken down into smaller parts using the microservices architecture approach.

Hopefully these suggestions help you think about where to focus your efforts while beginning your journey towards a Continuous Delivery process. Even if you are not on the same journey, I am sure you will see tremendous benefits just by implementing few of the suggestions made here.