Continuous Delivery Guide — Part 1/5

Hi guys, how are you? I hope you’re all doing just fine!

Today we are here to talk about Continuous Delivery theory.

This will be a five part article, in which we’ll discuss:

1. What is Continuous Delivery and why is that important?
2. What are the available tools and how to choose one?
3. Spinnaker: I want to sail in this one!
4. Jenkins X: New way to look the good old Jenkins
5. Concourse CI: New guy in town

I really hope you find this series useful, and if you do, please leave a comment or DM me on LinkedIn.

What is Continuous Delivery?

Continuous Delivery is the ability to release new features or correct bugs in production with three principles in mind:

1. It has to be fast
2. It has to be safe
3. It has to be sustainable

As you can see, it does not matter the architecture of your system, either being a big monolithic application or a bunch of microservices. But if you do have multiple microservices running in your production environment, be aware that each one has to have its own pace of delivery.

Why should I have this in mind?

It's quite simple to understand why, but very hard to put into practice. CD may not be exclusive to your team, it's a whole process, that begins with an idea, a project, a release.

And the reason for that are the benefits CD brings alongside with it.

1. Low Implementation Risks

It is possible to bring into production a new feature using multiple patters, such as blue-green deployment or canary deployment. Such patterns have the ability to lower your downtime or make it invisible to the end user.

2. Happy Team

Although it could get a little tense during the implementation of the CD process, your team would be the most satisfied after the job is done, simply because you wouldn't have to be awake at 11pm to deploy that app.

3. Time to Market

This may be the most beneficial reason for the whole company. Time to market became one of the most important things to a company those days. Today we get a lot of information very quickly and one week of a missed opportunity could be catastrophic.

Three Pillars for Continuous Delivery

There are three fundamental pillars in which the whole process must be standing.

• Configuration Management
• Continuous Integration
• Tests

Configuration Management is the process of having everything you need to scale or reproduce your business in an automated way. This includes your source code, testing, infrastructure, pipelines, libraries. Having everything stored in a secure place and with the availability of scaling in no time is crucial to a continuous delivery system.

And now you must be thinking that "Oh shit, I'm in the wrong place, we should have done this a long time ago". Well, rest your head. Think that companies like Google or Apple were not born like this. They must have a lot of thing in a great configuration management system, but they were not born like this. Just change the way you get your things done. Piece by piece the whole picture gets designed.

Continuous Integration is probably the most difficult thing here, well, for me of course. CI is all about making everyone work together. And it is not about that cool new tool that you are using, it is about people. And when it comes to people, everything gets a little bit harder.

One good example from that is the old problem when you have to merge your changes into master, and a lot of conflicts emerge in a simple three line code.

CI comes to save the day and make everyone work together as a whole, with the team patterns in mind and the business always making the calls. This comes exceedingly necessary when you get a fast growing team.

And finally Testing. This should not be hard, right? We write code to test our own code, what could go wrong?

Well, the most important thing about testing is feedback.

Image from continuousdelivery.com

As we can see, every time a change in the code has occurred the whole system has to be trigged. Even though it was only a 2 line change, we must test and get approvals from everybody in the process.

And the tests are one of the key fundamentals of the process, because they can tell us if the changes we made are actually being an improvement to the final product or they are just irrelevant.

The Culture behind Continuous Delivery

Culture is something hard to change. Specially if your company is a large one, with serveral teams and products. Just a little bit of change could cause a huge problem.

However, in order to CD work, there must be a some aspects of a cultural change happening. At first, try to have a warm welcome to new ideas and act upon them. As well with problems, try not to find a guilty person, instead, gather a bunch of people and work it out!

As you noticed, it’s not about tools. It’s about people and process. Having a clean workflow with defined objectives.

My personal recommendation falls into the Effective DevOps book, written by Jennifer Davis and Ryn Daniels.

Why is it so boring?

If you ever had this question when dealing with CD, you may be in the right path. CD is all about making things so boring, that you don’t wanna even look to them.

You probably have that process, in which you always know some problem is coming up, or a failover will eventually happen. Continuous Delivery has the fundamental objective to make those tasks tedious, in a way that a simple machine could do them.

This series will go on, stay tunned in my LinkedIn for some news.

See ya!