Co-Founder Taliferro
Introduction
I am a fan of continuous integration and continuous deployment. It's a great way to build software, and it can make the difference between having an agile team and just thinking they are agile. Many projects say they do CI/CD when really they don't even have primary CI in place, which is unfortunate because it makes all of our jobs harder and creates more work for everyone involved.
Ticketing
Many projects make a big fuss about how they do CI/CD when it is just a human doing all the steps on a ticket. This happens because people don't understand what CI/CD means.
CI/CD is not just one step of the process; it's a workflow that happens automatically without human intervention.
The word "continuous" is an integral part of that
Continuous integration is a process by which code is checked into a repository and then automatically tested. It's the opposite of waterfall development. It's not continuous deployment or continuous delivery, either. And it has nothing to do with continuous testing, that's called "test-driven development (TDD).
CD means continuous deployment
Continuous deployment is a human process. It's something that you, as a developer do, not something that happens automatically. CD means deploying every time you check in code. That's it!
There are many benefits to CD.
Continuous deployment means automatic deployments
Is continuous deployment automatic? No. Continuous deployment is a human process where you deploy every time the build passes. You could automate that task with Jenkins or any other CI tool. Still, it would no longer be continuous deployment because there would be a delay between checking in code and deploying it (unless Jenkins runs at each commit).
Deploy every time you check in code
The CI/CD acronym is often used to refer to the process of testing and deploying code, but with the caveat that it's not a requirement.
It's prevalent for projects to say they do CI/CD when they mean they deploy every time someone checks in code. The difference between these two things is subtle but essential:
"Deploy" means pushing your code up into production after every check-in. This can be useful because it helps keep each developer up-to-date on what everyone else has been working on lately. Then if you want to test something out before merging it into the master (like running an automated test suite), you've already got everything ready, just waiting for you.
"Test" means running automated tests against your application before deploying anything into production—you're validating that everything works as planned before going ahead with any deployment.
So why do projects call themselves CI/CD when they are only using CI?
The most common reason projects call themselves CI/CD when using CI is that they need the right tools. In other words, they don't have a good definition of CI or CD either because it needs to be clarified what those terms mean or because there is no agreement on what constitutes a good definition of them.
They need to understand what proper CI/CD means and therefore can't build an appropriate pipeline for their project.
For example, some teams think that if their project uses Jenkins as its continuous integration tool (for building artifacts), then calling it "CI" would be sufficient because Jenkins has an automation feature called "build pipelines," which allows users to specify different stages in their pipelines such as compiling code from source code files into binaries or deploying these binaries into production servers automatically after passing specific tests (such as unit tests).
They have no idea what they are talking about
The reason is simple: many people have never heard of CI/CD and do not know what it is. The truth is that CI/CD is a complex topic, and it takes time to understand its concepts. Many developers get hired with the knowledge of how the code they write will be deployed into production or what their role in this process should be. It's also common for companies to hire interns who may need to gain basic programming skills such as JavaScript or Python (which can be helpful when implementing certain types of automation).
As you can see, many factors come into play when dealing with Continuous Integration systems, so don't feel bad if you don't fully grasp all these concepts right away.
Teams feel productive when cutting code and testing it as they go.
CI/CD is not a magic bullet. If you're doing continuous integration (CI) and continuous delivery (CD), everything else will fall into place. But that's different from how it works.
A good solution can be implemented poorly or even incorrectly. And this is where many teams run into trouble with CI/CD: they either implement the wrong answer or need help understanding what CI/CD means.
Conceptually, CI/CD makes sense
CI/CD is a continuous process requiring frequent software integration and delivery. We have to ask ourselves why we aren't doing this now.
Conceptually, CI/CD makes sense. You should be able to take the results of a completed test and roll it into production with the push of a button. This allows you to deliver value quickly without waiting for weeks or months for all your tests to run. It also means that you can provide new features more frequently, which helps keep customers happy since they get new features sooner rather than later.
In an ideal world . . .
In an ideal world, all the code is tested and passes all tests before it gets promoted to production. This can be done by either pushing the code or reviewing it manually before deploying it into production. That's what we need to do for our software to be reliable.
We use continuous integration (CI) to do this; CI is used to test the code and ensure all the tests are passed before promoting any changes made by developers into production. Continuous delivery (CD) is used for deploying those changes into production after being successfully tested using continuous integration tools such as GitLab Runner or Jenkins Pipelines.
Continuous integration and continuous delivery are different. CI/CD is NOT:
- Continuous testing
- Continuous monitoring
- Continuous deployment
As we all know, some emergencies arise where you need a one-line fix immediately, especially if no one else can do it. Examples include fixing some bug or something like that. These fixes are often not tested and can break other things.
They should be done by someone who knows what they are doing, and the consequences might be harmful if you don't do it right (or if someone else did it wrong).
Conclusion
"Move fast and break things" The phrase "move fast and break things" is an excellent mantra for innovation but does not translate well to production support. It's only a matter of time before something breaks, and when it does, you want your team to be able to respond quickly so that your customers aren't affected. When innovating, your goal is to move fast and break things as part of the discovery process. Any issues encountered during this period will impact production after the project has been completed successfully. When you are supporting production, however, every change made could adversely affect one or more users, which means all changes must be carefully tested before being deployed into production - no exceptions.
Tyrone Showers