CI/CD.
You may have heard this weird little acronym floating around the web.
But what the heck is it?
And should you use it as a software developer?
Read on to find out!
What is CI/CD?
CI/CD is an acronym for continuous integration/continuous deployment.
But it can also mean continuous integration/continuous delivery (more on the differences below).
Basically, CI/CD automates:
- your builds
- your tests
- your deployments
And like all good pieces of software, a good CI/CD workflow is going to save you time.
This gives the boss a happy face!
It also prevents you, the developer, from flipping your desk over in an epic rage quit. Woot!
What are the benefits of CI/CD?
A few of the benefits of CI/CD include:
- Reduced production & staging errors
- Makes bugs easier to find & remove
- Easy rollbacks since changes are small & incremental
- Increase in team productivity
- Rapid feedback including automated code analysis & code health report
- Competitive advantage: you can get feedback from customers faster
- No more manual FTP deployment
What is Continuous Integration?
Continuous integration isn’t necessarily a particular tool.
Think of it more as a workflow or setup. And the CI tool(s) you choose lets you execute that workflow.
For example, there’s a CI tool called Jenkins.
Here’s what a CI process might look like if you were using Jenkins:
Developers push code to a repo frequently. This could include patches, updates, and new functionalities.
Once pushed, a Jenkins build server tests that code.
Jenkins shows developers if their code has passed or failed.
If code fails: Fix code and repeat steps 1-3.
If code passes: Send to deployment environment.
In this flow, broken builds become a priority before building the next feature.
What is Continuous Deployment?
Continuous deployment is the second part of the “CI/CD” equation.
And it ensures your software can be released on demand. Deployments are fast and frequent.
Remember the process from the CI section above?
Once the code passes the tests, it’s pushed to its final phase: the deployment environment.
This whole process has a name. It’s called a deployment pipeline. Further, all code changes you make go through this pipeline.
What’s a deployment pipeline?
A deployment pipeline (or CI/CD pipeline) a series of validations your code flows through before it’s released to production.
For example, a simple pipeline could consist of these phases:
Image via semaphoreci.com
And here’s a theoretical pipeline for a Go project:
Image via semaphoreci.com
These example pipelines may look relatively straightforward. However, they can get complex quickly:
Image via Medium
Do remember that pipelines vary from company to company, project to project.
What is the difference between continuous deployment and continuous delivery?
Continuous deployment simply means all changes go through a pipeline. They’re automatically deployed into production.
On the other hand, continuous delivery means means developers must manually approve the deployment.
Then once approved, the pipeline continues its automation.
Image via crisp.se
To illustrate another way:
Image via RedHat
What are some popular CI/CD tools?
Some popular CI/CD tools include:
- Travis CI
- Jenkins
- CircleCI
- GitLab
- Spinnaker
- BuildKite
Do CI/CD tools cost money?
It depends.
While some CI/CD tools are totally free, some are freemium and some are paid tier only.
Additionally, many are available as part of the GitHub student developer pack. This includes Travis CI.
So if you’re a student, read this GitHub post to check your eligibility.
Also, GitHub announced in 2019 that GitHub actions now supports CI/CD. This is a free feature available to public repos.
Should I use CI/CD as a software developer?
For complete code newbies:
Not recommended.
Is CI/CD is an incredibly powerful mechanism for your workflow? Yes.
But learning the basics of programming and workflow management 101 (i.e. Git workflow) is more important as an aspiring developer.
For advaced beginners:
Give it a try!
Because if you plan on working in the industry as a software developer, there’s a good chance you’ll be using some sort of automation.
Thus, getting familiar with continuous integration & continuous deployment/delivery, even as a solo dev, is good practice.
For those in the industry:
Absolutely. If you have a DevOps team, there’s a good chance they’ve implemented (or plan on implementing) a CI/CD workflow.
But if you don’t have a DevOps team, you can still get up and running with CI/CD.
Conclusion: What is CI/CD?
In summary, CI/CD is a way to automate your builds, tests and deployments.
There are lots of open source tools available.
But there are also paid options if you need the upgrade.
At the end of the day, continuous integration and continuous deployment/delivery can save time and money.
Lastly, if you’re on a dev team, it’s something you should seriously consider using.
Are you using CI/CD? If so, what tools do you prefer?
Top comments (5)
To start, I've found that the simplest solution came with github Actions and github runners.
I work with node and react, so my apps are deployed to a vps. Its amazing to code, push and deploy automatically to the vps.
GitHub actions is such a fantastic way to get started, They have such a simple and intuitive product.
I think you've missed the most important point about continuous integration. You need to integrate your code regularly with your mainline. The reason why this is so important is it informs you of what the overall state of the codebase. If you have long lived feature branches you will only really know if your work broke something when you merge, instead of when you run the CI on your branch.
Continuous delivery (CD) is more about being able to deploy at any given time. Its not even about your deployment being automated, although automating it is often the most practical thing to do. I suspect the reason for people getting this wrong so often is because of vendors trying to push their products on blogs...
"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually, each person integrates at least daily - leading to multiple integrations per day." - martinfowler.com/articles/continuo...
There is the misconception of the CI is a tool or a server, when actually is a practice, there's also the need to do real CI of adopting something as trunkbaseddevelopment.com/ that enables the merge to main easily.
I'm using Azure DevOps CI... and want to use the CD part too, but can't because something is denying me the ability to set it up. Ah well... at least I get a status report every time my app is built on whether or not my tests passed.