It used to take hours, weeks even, to ship software – but now companies are doing it in minutes.
What was once a struggle to make ends meet is now a simple and speedy job, thanks to CI/CD. You must be asking, “What is ci/cd?” but don’t worry; we will explain it all.
Today, you can expect a detailed description and some simple concepts to hit the ground running.
Continuous Integration – Explained
The “CI” part of CI/CD stands for Continuous Integration. CI takes code from the build to testing to an artifact ready for deployment. “Continuous” means that builds can be created and ready to deploy multiple times daily.
It works like this – the developers work on code and push this code into the main branch.
The build server then processes this change and builds the application as instructed. Before turning the build into an artifact, it runs tests to ensure everything is okay and reports back if it finds an error.
People used to wait until the release stage before they started testing. This meant changing more than just one element of the code as multiple developers had interacted with it and added their information. This caused the process to take a longer time than needed.
Using a CI tool, you stop that future from happening. Instead, errors are found early; you can change them before they become a mess.
CI tools, such as Jenkins, Drone, Concourse CI, Travis CI, CircleCI, and more, can help you automate the process quickly. Each tool has its pros and cons, so research each tool you are considering. Your use case might fit one tool better than another. For example, a small company may do fine with an open-source tool, while a large organization may need a tool with enterprise-grade features.
Committing To Master
The most significant change when moving to a CI system is committing to a master. Technically it is an easy function, like hitting “save” on a game. But in reality, this concept contains a cultural shift.
People who’ve been working in the industry for decades will have a hard time changing their ways. Usually, they would finish their code and push it into the relevant feature branch, but we need a mini-save before the tree gets too large.
There is a concept called Trunk Based Development that explains this reasoning well. If you are interested, we recommend giving it a read. But to keep it simple, we need the developers to push the code into the main branch.
This is because the central branch will always be there. If the feature branch is ever removed or no longer needed, the code will be lost when it’s gone. Put the code in the main branch, and it’s saved.
Trusting The Automated Tests
Doing so many tests daily means you need a reliable system. It needs to flag any issues that might appear. You can put in as many tests as possible, but a tremendously automated system will decide what tests to run. Not all CI tools offer this functionality, so you’ll likely choose which tests to run.
For example, if you compile code, the first test you should consider is, “Does the code compile?” That might seem simple, but fixing this type of error will stop it from becoming a head-scratcher later.
Most importantly, whatever the tests tell you, you should believe it is true. There is no point in using a testing system that isn’t reliable. It is usual for you to make mistakes as a human being, but your software shouldn’t have the same faults.
Fixing Bugs Is A Priority
This is another culture change for a lot of seasoned developers. Once upon a time, the idea was to deploy a set of features and then go back to fix the bugs. This still happens occasionally, as tests won’t catch everything, but ideally, tests cover a large enough portion of code that bugs caught after deployment are the minority. Most bugs should be caught in the testing phase of CI. Producing a bug-free artifact should be the priority.
The Right Tools For CI
We briefly touched on tools earlier, but I wanted to give you more information to help you start your research. Because CI is primarily a cultural shift, it doesn’t take long to get into the process. As James Shore says, you only need an old computer, a desk bell, and a rubber chicken!
That being said, tools can be handy to get you started. You can choose from a handful, with some descriptions added.
- Azure Pipelines – This is a Microsoft product that uses open-source projects. You can start it for free and include no more than five users.
- Cloud Build – Google creates this service through their Google Cloud Platform.
- Circle CI – This tool works seamlessly with GitHub projects. It is a self-hosted project which you can use for free.
- CodeShip – This tool only uses self-hosted solutions. It is a paid-for service, but there is a free version you can try.
- GitLab CI – As you can expect, GitLab CI works exceptionally well with GitLab but can also be used alongside other tools.
- Jenkins – Jenkins is another free tool that uses open-source solutions. However, it is Java-based, so you’d have a lot of flexibility.
Continuous Delivery – Explained
The “CD” part of CI/CD stands for Continuous Delivery. It describes the ability to install changes into production (i.e., what customers see). These changes could be new features, bug fixes, or anything. The changes are delivered seamlessly and to a live environment.
The idea behind Continuous Delivery is in the name: of making frequent deployments (usually multiple per day) more diminutive in size, as opposed to a monthly release cycle (for example) that is huge and takes a long time to complete.
The CD isn’t an environment but another stage in your pipeline.
Focus On Small And Frequent Deployments
Whenever you deploy, your application’s stability is a concern. If you’re doing a large deployment where multiple people contributed code, there could be a bug (or multiple!) that will break the entire deployment and result in a rollback that could take hours.
Think of it this way: the old way of doing things (two-week sprints, monthly release cycles, etc.) poses a considerable risk of downtime, while Continuous Delivery ensures smaller deployments, often multiple times a day, where if an error does happen, it’s easy to undo.
If you’ve been using Continuous Integration and properly testing your code, then there shouldn’t be a lot of bugs to deal with, but if any come up, you only have a handful of changes to consider/rollback.
As far as tools go, try to go with an actual CD tool. Tools like Jenkins and CircleCI can be extended to perform CD, but that requires much scripting work upfront and then maintaining the system. A proper CD tool, like GoCD, Argo CD, Harness, and Octopus Deploy, is built correctly with deployment in mind.
Better yet, if you’re going to do CI/CD, get a CI/CD tool! Platforms like Harness, Azure DevOps, Codefresh, and more have the right idea in mind by combining both for a unified pipeline. It’s easier to learn one platform than two separate tools.
Labor Automation
Don’t worry; we aren’t about to jump into a sci-fi movie. The idea of labor automation is to automate anything that a person would typically do through physicality; however, anything that contains a person’s mind should be manual.
For example, it takes a person to create a recipe, but the following can lead to mistakes. You could miss a line and forget the sugar or stop paying attention and over-whisk the eggs. These are simple human errors that would never happen with a machine. Creating the recipe is different, though. It would take trial and error, imagination, and an understanding of flavors.
We can bring this metaphor into the world of software engineering. Doing repetitive tasks can easily lead to lower concentration, so try to automate these tasks. But anything that requires intellectual thought, creative problem-solving, or multiple perspectives should be left in the hands of your developers.
The Right Tools For CD
We have touched on tools a little bit but want to expand. You may notice that many CD tools are also CI tools, so some of the options we give you may be repeated. These joint-use tools could be the best option if you want to hit two birds with one stone.
- Harness – Harness is a developer-first experience that uses CI, CD, Feature Flags, and more.
- Azure Pipelines – Azure can integrate a definition section into your build stage.
- GitLab CI – This tool is an excellent choice if you already use GitLab, as it allows you to work seamlessly without conflict errors.
- Jenkins – Jenkins uses plugins like Terraform and Ansible to use the CD pipeline as code.
- Spinnaker – Spinnaker is relatively new compared to these other tools; however, it is quickly becoming popular due to one massive client – Netflix. Netflix uses Spinnaker to create releases.
Give Yourself Room To Improve
Improving at anything doesn’t happen overnight. You will become overwhelmed if you try to do too many things too fast. An overwhelmed mind backs out of the stressful situation and might not get back on track for a long time. The same goes for your systems and your developers.
When you are happy with how things are going, it’s time to improve.
Easy Teamwork
CI/CD doesn’t make fixing bugs and deploying artifacts easier. It also eases the struggles between developers and DevOps. True collaboration and communication can begin when CI/CD is done right.
This, in turn, allows both teams to focus on improving the business and delivering value to their customers.
Summary
So there you have it, the basic concept of CI/CD. Following our outlines, you can create a happy environment for your workers, quick and reliable content for your customers, and easy-to-manage pipelines to fix bugs!