CI/CD is a hot topic in software development for years now. Year by year, popularity and usage of it increases. I will cover the definitions, pros and cons of all three to let you choose if you need them or not. Then I will cover some of the business domains or company structures, and if they need to or can use CI/CD pipelines.
What is continuous integration?
According to wikipedia, CI is the practice of merging all developers’ working copies to a shared mainline several times a day. Also, it is the beginning of the CI/CD perfection. The definition is simple enough to understand, but how does it work?
The pipeline works like this: You integrate early, and you integrate more often. What you need to have for having CI is simply:
- Technologically: You need automated building and automated unit testing.
- Socially: You need motivated developers to develop their unit tests, and also they should be confortable with committing/pushing their code to the mainline several times a day.
What will you gain by implementing CI?
You will fail early and often. This seems like a negative output for an outsider, but believe me it’s not. Failing early will allow you to steer your plan according to this failures earlier, eventually makes your product both more successful, more accurate for you user(s), and in time. Failing often helps your plan to be up-to-date all the time.
You will have a test suite up-to-date all the time. If you have obsolete tests, they will fail and you wouldn’t be able to integrate, thus you will always have a perfectly fine test suite.
You will have a faster codebase and test suite. Your whole build and test suite execution should be in a logical time frame (15 minutes at maximum.) since the CI pipeline should grant the team with fast feedback. Whole integration should take no more time than a medium-length coffee break. Taking time more than this will result lost focus, and bottlenecks in the CI pipeline.
You will handle issues faster. If you use non-continuous integration, since you discovered buggy parts of your code integration-to-integration, you will probably have builded more functionalities above the faulty one. Thus, after fixing your initial issue, you will need to fix all the related issues that will arise from that fix. However, if you use CI, your bug will be discovered in time, then fixed. You will have no other functionalities built on a bug, thus fixing them will not be an issue.
Faster releases. People plan non-continuous integrations beforehand, and releases happen only at the integration periods. Also, some of those releases may be failed and postponed to the next release since the bugs cannot be solved in the integration time. However, in a project that uses CI, your codebase is always ready to deploy when the time comes. Also, when the user needs a new feature ASAP and don’t want to wait for integration, you can release your product without waiting the date set before.
Who cannot/shouldn’t use CI?
Low-level program developers, like sensor or actuator developers. Their products will not be iterative, and self-containing, thus they have just only one integration. Thus, they are not for CI/CD.
Application developers that target embedded devices. Since your target device probably has a low-end CPU and limited ammount of memory. The tests and builds will take more time and you will be missing fast feedback.
Teams which are just too big. If more than 30 people work on your product and your integration takes 15 minutes, than some of your developers cannot commit a day’s work to the trunk for an 8-hour workday. For larger teams, you should either divide your teams, or make your CI pipeline faster first.
When the return of investment is just too low. Implementing CI costs both money, and time(which is money). If your gains do not surprass your costs, just don’t.
The team is not ready. The team is not ready for test-driven development or mutliple commits a day, than you should educate your team to benefit from these first. Otherwise, your efforts of implementing CI would go to waste.
What is continuous delivery?
Continuous delivery is having new and working software in the mainline codebase all the time. It is the next step of the full CI/CD. Your product will always be ready to deploy and have full features. For achieving this, you need:
- Continuous integration: You need to implement continuous integration first to achieve continuous delivery. The reason for that is continuous delivery builds on the practices of CI. You need to have it first.
- Branching strategy: You cannot merge everything to the mainline because it will cause having unfinished features on the trunk which make it un-deployable. One of the most used strategies here is “feature branching”. This is like: When a new feature is started to be developed, a feature branch is opened for it, by using continuous integration, the development of this feature is done at that specific branch. When the development of the feature is completed, the feature is merged to the mainline as a full-functioning module and the mainline codebase stays deployable whole time.
What will you gain by implementing continuous delivery?
Effortless releses: Being sure of deployability of your product, releases are just a button click away. They are mostly pain-less too.
Faster market time: If customer asks for it, a feature can be deployed without waiting a fixed date, as soon as the feature is finished, since the product will be releaseable.
Always have a product ready: Your main product never brakes down, always ready to develop. Even if you missed a deadline for few features, the others will be deployable.
Enables early termination of projects: Continuous delivery allows customer to end the project without turning it to a premature mess. If the features develop until now feels satisfactory, early terminations are possible.
Enables continuous deployment: Continuous delivery enables continuous deployment to happen, which is the magnificient beast that I will talk about next.
Who cannot/shouldn’t use cont. delivery?
If your release dates are fixed: If the dates for release are fixed before, the early delivery option is not a gain, so you don’t need to implement this. Implementing less means saving money.
If the customer is asking a feature creep: Sometimes rapid feature delivery gives the customer the courage to ask for new features that are not that important with increasing importances assigned to them. In that kind of setup, it would be better for the product to get updates in a regular basis like a week or so.
If you cannot use continuous integration: Because, DUH!
If you don’t have the upfront investments: You need at least one DevOps person to control your source control and deployabilities and the developers should have the grasp of the various branching strategies to achieve this.
What is continuous deployment?
Continuous deployment is the extreme form of continuous delivery. The only difference is the deployment happens every time a feature is fully implemented automatically. This is where you will get the full CI/CD benefits. From 2011, Amazon was deploying a new software in the system every 11.6 seconds in average. In the busiest hour, the deploy per hour count was 1079, which is roughly 3.3 seconds per deploy. Seems nice. Here’s what you need for this:
- A perfect infrastructure to recover with rolling back or else: If a deployed feature is found faulty in the alive system, rolling back should happen in seconds to minimize the downtime of the service. For example, on the Amazon’s website, only 1 of every 100.000 deployment cause trouble to the users thanks to their design of load balancers.
- Continuous delivery: Because, DUH!
What will you gain with CD?
Cutting costs: Since there will be no pain of deployment, you can cut costs of the salaries of the deployment, DevOps, or operations team.
Lightspeed to the market! After you pass the last test, you immediately deploy features. Cannot beat this pace!(Maybe without testing LOL.)
Enables rapid A/B testing: Deploying so frequently allows to serve your product different to segments of customers for A/B testing. For example, for a new way of service may be presented for an hour to some customers to get the feedback if they like it or not. According to the output of A/B tests, this features can stay at the alive website long term or not. By the way, this could even be the color of a specific button.
Happier teams: Continuous deployment erases the stress of deployment from a developer’s mind, lowering the burnouts and so.
More optimized products: Using CD, not only the developer teams, but also the product teams get faster feedback from the customer, which can be used for optimizing the product. More optimized products make pretty much everyone happy.
Closing
In many domains, CI/CD pipelines are becoming the new defacto standard, and I tried to explain how they are helpful and if your organization can salvage from these at all. Let me know in the comments if this CI/CD article helped you to clarify the concepts for you or changed your mind about anything. Check my website if you liked my content. See you soon!
