Now’ a Days technology landscape (which one could describe as a sky filled with clouds that overlook a sea of IoT devices), clients expect a constant flow of updates on it. They also expect them to be seamlessly deployment. From microservices to mobile apps, modern applications there are lots of moving components required to deliver their services. Read this tutorial and make sure to create a free Codefresh account to start building, testing and deploying Docker images faster than ever before.
What are CI and CD?
Just to set our baseline, I thought it would be useful to define what CI and CD are before getting into the value they can provide. Instead of redefining these terms, let me cite the “official” definitions from the guys at ThoughtWorks, who literally wrote the books on these topics.
Suggested Read: Continuous testing embraced but adoption still a challenge
Continuous Integration (CI) is a programmer practice that requires developers to integrate code is a shared repository several times a day. At check-in is then verified by an automated build, allowing teams to detect problems early.
Continuous Delivery (CD) is the natural extension of Continuous Integration an approach in which team ensure that every change to the system is reliable, and that we can release any version at the push of a button. Continuous Delivery aims to make releases boring, we can deliver frequently and get fast feedback on what users care about.
Pipelines: What are they?
Once you have the CI and CD in place, the deployable unit path is called a pipeline. You can see the example pipeline in the image below:
A pipeline procedure triggered when code is committed to a repository hosted somewhere like GitHub. Next comes to a notification to a build system, such as Codefresh. The build system compiles the code and runs unit tests.
Wait, your code does have unit tests, right? Of course, it does; I don’t know why I asked. (If you are not doing unit testing, you need to do!) Back to the pipeline.
If your pipeline is built well then unit tests go smoothly, at this point integration tests should be the next step.
Also Read: 7 steps to adopt continuous testing
After integration testing has done, you can create images and push them to a registry service, such as Docker Hub. From there, they can be easily deployed.
This is just a basic example. A pipeline can do many other things, like as performing security scans, run quality checks on the code, send slack notifications etc. You can also have approval steps that stop a pipeline and ask for human approval before resuming their operations.
Some pipelines also include automatic deployment (which is sometimes called Continuous Deployment) to a test environment for any user validation after the packages are built.
Pipelines: The Good, The Bad, The Ugly
Now that you know what a pipeline is, let’s discuss the pros and cons of pipelines.
Probably the biggest con (although it’s easy to avoid as long as you approach pipelines in a healthy way) is the temptation of trying to build your own tools in-house. This is insane. As I mentioned in the previous section, there are more than enough tools available in the market to get you started without having to reinvent the wheel. Almost always they end up with a spaghetti structure of files and methods that nobody wants to edit or add features.
Pipelines done the wrong way can also be dangerous because they can limit the amount of choice you have in deciding which tools to use. You can spend a lot of time trying to find the perfect tool, or combination of tools, to meet your dream scenario. A better approach is simply to find tools that are good enough to start. Whatever tool you pick first, you will probably be missing a specific feature you want, or it will be too big or small for what you need it to do.
Importance of Pipelines
The single most important piece of a solid deployment pipeline is that it is so consistent and reliable, it’s boring. Building code isn’t fun, packaging things and managing dependencies between versions sucks, and having someone waiting around to make sure every successful build gets put in the correct test environment right away is a bad use of everyone’s time.
Any developer that has been in the industry for a while has fought to get something deployed in a second (or 15th) environment and it just won’t start or throws a weird error that no one has seen before. Then, the game to find what step got missed, starts. Of course, it’s always someone else who missed the step, and asking other people if they performed ALL of the steps in their jobs in order to track down the source of the problem is extremely time-consuming.
With delivery pipelines, however, you get the same result every time, so if it works in the system test environment it will work in UAT and staging and production.