Continuous Delivery

With continuous delivery you should be able to ship incremental changes which allow you to reduce the number of things impacted in a change. This is very useful to help release new software. Not necessarily new features but new releases of your software. This is to make sure that new deployments don’t have errors or cause regressions, making it easy and fast to deploy software. While at the same time rewarding the efficiencies gained in the development and continuous integration (CI) processes. All of this works together and continuous delivery is just another step in the process of reducing the friction of going from development to production. The friction is both technical and organizational. If people in your organization are used to reviewing everything or checking everything manually because you only release every month or there is a long lag time between code submission and deployment then those will have to become more comfortable releasing that gate keeper mentality and adding features to your CI or cd that would give them the same comfort without stopping everything. This is key because the idea is to not let quality slide by releasing more often but actually the opposite of raising the quality of the tasks that can be automated so that they can be done frequently and consistently. Anyone who has had to manually do qa myself included knows that people get tired the tasks gets repetitive, things are missed no matter how good your intentions are.

The real goal should be to find existing or new ways to give you enough confidence in the quality of your changes and deployments that they can be done multiple times a day. That way developers or anyone who wants to work and make a customer happy can try something with confidence and see what kind of impact it has. Reducing these self imposed barriers and restrictions on cross team collaboration can have very positive effects for any organization. As you allow more people to have input or propose changes you increase the chances of having a more positive impact for your customers. It shouldn’t matter where the idea came from or who submitted the change, the focus should just be on if it positively impacted the end user of the product or made it better over all. Continuous delivery plays a large roll in that by removing the barrier to get a change deployed and seeing its impact. This can be taken down from months to a couple days or however long you decide you need feedback or data for. This has a big impact for the person proposing the changes as well because they will not have to own or convince the other team to own this change for months and it’s first released and then a second or third release either approves or removes the change. Neither party has the desire to add that much more work to their plate. But in a different situation someone has finished their tasks for a sprint or has taken some extra time to propose a change then they could potentially have a full cycle of creation deployment feedback/data gathering and justify or invalidate their idea in a matter of days off the side of their desk. As the longest process in this should be the feedback/data gathering which should cost no time to the one who proposed the change unless the feature needs to be turned off then that should just be a couple seconds and thats all. We will cover how feature toggles or flags fit into this process in the next post.

There are many different ways to do continuous delivery and all options should be open to fit and allow you to grow. This could mean that you have an end goal in mind while the steps you take to get there look very different. As you have to change both technical features and cultural features to adapt.

Personally I feel as though some form of canary release makes up a key part of continuous deployment. This is largely based off the benefits it provides not the technology or implementation. Having a simple low impact way to roll out changes while at the same time being able to compare it against the current deployment and opening up to more traffic as the changes are proven acceptable with production traffic. This is the only way to truly feel confident in your changes because it is running against real production traffic. It can also be automated and happen as quickly or as slowly as your culture decides while still providing all the feedback and greatly reducing the impact of a problem that is found in production.