More in LearnWhat Is CI/CD?
CI/CD, or Continuous Integration/Continuous Deployment (or Delivery), is a set of software engineering practices that aim to speed up the software development process. For example, in eCommerce, CI/CD practices can help make changes to a website (or application) faster and with a lower risk of failure.
Typically, CI/CD is about building automated workflows by using scripts or platforms connected to your Git repository. However, CI/CD is also about the way of development: for example, the ability to release small changes more often.
The following sections describe the main principles of each practice.
Continuous Integration (CI) is the process of continuously building, testing, and merging changes into a project, usually into a shared source code repository. Without Continuous Integration, you would not have Continuous Deployment. CI helps you to enforce all the processes that you have in place in your company/projects/teams. The CI is in charge to run the tests and the automation that should have been run by the team locally. It’s a verification process. A solid CI means all developers push/merge to the main branch a couple of times per day.
This practice requires automated tooling for checking that the new code is working correctly (or eventually also well-written). It is typical to call this tooling "CI," but CI is the way of development, not tooling.
There are many ways of setting up a CI workflow in a team:
- A team member runs tests locally and then pushes changes to the main branch. CI tooling can additionally run tests, coding standards, and automation in general after the push. It acts as a safeguard.
- A team member pushes a feature branch and creates a pull request. CI tooling will automatically run the automation and might even merge the pull request if tests pass. This is really powerful when your application is well tested.
- A team member creates a pull request with new changes, and tooling runs tests. Another team member will do a quick code review and merge the pull request.
- …
Using CI is not easy. The biggest challenge is to have the code ready for making big-scale changes by a small commit. However, applying even a few CI principles or setting up CI tooling is beneficial. It checks the code more frequently and avoids unexpected situations such as new bugs, code to refactor, etc.
Also, a CI must be fast to run. You cannot ask your team to wait for an hour to merge a simple code change. A side goal of a CI (as well with CD) is to reduce the feedback loop on a feature or a fix.
Examples of CI automation/checks:
- Coding Standards
- Static Analysis
- Security (via Dependabot for instance)
- Automatic Installation process (to improve onboarding of new team members)
- Tests (Unit, Functional, and Smoke at least)
Continuous Deployment is a practice that follows Continuous Integration. The practice is about automatically releasing all new changes that passed the CI. Typically, there is tooling for building the code and deploying the build output to the live environment.
Similar to CI, there are many workflows for continuous deployment:
- Production environment only with trust on CI tooling
- Production environment with feature previews
- Production and staging environments with frequent releases to staging, applying staging changes to production after some time and verification.
- …
A good CD platform will let you have one environment per feature (Pull Request or branch). The goal is once again to reduce the feedback loop. Having one working environment per feature enables QA to be more efficient.
This is when Platform as a Service (PaaS) comes in handy. As your architecture is code, it follows your automation.
Continuous Delivery is similar to Continuous Deployment, but only the build is automatic. Every release requires manual action (typically pressing a button), and it is common to choose specific build output to be released.
For example, reverting release in continuous deployment means creating a commit that reverts changes. In continuous delivery, it just means choosing and releasing previous build output.
It is possible to combine continuous delivery with continuous deployment.
There are many platforms for CI/CD tooling:
