When multiple developers work on the same project, they’re changing a shared master development branch at overlapping intervals. This overlap occurs because developers create parallel branches for the work and then merge those branches in, when works on the features are completed. The branches they create for their work all start as identical copies of the master branch. But, as the master branch changes over time, the code on unmerged branches looks less and less like the current code on master. When time comes to integrate the changes into the main codebase, this inevitable divergence can cause lots of challenges that can introduce bugs, create bottlenecks or even bring development to a complete halt.
Continuous Integration, or CI, is a workflow strategy that helps to ensure that everyone’s changes will be integrated with the most up-to-date version of the project. This allows you to catch bugs, reduce merge conflicts and have confidence that your software is working. While the details may vary depending on your development environment, most CI systems feature the same basic tools and processes. In most scenarios, a team will practice CI in conjunction with automated testing using a dedicated server or according service. Whenever a developer adds new code to a branch, the server will automatically build and test it to determine whether it works and can be integrated with the code on the main development branch. The server with according automation software will produce output containing the results of the build and an indication of whether or not the branch passes all the requirements for integration into the main development branch. By exposing build and test information for every commit on every branch, CI paves the way for what’s known as Continuous Delivery, or CD, as well as a related process called Continuous Deployment.
So, what’s the difference between Continuous Delivery and Continuous Deployment ? Continuous Delivery is the practice of developing software in such a way, that you could release it at any time. When coupled with CI, Continuous Delivery lets you develop features with modular code in more manageable increments. Continuous Deployment is an extension of Continuous Delivery. It’s a process that allows you to actually deploy newly developed features into production with confidence and experience little, if any, downtime.
Now, let’s take a look at how GitHub (GitLab/BitBucket or any other kind of repo, that can be integrated) fits into this process. We’ll take in one step at a time, starting with CI. GitHub is like a clearinghouse for your code. Developers make changes locally and push those changes to GitHub when they want to share them with others. With Continuous Integration, all of these changes need to get to the, let’s call it, central automation server or CI server so it can determine whether or not they will be integrated with the current main development branch. But how does it even know about them? GitHub uses so-called «webhooks» to send messages to external systems about activity and events that occur in your projects. For each event type you can specify the subscribers who should receive the message about the event. In this case, we can subscribe our central automation server to receive a message anytime someone pushes code to a branch or opens a pull request on GitHub. The CI server will parse the message from GitHub, grab the current copy of the project, build the branch and run the tests. When the central automation server finishes its processes for the current commit, it sends a message to GitHub Status API containing status information about the commit. GitHub uses that message to display information about the commit and can even link back to more detailed information on the CI server. This helps give you a clearer idea of which changes can be integrated into the main development branch, and which ones need a bit more work.
Continuous Deployment works in a similar way. You can configure your central automation server to deploy branches as part of its processes. In a simple setup, anytime the master branch receives a new commit, the CI server grabs a current copy of the project and deploys the master branch to production. The setup for such type of deployment will vary depending on your software. If your project requires more flexibility, GitHub also exposes a Deployments API that gives you an ability to create custom deployments from branches, tags or commits. You can use the deployments API in conjunction with webhooks to automatically notify third-party systems, which can then retrieve a copy of the code from GitHub and deploy the version you request to the environment you specify.
So, let’s review all of that one more time. Continuous Integration is a workflow strategy you can lean on to help you ensure new code will integrate into the current version of the software. Continuous Delivery is developing software that could be released at any time. GitHub (or any other repo) puts your code at the center of your development ecosystem by serving as a clearinghouse that not only keeps track of changes, but also communicates with other systems about those changes using webhooks and APIs.