High level overview of CI/CD
Modern software development is much more complex than a few years ago, because its reach has grown, use cases have multiplied and there’s basically no business nowadays which doesn’t rely on software to function. This means that the demands that the software must meet are much more complex and diverse than before. With increased demand, comes also increased availability and reliability.
Currently, the best way to ensure that software meets such high standards is by using CI/CD.
CI/CD which stands for Continuous Integration/Continuous Delivery is a process that ensures that any changes made to the code, will guarantee an artifact that will be in a releasable state at all times. This is done in several stages.
Firstly, it’s important to notice that a CI/CD setup is usually a software pipeline configured by leveraging the idea of IaC - Infrastructure as code. The idea is that at the root of the repository, a configuration file is added, usually a .yaml
file, where the pipeline configuration is defined in a declarative way, and, once new code is pushed from the repository where the configuration is defined, the pipeline will trigger and the CI/CD process will start. Let’s see the typical stages of a pipeline that ensure the quality of the software being released:
-
compile stage: in this step, the code is simply compiled and packaged, to ensure that there are no breaking changes introduced in the build; depending on the setup of your team and company, in this step, additional actions can happen, like, generating docker images, updating internal registries with new artifacts, etc.
-
testing stage(s): the testing stage of a pipeline is usually comprised of several different sub stages: there are usually several different types of tests, and, all of these are part of the pipeline: unit tests, integration tests, acceptance tests. Additionally, reporting regarding the test coverage of the codebase are usually also run at this stage.
-
release stage: this release stage is where the, usually automated, code release happens and a new version is deployed to be available to clients. Usually the pipeline is configured in such a way that this release stage will only occur when pushing code against a specific branch, usually
main
ormaster
and this is done to ensure that only code containing a feature considered final is released.
By combining these stages in a pipeline like fashion we ensure that the software we release is of high quality and that any changes requested by customers or critical bug fixes can land in production in a predictable, safe and reliable way.
There’s more than this overview of CI/CD but this post covers the basics about it so that you have a solid basis to research it or try to establish it at your company in case you still don’t do it. It’s a relatively simple, one off process that will pay itself many times over, during the lifetime of your teams and projects!