Continuous Integration In Github
When more than one developers work on the same software project, they’ll normally be committing changes to a shared master branch, these changes happen in different time stamps. This overlap happen due to the developers creating parallel branches from the same master, and then merge them back when they are done developing.
The branches they create for their work all start off as identical copies of the master branch, but as the master branch changes over time, the code on an un-merged branch looks less and less like the current code on master.
When it’s time to integrate their 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 ensure
everyone’s changes will integrate with the current version of the project.
This lets you catch bugs, reduce merge conflicts, and have confidence 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 CI service.
Whenever a developer adds new work to a branch, the server will automatically build and test the code to determine whether it works and can be integrated with the code on the main development branch.
The CI server 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 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 CI, all of these changes need to get to the CI server so it can determine whether or not they will integrate with the current main development branch. But how does it even know about them?
GitHub uses what are 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 CI 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 CI 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 often configure your CI server to deploy branches as part of its processes.
In a simple setup, anytime the master branch receives a new commit, the CI provider grabs a current copy of the project, and deploys the master branch to production. The setup for this type of deployment will vary depending on your provider. If your project requires more flexibility, GitHub also exposes a Deployments API that lets you 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 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.
Thanks for GitHub Training & Guides
If you work the Right to left design or languages, or you know someone who do, then buying my book will be great way to gain RTL end to end knowledge and support me to keep writing book at the same time.
https://www.amazon.com/RTL-Foundations-Sam-Shamsan/dp/1656300087
