CI/CD – Continuous Integration, Continuous Delivery, and Continuous Deployment
Continuous Integration (CI)
CI is the process of automatically building and testing your software on a regular basis. CI tools run builds and tests triggered by these commits. This improves consistency for testing, provides faster feedback, and reduces bugs in production.
Any time a commit is added to a branch, CI tests can let you know if the changes in that commit pass the requirements and tests you want to enforce. This reduces the time it takes to check for consistency and code review.
Continuous Delivery (CD)
Continuous Delivery means that if your tests are being run with every commit, then it is possible to release or push your project to production at any point. While this does not mean that you are releasing your code to production with every commit, it means that with every commit that passes, your changes are production-ready.
Continuous Deployment (CD)
Continuous Deployment takes Continuous Delivery one step further. This is the actual delivery of changes and updates to production without human interaction.
CI Status Checks in the Workflow
Typically, on a GitHub project, there is branch protection on the master branch so that contributors cannot push directly to this production branch. Instead, they can create a branch off of the master to work on changes in the form of commits on the newly created branch. This is the first point where CI status checks can be required to succeed. It is important for contributors to send their commits in a pull request as early as possible so that these CI status checks can run early on and prevent them from redoing work that could have been avoided.
Once the pull request is opened, the discussion and review of the changes take place. Commits during this process still report back status checks. At this point, there can be another branch protection that requires a pull request to be approved before a branch can be merged. This protection can be in the form of requiring a number of approving reviews on the pull request before it can be merged in.
Before merging in, there can be other branch protections to make sure the newly created branch is up to date from the master and has approval from a designated reviewer. Merging to the main branch can also be limited to a release team or a manager.