CI and CD are two software development processes that allow teams to integrate code and deploy products to users faster, safer, cheaper and easier.
I will discuss both of these methods and their benefits.
Both of these methods have been around in some form since the 1990s but have gained popularity more recently as they solve common integration and deployment issues teams often face.
What is CI?
CI is Continuous Integration.
This is a process where the development team frequently checks their code into the same source control repository and branch so that it is frequently integrated.
Commit Frequently
Each developer should check their code into this branch at least once per day, but ideally it would be even more than that.
As the code is checked in from all developers on the project into a single branch, a build is created.
The build can consist of scripts and tasks that need to run, such as variable swapping, unit tests, etc.
Code is Integrated With Each Commit
The developer checking in the code at the time can watch the build and if it fails, he or she will know that their commit broke the build.
They are then able to fix this immediately.
Without CI
The ability to integrate code daily and immediately fix broken builds is important because the common practice without CI is that each developer would work on a separate branch and at the end of a cycle, right before a release, the developers would all create merge requests into the deployment branch.
That would mean that there is no way to know if all of the code will integrate together until right before the release.
If there were bugs during this integration process, they would be caught at the end of the cycle and there would be a huge scramble to fix them.
It could mean a delay of a promised feature or the release entirely.
Costly Integrations Without CI
You can imagine that the scenario where all developers integrate their code immediately before a deployment can be costly.
With CI, a developer knows if their code was integrated immediately after checking it in because they can check if the build failed.
If the build fails, they can immediately fix their code.
Imagine finishing some bug fixes or features quickly in the cycle and continuing to move on to new tasks, then right at the end of the cycle, your code doesn’t integrate! You (the developer) need to switch gears and go back to this old task you worked on and work as fast as possible to get it fixed. Then it needs to be integrated and tested over again.
CI fixes this common problem.
Benefits
The big benefit is the ease of integrating code. This saves time and money, bugs are found earlier and can be fixed faster.
Your build pipeline can check unit tests and fail the build if one fails. After a successful build, automated tests and end to end tests can run.
All in all, CI is a huge win for companies that migrate to this process.
Pro Tip:
Developers can run the pipeline locally and make sure there are no merge conflicts, failed tests, and other issues before the code is allowed to be pushed to the repository.
What is CD?
CD is often associated with CI. CD could be Continuous Delivery or Continuous Deployments.
These are two slightly different processes from each other.
Continuous Deployments would mean that each time code is checked in, it is automatically deployed.
While there are pros and cons to this approach, I would usually prefer Continuous Delivery as it gives a team more control.
The rest of this post will refer to CD as Continuous Delivery (not Continuous Deployment. See? Confusing!)
Continuous Delivery (often confused with Continuous Deployments) means that a development team has the ability to deploy their codebase at any time, though they can chose when as it is not automatically deployed with each integration.
Freedom to Deploy Any time
If a feature is ready to go and is accepted, it can be deployed.
The master branch (or deployment branch) is always ready for production.
A team can deploy to production multiple times a day if it works for them.
They could do a daily deployment, or still deploy at the end of a sprint knowing that the codebase is always ready for production.
Build to a Lower Environment for Testing Immediately
As code is checked in multiple times a day because of a team’s CI process, maybe a team doesn’t want code to go directly to production.
But, code can be automatically deployed to a test environment for the QA team to get a look at.
It can also be deployed to an environment for viewing by the business team as code is integrated. That way, design and user experience can be accepted as it is worked on.
This can prevent a situation where a developer works for a full cycle (or more) on a new feature and as it is integrated and built to a test environment right before a release, the business team finds flaws in the UX and wants the design changed.
Simpler Deployments
Again, code can deploy to a test, staging and/or prod environment immediately.
This can occur because the process is automated. It can be set up so as a developer commits code, a hook is caught and the codebase is built and immediately deployed by running scripts and tasks that the team set up.
It can also be manually deployed at the push of a button. This might be a better way to deploy to QA or Production for your team.
No matter how your team decides to deploy, CD gives that flexibility.
Flexible Deployments
Speaking of flexibility, all deployments can be set up the same. If something needs to change, it can be tested in Test, Acceptance, Staging, or a lower environment to ensure that it will work when deploying to production.
Flexible Tooling
While there are many tools like: GoCD, Jenkins, Azure Devops, etc. that allow you to create your deployment pipeline, they have one thing in common.
They are flexible.
CI and CD are not rigid processes. They are language, framework, and culture agnostic.
Need a bash script to run? Maybe a little powershell now? Need to install npm or nuget packages? a ruby gem (I think that's a thing, right?).
These tools will allow you to do that in a manner that works with your team's workflow and culture without having to make a large institutional change in the tooling.
If Everyone is Committng to the Same Branch, Won't There Be Code Conflicts?
Yes, if you are not communicating with your team.
Members on the team should not be working on the same portions of a code base that would conflict regardless of committing to the same branch with CI/CD or if they are using a feature branch and integrating code once before each release.
Even without CI and CD, this is the kind of practice that would lead to conflicts and integration issues.
It is important to communicate this with your team and distribute work appropriately.
That doesn't change with Continuous Integration and Continuous Deployments.
What changes is that the code is integrated frequently.
If Everyone is Committing to the Master Branch, Won’t it Get Polluted with Code That is Not Production Ready?
Yes and no.
CI/CD works best with agile teams that deploy small features every 2 or 3 weeks.
Now, let’s say you are working on a large feature that takes 10 weeks. That means your code would be polluting the deployment branch for the devs working on smaller items in the cycle.
Should you just commit to a separate branch?
No.
That would break CI because your code needs to be integrated at least daily to know that it doesn’t break a build. And 10 weeks without an integration?! That’s a huge risk.
There are options for this, one common and excellent solution that is often utilized is by using a feature flag.
Feature Flags
A feature flag allows you to hide code behind a toggle. You can decide which users can view your code and in which environments.
This can be useful for progressively deploying a new feature out to users, or collecting feedback on some new integration.
A feature flag is also an excellent tool for Continuous Integration.
Getting into how you can use a feature flag is out of scope for this article, but check out Launch Darkly’s website. They have excellent docs and I have used their product and highly recommend them.
Downside
Is there a downside to CI/CD?
I can think of a few
Human Error
CI/CD automates the build process. That eliminates the possibilities for human error. Except that computers really only do what humans tell them to.
So who sets up the build processes? Humans.
And when a process needs to change for a specific deployment or a new pipeline needs to be created, who does that?
Humans.
While CI/CD makes integration and deployment faster, safer, cheaper, easier, and removes a lot of possibility for human error… there is still room for some human error. And man do you feel dumb when you mess something up!
Computers and automation won't fix everything. Developers need to learn the tooling and processes and apply them appropriately.
Cultural Change
The biggest downside to CI/CD is the cultural change it takes to implement it.
I’m sure I lost tons of people when I said that devs should be committing code multiple times a day to the master branch.
It sounded crazy to me at first… until I did it, and a few cycles later it started to make sense.
Who is going to run the deployments? Well, see… your pipeline will just run… no one is responsible for manually deploying anymore. That is another one that doesn’t always make sense.
Finding these issues and working them out will be unique to your team's culture and needs.
It will take time, but the benefits of CI/CD tend to be worth it.
Slow For Teams to Implement
Part of the reason it is slow for teams to implement is the cultural change.
But when I began using CI/CD, it was unclear when we would need a feature flag or what environment we wanted to deploy to and when.
These are things that will certainly take time and collaboration.
It’s energy well spent though to get to a point where integration is regular and deployments are a breeze.
Conclusion
CI is continuous integration. It is a practice where development teams commit their code into a shared repository and the code is immediately integrated together with the rest of the development team's code.
This can help a team find integration issues immediately and fix them.
This can also be done in a manner where the repository is always ready for a deployment at any time.
The concept of being able to deploy at any time is Continous Delivery. (Often confused with Continuous Deployment which is when code is deployed immediately and automatically after it is integrated).
These two practices, CI and CD, can help teams deliver code faster, with few bugs, and spending less time on the deployments and integrations and more time on development, thus saving a company money.
Top comments (0)