Crystallize logo
Answers/Tech / Dev/What Is CI/CD?

What 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 e-commerce, 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

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 enforce all the processes you have in place in your company/projects/teams. The CI runs the tests, and the team should have run the automation locally. It’s a verification process. A solid CI means all developers push/merge to the main branch twice daily. 

This practice requires automated tooling to check that the new code works correctly (or is 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 merge the pull request if the tests pass. This is powerful when your application is well tested.
  • A team member creates a pull request with new changes, and the 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 having the code ready for making big-scale changes with a small commit. However, applying 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 an hour to merge a simple code change. A side goal of a CI (and 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

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 in 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

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.