Professional Guides: Continuous Integration Continuous Delivery

♪ (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, 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
ascontinuous delivery, or CD, as well as a related process
calledcontinuous 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 calledwebhooksto 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, visitgithub.com/businessto learn more. ♪ (music) ♪

Norman Bunn


  1. Nice video. Refer this video for Continuous Integration Introduction https://youtu.be/t4tAyW3nwi0

  2. [2:50] WebHooks send messages to external systems about activity in your projects
    [4:48] Deployments API

Leave a Reply

Your email address will not be published. Required fields are marked *