♪ (music) ♪
When multiple developers work on the same project,
they'll usually be changing a shared master development branch
at overlapping intervals.
This overlap occurs because developers create parallel branches for work,
and then merge those branches in when features are complete.
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 unmerged 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
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
as well as a related process called
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
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.
To get started setting up CI, CD,
or integrating GitHub with the tools you love,
visit
♪ (music) ♪