Defining DevOps

Build Your
DevOps Practiceon GitHub

W R I T T EN BY G I T H U B W I T HWhat’s inside
3

Introduction to DevOps

4

DevOps fundamentals

12

The DevOps pipeline

17

Continuous integration and continuous
deployment concepts

31

DevOps planning, tools, and capabilities

41

Conclusion: DevOps as a framework todeliver value

42 Resources
43 Build your DevOps practice on GitHub

W R I T T EN BY G I T H U B W I T H

Introduction to DevOps
From headlines to job descriptions, DevOps
has emerged as an outsized buzzword overthe past decade–and for good reason.
Organizations that successfully adopt DevOps often see big
gains in software development speeds, improved reliability,
faster product iterations, and have an easier time scaling
their services.
But despite its roots in software development, DevOps is aholistic business practice that combines people, processes,
cultural practices, and technologies to bring previously siloed
teams together to deliver speed, value, and quality across thesoftware development life cycle (SDLC).

DevOps is a holistic business practicethat combines people, processes, cultural
practices, and technologies.
That means there’s often no one-size-fits-all approach.
But there is a common set of practices and principles
in any successful DevOps implementation. This e-bookoutlines core DevOps fundamentals and principles, as well
as how to implement a DevOps pipeline in an organization
to deliver increased value to customers. Guidance isthen provided for the tools that best complement anorganization’s DevOps practice.
GitHub approaches DevOps as a philosophy and set ofpractices that bring development, IT operations, and security
teams together to build, test, iterate, and provide regularfeedback throughout the SDLC.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 3

DevOps fundamentals
DevOps helps teams ship high-quality
products faster by reducing the friction
between writing, testing, and deploying code.
GitHub offers a holistic platform designed to helporganizations successfully adopt DevOps, making it easier
to continuously ship and improve software.
People often ask what a DevOps model is—but this misses
the point of DevOps. DevOps is an approach to building
software that touches the entire development life cycle. It’sa mix of practices, cultures, and technologies intended tocontinuously deliver value to end users.
In short, there is no one-size-fits-all approach to DevOps. Its
implementation varies from organization to organization.
Despite this, DevOps does have a framework of practices
that all organizations leverage in varying forms.
At the core of DevOps is the idea that everyone responsible
for a product should collaborate as a unified team. Rather
than work in separate development, quality assurance,
security, and operations silos, DevOps brings people together
to take end-to-end responsibility for planning, building,delivering, and improving software.
Compared to traditional development methods where
programming teams write code, testing teams find bugs,
and operations teams take care of the infrastructure,
DevOps can seem like a radical change. As a practice,
DevOps fundamentally seeks to transform organizations
by bringing traditionally siloed teams together across every
part of the SDLC.
Even though every organization’s DevOps adoption journeyis unique, these are key principles that indicate success. If
you do these things you’re doing DevOps well—but dependingon your industry, you’ll have things that are particular andnecessary to your DevOps practice.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 4

D e vO ps f u n da m en tals

DevOps principles defined
The implementation of DevOps will look different in everyorganization. GitHub believes it’s best to understand DevOps
as a framework for thinking about how to deliver value
through software. It’s more than a single methodology orcollection of processes. It’s fundamentally a set of principles—both cultural and technological. Let’s break that down:• Collaboration: To succeed, DevOps requires aclose working relationship between operations anddevelopment—two teams that were historically siloedfrom one another. By having these teams collaborateclosely under a DevOps model, you seek to encouragecommunication and partnership between theseteams to improve your ability to develop, test, operate,
deploy, monitor, and iterate upon your application andsoftware stack.
• Version control: Version control is an integral part of
DevOps—and most software development these days,
too. A version control system is designed to automaticallyrecord file changes and preserve records of previous
file versions.
• Automation: Automation in DevOps commonly meansleveraging technology and scripts to create feedback
loops between those responsible for maintaining
and scaling the underlying infrastructure and those
responsible for building the core software. From helping
to scale environments to creating software builds andorchestrating tests, automation in DevOps can take ona variety of different forms.
• Incremental releases: Incremental releases are amainstay of successful DevOps practices and are definedby rapidly shipping small changes and updates basedon the previous functionality. Instead of updating a wholeapplication across the board, incremental releases
mean development teams can quickly integrate smallerchanges into the main branch, test them for quality andsecurity, and then ship them to end users.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 5

D e vO ps f u n da m en tals

• Orchestration: Orchestration refers toa set of automated tasks that are built
into a single workflow to solve a group offunctions such as managing containers,
launching a new web server, changing
a database entry, and integrating a web
application. More simply, orchestration
helps configure, manage, and coordinate
the infrastructure requirements anapplication needs to run effectively.
• Pipeline: In any conversation about
DevOps, you’re likely to hear the term
pipeline thrown around fairly regularly. In
the simplest terms, a DevOps pipeline isa process that leverages automation anda number of tools to enable developers
to quickly ship their code to a testing
environment. The operations anddevelopment teams will then test thatcode to detect any security issues orbugs before deploying it to production.
• Feedback sharing (or feedback loops):
Feedback sharing—or feedback loops—is
a common DevOps term first defined in
the seminal book The Phoenix Project byGene Kim. Kim explains it this way: “Thegoal of almost any process improvement
initiative is to shorten and amplify
feedback loops so necessary corrections
can be continually made.” In simple

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

terms, a feedback loop is a process formonitoring application and infrastructure
performance for potential issues or bugs
and tracking end-user activity within theapplication itself.
These DevOps principles are paramountfor building a successful DevOps
practice. Successful, high-functioning
DevOps practices exhibit the following
characteristics and benefits:• 	Faster delivery and release cycles• 	More automation and increased
productivity• Increased quality through collaboration• 	More scalable products• Improved process scalability, wherecontinuous measurement drives
continuous improvement• Greater resilience in applications,infrastructure, and teams
These benefits translate to the ultimate goalof DevOps, which is to bring increased value
to customers and more productivity, as wellas collaboration between teams.

PAG E — 6

D e vO ps f u n da m en tals

Key stages in the DevOps
adoption journey
When building your organization’s DevOps practice,understand that it’s a journey, not a destination. Eachjourney will vary depending on what the organizationneeds. Organizations often start by implementing DevOps
practices at a small scale while evolving and becoming more
proficient over time. The stages in the table below show atypical evolution of an organization—from Experimental
DevOps where only a few teams are practicing DevOps to
Native DevOps where DevOps is adopted across the wholeorganization, silos are broken down and there’s an easy flowof information between teams.

Our philosophy is to build
automation and great DevOps
for the company you will
be tomorrow.”
Todd O’Connor
Senior SCM Engineer at Adobe

Experimental DevOps

Learned DevOps

Proactive DevOps

Native DevOps

One or two teams are
exploring DevOps.

Some parts of theorganization haveadopted collaborative
product teams.

All new products
start out under the
DevOps model.

DevOps is adopted acrossthe organization.

Role-based silos stilllargely in place.
Some experimentation
with automation but
manual intervention
needed for each step.
No formal process.

Those teams are using
DevOps tooling to goodeffect, but each teamhas its own approach.
Process is forming
and largely learned
from what otherorganizations
are doing.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

Measurements arein place to monitor
process effectivenessand feed into
improvements.
Process is starting
to become adapted
to the needs ofthe organization.
Most of the organization
is using DevOps tooling.

The DevOps process istuned precisely to theorganization’s needs,
with regular updates ascircumstances change.
Tests, builds, anddeployments are automatedusing DevOps tooling.
All teams are productfocused, with an easy flowof communication andcollaboration across theentire organization.

PAG E — 7

D e vO ps f u n da m en tals

For a DevOps practice to reach its full potential, it requires
buy-in from everyone in the organization. However, changes
can still be affected at a smaller scale within individual
product teams. This is reflected in the Experimental DevOps
stage. Often, other areas of the organization notice thesuccesses of the teams practicing DevOps and want to
replicate what they are doing. This is reflected in the Learned
DevOps stage. Organizations may then reach a point where
all new product development is following the DevOps model.
In this stage, the development and operations teams arein sync to form product-focused teams. This is reflectedin the Proactive DevOps stage. The Native DevOps stage
is the objective. Here, the process is well defined, andcommunication and collaboration flow easily across theorganization. In the Native DevOps stage, everyone in theorganization is working together to deliver increased value
to customers.

Foundational practices
How DevOps works varies from one company to thenext. But there are three core themes you’ll find in everyorganization that successfully adopts DevOps.

Everyone is responsible for quality
DevOps reduces the barriers between the disciplines foundin software development teams. Practitioners tend to focus
on building end-to-end products instead of completing
siloed, incremental projects. This means the same individual
will collaborate across the full SDLC, from planning tobuilding to testing and deploying a product.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 8

D e vO ps f u n da m en tals

Code ships when it’s readyTraditional software development practices often bundle
many changes into large releases. This means customers
typically wait longer for software updates. It also makes
it harder to predict the knock-on effect big code changes
will have, putting greater pressure on development andoperations teams. In contrast, DevOps favors incremental
code changes that are easier to build and test—and toship as soon as they are ready. Once a developer commits
code changes to a project, continuous integration anddeployment (CI/CD) tools facilitate automated tests,
application builds, and code integration or issue reporting.
Many DevOps practitioners extend the concept ofcontinuous improvement to their own work, measuring
and adjusting their processes over time.

Automation improves quality andpredictability
In a successful DevOps practice, anything that can be
automated should be automated. This reduces the risk ofhuman error and makes products easier to scale. Tools
are used to automate the configuration and deployment of
infrastructure, while static analysis tools find and highlightsecurity vulnerabilities. DevOps practitioners strive toautomate repetitive tasks at every stage.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 9

D e vO ps f u n da m en tals

DevOps maturity
Introducing DevOps to your organization is an ongoing
journey with different levels of adoption across the manydifferent stages of product delivery. DevOps is as dynamic as
a business needs it to be, and its implementation varies fromorganization to organization.
This means there isn’t one defined DevOps maturity
model. At GitHub, we shy away from talking about DevOps
maturity models because it implies there’s a checklist any
organization can use to achieve “DevOps.” This isn’t true. At
its core, DevOps is an ongoing practice. However, there arecommon steps and markers of success businesses canwork toward, as shown in the following figure.

Figure 1: The DevOps maturity modelThis DevOps maturity model diagram should be used toroughly plot where an organization is currently at and what it
takes to reach the next level. Whichever stage of the maturity
model an organization is currently at, the key concept
is promoting an environment that fosters collaboration,
continuous learning, and iterative improvement.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 1 0

D e vO ps f u n da m en tals

The next section introduces the idea of the DevOps pipeline
and the tools and practices that make up each stage. Keepin mind the definition of DevOps—bringing together people,
processes, cultural practices, and technologies in softwaredevelopment. It’s important to note that technology ismentioned last and is only one piece of the overall picture.
Technology can certainly help influence and optimize your
DevOps practices, but people and culture are at the heart. An
organization could have state-of-the-art DevOps tools, but acollaborative culture is required for the benefits of DevOps tobe fully realized.

“The mindset we carry within our team is that
we always want to automate ourselves into abetter job.”
Andrew Mulholland // Director of Engineering at Buzzfeed

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 11

The DevOps pipeline
A DevOps pipeline is a combination of
automation, tools, and practices acrossthe SDLC to facilitate the development anddeployment of software into the hands of
end users.
Critically, there is no one-size-fits-all approach to buildinga DevOps pipeline and they often vary in design andimplementation from one organization to another. Most
DevOps pipelines, however, involve automation, CI/CD,
automated testing, reporting, and monitoring.

We have a slogan on our
team: don’t let a human doa machine’s job. GitHub helps
us achieve that.”
Gabriel Kohen
Principal Software Engineer
at Blue Yonder

Important concepts in any successful DevOps pipeline arethat it’s repeatable, continuous, and always on. Nothing ina DevOps pipeline should be an isolated event, but instead
comprise a larger system where each step is defined by
its repeatability.
Importantly, building a DevOps pipeline is often one of themost tangible elements for organizations looking to adopt
DevOps, which is defined as much by its cultural dimensionthat favors deep collaboration as it is by automation andspecific tooling.
With the right technology and investments in people andprocesses, any organization can build an always-on DevOps
pipeline—even if it’s a simple one to start with. But without
fully adopting a DevOps culture that prioritizes incremental
development work and deep, cross-functional collaboration
across the SDLC, organizations are unlikely to realize the fullvalue of a DevOps pipeline.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 1 2

T he D e vO ps pipeli n eStages of the
DevOps pipeline
A common way people often explain a DevOps pipeline isby comparison to an assembly line. Each part of the SDLC
is analyzed to establish a consistent set of automated andmanual processes. The result is improved efficiency andconsistency in terms of the overall output.
But unlike an assembly line, DevOps isn’t an end-to-end
process with a definite beginning and end. Instead, DevOps
is a cycle of continuous improvement where even after
software is shipped, improvement continues.
In practice, that means that even as a new software featuremight take a linear path through stages of development, theoverall system (and even that feature) goes througha continuous cycle of iteration.

Figure 2: A DevOps pipelineB U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 1 3

T he D e vO ps pipeli n e

To understand this, it helps to break down
the stages of a DevOps pipeline and how
they feed back into one another:
1. Plan: Every DevOps pipeline starts in theplanning stage, where new features orfixes are introduced and scheduled. At
this stage, the primary goal is to ensure
people who play different roles within thelarger DevOps practice are collaboratingfrom the start—and that means working
together to understand user needs,
design a solution, understand theimplications of the change, and ensure
it fits smoothly into the existing system.
Learn how to use GitHub for projectplanning with GitHub Issues.
2. Code: In the coding stage, organizations
begin writing code according to the planand track their work via a version control
system such as Git. At this point in a
DevOps pipeline, developers may use
a number of tools in their development
environment to introduce consistency
in code styling and identify any potential
security flaws. This might include utilizing
tools such as a cloud-hosted integrated
development environment (IDE), which
are often used to introduce consistency
across development workflows andincrease the speed at which coding
environments can be spun up. Find out
how developers code on GitHub.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

3. Build: The build stage is when a DevOps
pipeline fully kicks into gear and begins
once a developer commits code changes
to a shared repository. At this point, adeveloper may submit a pull request
to merge their code changes with thecodebase. This will alert someone elseon the team to review their code before
approving the merge. At the same time,a typical DevOps pipeline will initiate anautomated build process that merges
the codebase and begins a series ofintegration and unit tests. If any of thesetests or the build itself fails, the pull
request will also fail, and the developer
will get a notification about the issue. Thislevel of workflow automation in a DevOps
pipeline helps organizations mitigate any
potential build integration problems andidentify any bugs or security issues at an
earlier point in the SDLC. See how GitHub
enables CI/CD for code integration andapplication building.
4. Test: After a build is approved, thetesting stage in a DevOps pipeline
begins and the build will be deployed
to a testing environment that closely
mirrors the production environment.
Some organizations may elect toadopt infrastructure-as-code (IaC) in
their DevOps pipeline to automate theprovisioning of a testing environment
for staging. Others may have dedicated,

PAG E — 14

T he D e vO ps pipeli n e

pre‑built testing environments readyfor any new build—the choice largely
depends on an organization’s needs andcomputing resources. Once the build isdeployed to the test environment, it will
be subject to a number of automatedand manual tests. This may include
automated security tests such as
dynamic application security testing(DAST) and interactive application
security testing (IAST) to identify any
vulnerabilities or risk areas. It can also
include manual user acceptance testing(UAT) where team members will use
the application and note any potential
problems or bugs a customer may
encounter. Every organization will haveits own unique automated and manual
testing suite and strategy during thetest stage in its DevOps pipeline. But
this stage, critically, provides a space fororganizations to apply their tests without
disrupting the development workflow.
Learn how to use GitHub to build acontinuous testing pipeline.
5. Release: The release stage marks thepoint in a DevOps pipeline where a newbuild has been fully tested and is readyto be deployed. In addition to the code
itself having been tested, its operational
performance has also been cleared,leaving organizations confident that it will
successfully run in production without
being affected by any undiscoveredbugs or issues. At this stage, someB U I L D YO U R D E VO P S P R AC T I C E O N G I T H U Borganizations will elect to automatically
deploy code when it reaches thisstage in a practice commonly called
continuous deployment. This is how
some software teams deploy several
code changes a day. Others may
instead decide to manually release a
new build into production and include a
final approval stage, and still others willschedule automated releases to happen
on certain days or at certain times. CI/
CD platforms and other DevOps tools
enable organizations to build a releasecadence that best works for them—andapply automation throughout the releasestage in their DevOps pipeline. See how
companies release software on GitHub.
6. Deploy: Once a build has been released,
it should be ready to deploy into
production. At this stage in a DevOps
pipeline, organizations will leveragea number of tools to automate thedeployment process by provisioning
new production environments via IaC ororchestrating a blue-green deployment(this is where code changes are slowly
rolled out to a percentage of users in a
new environment while the old codebase
remains operational for other users ina separate environment). A blue-green
deployment strategy also enables
organizations to quickly migrate users
back to an old build in the event thatanything goes wrong. Learn how to deploy
your code with GitHub.

PAG E — 1 5

T he D e vO ps pipeli n e

7. Operate: A DevOps pipeline doesn’t end
once an application is deployed—that’s
when the operational stage begins,
and organizations need to make sureeverything is running smoothly. This stage
includes infrastructure orchestration andconfiguration settings that will enforce
rules to automatically scale resources
to meet real-time demand. It also willoften include mechanisms to captureuser activity within the application suchas behavioral logging and customer
feedback forms. The goal in the operations
stage is implied by the name of the stage:
to successfully operate the application
and underlying infrastructure and seekout ways to improve the operational
profile of the software itself. Learn how
GitHub enables software operations.
8. Monitor: Building upon the operational
stage of a DevOps pipeline, organizations
will set up automated monitoring
tools to identify potential performancebottlenecks, application issues, anduser behavior. This stage requires
implementing tooling to collect dataon application and infrastructure
performance and then pass actionable
items back to the product teams toeither resolve outstanding issues or

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U Bdevelop new features to support existinguser behaviors in the application. Even
though this is the last stage of a DevOps
pipeline, it’s important to understandthat the process itself is continuous—i.e.,
monitoring tools help organizations
identify areas for additional planningand iteration to feed back through the
DevOps pipeline. Each stage feeds into
the next in an infinite loop. Find out how
GitHub gives organizations advanced
monitoring capabilities.
Each of these stages makes up a partof the overall DevOps picture. As thediagram depicts, each of these stages
flows to the next in an infinite loop. It requires
diligent effort in each of the stages foran organization to transform itself into awell-oiled DevOps machine. As the stages
in the DevOps pipeline become morenatural for an organization, they will bringincreased value to customers faster withimproved quality.
Automating as much of the process
as possible, from code to production, isfundamental to DevOps. The next section
discusses the concepts of CI and CD, andhow they fit into the DevOps pipeline.

PAG E — 1 6

Continuous integrationand continuous
deployment concepts
Continuous integration (CI) is a foundational
DevOps practice where development teams
integrate code changes from multiple
contributors into a shared repository.
Continuous deployment (CD) is an
automated software release practice wherecode changes are deployed to different
stages as they pass predefined tests.

CI/CD with GitHub Actions
allows us to build, test, anddeploy right from GitHub.
We’ve reduced build timefrom 80 to 10 minutes.”Engineering Architect
at Pinterest

CI enables organizations to quickly identify defects andship higher-quality software faster, and the goal of CD is tofacilitate faster releases by using automation to help remove
the need for human intervention as much as possible during
the deployment process. Together they are often referred to
as CI/CD.
The next few sections discuss the concepts of CI/CD as wellas guidelines organizations should follow to yield the best
results. CI and CD make up a large part of the overarching
DevOps pipeline, encompassing code from when is firstwritten, built, and tested, all the way through release.
Additionally, the topics of containerization and security in
DevOps (DevSecOps) are introduced, and we’ll see how they
can play a crucial role in a DevOps organization.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 17

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts

Continuous integration
CI seeks to encourage faster and more efficientdevelopment cycles by solving a key problem in softwaredevelopment: managing code integration challenges
in a shared repository with multiple contributors.
When a developer begins working on a software update
or fixing a bug, they make a copy of the codebase to workfrom. This is done via a version control system such as Git,
which enables developers to create a copy of, or “fork,”
the codebase.
As more developers create codebase copies, integrating
the changes from multiple contributors can becomechallenging—especially when the codebase that one
developer started working from becomes dated andno longer matches the main repository.
In a worst-case scenario, it can take longer to successfully
integrate code changes than to make the changes
themselves as each developer tries to untangle where
their code is not matching up. Developers often call this“integration hell.”
CI seeks to prevent this by encouraging developers tointegrate changes as they make them. CI also leverages
automation to increase the speed at which code is integrated
and tested to ensure no additional changes are needed,
reducing the burden for a developer. This combination of
more frequent code integrations and automated builds andtesting helps speed up the software development process.
Every company will define its CI practice per its unique needs.
Some companies may introduce more rigorous automatedsecurity tests; others may prioritize fast code merges andreserve more time-consuming automated tests for later in
the SDLC.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 1 8

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts

Despite this, effective CI pipelines share a
set of common tools and best practices.
These include:• A shared code repository: A shared code
repository in a version control system isfoundational to creating an effective CI
practice. Beyond serving as a place tostore code, scripts, automated tests, andeverything in between, version control
systems also enable developers to create
multiple branches from which to work.
• Regular code commits: Automation,
testing, and tooling are important for
creating an effective pipeline—but without
a team cultural shift that prioritizescommitting code changes often, you’reunlikely to get very far. There are no hardand fast rules for how often developers
should be committing code. A good ruleof thumb, however, is that the more often
individuals commit changes, the moreproductive the development environment
will be.
• Build automation: Build automation
is a critical component of a CI pipeline
and enables teams to standardize theirsoftware builds. A typical build processincludes compiling source code,
generating software installers, andensuring that all the necessary items
are in place to support a successful
deployment. In a CI practice, thisprocess is automated to help integrateincremental code commits into
the codebase.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B• Automated testing: You can makelots of code commits and have a fully
automated build process. But justbecause a program runs, it doesn’tmean it’s running correctly. That’s where
testing comes in. Automated testing isa key part of CI pipelines. Each commit
triggers a set of tests to identify bugs,
security flaws, and commit issues. These
tests are meant to keep the main code
branch operational, or “green,” and give
rapid feedback to developers about theefficacy of their code changes. No two
CI models are alike. Every organization
will implement CI according to its uniqueneeds and team requirements.
There are, however, some common
steps every organization needs to take toimplement CI successfully. These break
down into five practices:
1. Create a testing strategy: Every CI
practice starts with a cogent and clear
testing strategy. You’ll need to consider
what types of tests you’re running, what
triggers you use to build your automatedtesting sequences, and which tests
you apply to each coding branch yourdevelopment teams will work on.
2. Choose a CI tool: Choosing a CI platform
is a critical part of building a CI modelin any organization. This is the tool thatwill trigger your automated builds, tests,
packages, and releases.

PAG E — 1 9

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts

You’ll want to ask several questions whenselecting a CI platform. These include:

How does it map to your security
requirements?

How well does it integrate with your current
technology stack?

Security is a critical consideration with any
technology investment—especially if thatinvestment will end up deeply integrated
with your codebase and core services.

From your programming languages to yourversion control system to your third-party
tools, a CI platform should easily integratewith everything in your stack. It’s also worth
considering any future technologies you
might adopt and looking for a platform thatcan grow with you.
Does it offer native support for containers?
Containers are a critical part of a DevOps
and CI practice and making sure your CI
platform has native support for container
applications such as Docker is critical.
You might not leverage containers today,
but as you grow your DevOps practicethere’s a good chance you will end up using
containers in some capacity.
Does it enable matrix build
testing capabilities?
Matrix builds enable you to simultaneously
test builds across multiple operating
systems and runtime versions. Look for a
CI tool that has native support for matrix
builds, which help streamline your testingand ensure your application will work for allof your end users.
Does it offer built-in code coverageand testing visualization?

3. Integrate code as soon as possible:
Successfully adopting CI starts withmaking sure your developers areintegrating their code as soon as possible
to a shared repository.
There are two benefits to this:• You avoid larger integration conflicts that
can arise when merging older branches
back to the main repository.
• You end up regularly integrating smaller
code changes, which helps withknowledge transfer between your teams
and simplifies your testing regimen.
You should also consider what your existing
SDLC looks like today, and what changes
you might want to make procedurally
moving forward as you implement a CI
pipeline. This isn’t a conversation about
whether feature branching or trunk-based
development is better either. Instead, it’s
about making sure you have an organizeddevelopment workflow that facilitates a
steady stream of coding, testing, merging,
and reviewing.

Code coverage and testing visualization give
you a simple way to see how much of yourcodebase is currently being tested and how
existing tests are running in real time andhave run historically.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 2 0

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts

5. Build new tests for every new feature
you introduce: Under a CI model, yourtesting suite should grow with yoursoftware or application. That means thatas you build new features and prepare
larger updates, you should also bebuilding tests to validate these features.
Consider writing tests as you build newfeatures and fix bugs. This might feel time
consuming—but going back after thefact will almost certainly take longer thanwriting tests as you build code.

Figure 3: The stages of the SDLC

4. Fix your main branch as soon as it
breaks: As a rule of thumb, you should
fix your main branch as soon as it
breaks. In a CI model, your developers
should be integrating code changes assoon as possible. That’s a good thing.
But if a code change breaks your mainbranch and your developers keep adding
more changes, it becomes difficult to
identify what caused the initial failure.
To do this, write tests that immediately
notify developers when one of their codechanges breaks the main branch. This
helps create a feedback loop, which is an
important DevOps practice. Make sure
to balance testing speed with testing
coverage when it comes to keeping yourbuilds green, or operational. If your tests
take too long to run, it becomes harder
to pinpoint what code change led to a
failure. The best testing suites start withsimple tests such as build and integration
tests before advancing to more timeconsuming tests.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

The idea behind CI is to integrate code asoften as possible, in small chunks. It’s easierfor developers to merge a code branch that
contains a single new feature or hotfix than
it is to merge several branches that haveweeks’ worth of work. When CI concepts
are being followed, it is easier for teams
to pinpoint which bit of code broke thebuild or caused the tests to fail. This allows
developers to spend more time creating
value instead of troubleshooting build errors.
With CI, code is integrated early and often
to minimize merge conflicts that occur
when multiple developers are working
on the same codebase. The next section
introduces the next step in the process:CD. With CI and CD working together,
organizations can build, test, and deploy
code often and with confidence.

PAG E — 2 1

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts

Continuous deployment
Continuous deployment, or CD, is one of the more advanced
examples of automation in a DevOps practice. It requires a
mixture of rigorous testing, deep cross-team collaboration,
advanced tooling, and workflow processes across theapplication design and development process.
And when it’s successfully implemented, it works. DevOps
organizations that adopt CD have been found to ship code
faster and outperform other companies by 4-5x.
DevOps seeks to increase the speed of innovation and value
delivery by applying automation to every stage of the SDLC.
With that view, CD stands as the ultimate goal of DevOps: acompletely automated SDLC where every code change ispushed to production if it passes a predefined set of tests.

Figure 4: Continuous deployment in practice

In some ways, building an automated pipeline is one of
the easiest parts of adopting a CD model. But very few
organizations start their DevOps journey by building a CDpractice due to the cultural change it signifies, and thematurity of the testing suite it requires.
In that light, it’s best to understand the process and journeyof achieving a fully functioning CD practice.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 2 2

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts

Figure 5: Steps to automation in CI/CD

Figure 5 shows a high-level journey map for
how organizations typically start thinking
about automating the SDLC.
To start, organizations need to build a CI
practice. The foundational elements of astrong CI practice—regular code commits,a testing strategy, version control tooling,
and a CI platform—set the stage fororganizations to begin developing a
CD practice.
At its most basic, CD brings automatedbuilds, tests, and deployments together
in a single release workflow. The goal is
to automate the deployment of software
builds into production. Each company
needs to identify the right combinationof unit, functional, and stress tests thatcomprise its testing suite. It’s also criticalto mirror production environment pressuresin a pre‑production environment toeffectively stage and test builds andrelease candidates.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

Getting all of this right leads to a significant
payoff: faster and more stable releases. It
also positions organizations to achieve CDwith a fully automated CI/CD pipeline.
Ideally, a DevOps practice becomes sofine-tuned across its testing regimen,
automation triggers, workflow composition,
and CI/CD platforms that it naturally
leads to CD. In effect, the need for humanintervention to orchestrate a software
release dissipates over time.
In practice, however, achieving a durable
and scalable CD model takes significant
investments in engineering resources andtooling. And while CI/CD platforms andassociated tooling go a long way to standing
up a CD practice, a cultural change thatemphasizes cross-team collaboration andregular code commits is critical.

PAG E — 2 3

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts

Stages in the CD pipeline
There is no singular “model” for CD. Everyorganization will build a CD pipeline uniqueto their needs, software development
practices, and customer demands.
Despite this, there are four commonly
accepted stages in any CD pipeline thatevery organization should build into theirengineering plans. These include:
1. Verification: CD builds upon CI—and
it’s at this stage that CI stops, andCD begins. After a new piece of code
is committed and integrated into thecodebase, this triggers the automatedverification process that runs a seriesof tests on a release candidate build.
This can include functional, integration,
security, and production-level testing
to ensure a release candidate will work
following deployment.
2. Deployment: Once code is verified via
testing, the automated deployment
process begins. More advanced
implementations will typically create
automation workflows that move code
to deployment immediately after it iscommitted (of course, this assumes it
passes all predefined tests in the
CI stage).
3. Monitoring: Continuous monitoring is a
critical element that organizations needto invest in to support CD. Monitoringshould take place across the SDLC.
But the ability to see what is and is notworking and receive real-time alerts
before, during, and after deployments

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

is key. Tooling that helps teams visualize
performance metrics and show systemstrains is one helpful investment.
4. Response: Whether it’s addressing
a production-level system error or
identifying a security incident or apotential new feature for development,
being able to respond to events is a
critical element of a CD pipeline. A
benefit of CD is that code is immediately
released into production. This also meansthat organizations need to be prepared
to respond to and address any issues
that emerge after deployment. Common
metrics used to evaluate response times
include mean time to resolution (MTTR),
which organizations will track to evaluate
improvement over time.
Gone are the days when software waspredominately distributed by floppy disks
or CDs. With the advent of cloud-based
hosting solutions and technologies,
practicing CD concepts allows
organizations to actively deliver value tocustomers through software updates.
This doesn’t necessarily mean that every
DevOps organization needs to deploy
code to production dozens of times a day.
Instead, the idea is that organizations
can deploy as soon as the code is ready.
Deployment to production is a non-eventin organizations with a successful DevOps
practice. The code that is being deployedis relatively small in function, has alreadybeen rigorously tested, and deployment
automation leaves no room for human error
in the deployment process.

PAG E — 24

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts

Containerization
It’s not just code where problems can arise.
What works on one person’s machine
might behave differently on a colleague’s
laptop—or worse, on a production server.
Containerization is one type of technologythat can be used in DevOps practices
to ensure that the software environment
is consistent from one machine to anotherduring development, testing, and on
into production.
Containerization packages software codewith dependencies and an operating systemin the form of a standalone applicationthat can be run on top of anothercomputer. These virtualized environments
are lightweight by design and requirecomparatively little computing power.
They can also be run on any underlying
infrastructure and are portable or are able
to be consistently run on any platform.
By bundling application code, configuration
files, operating system libraries, and all
dependencies together, containers help
solve a common problem in softwaredevelopment: code that is developed in
one environment often exhibits bugs anderrors messages when transferred toanother environment. A developer may, forinstance, build code in a Linux environment
and then transfer it to a virtual machineor Windows computer and find their code
no longer works as expected. In contrast,
containers stand alone from the hostinfrastructure and provide consistentdevelopment environments.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

But what makes containers particularly
useful is that they are easy to share. By
using container images—files that act
as a snapshot of the container’s code,
configuration, and other data—you canquickly spin up consistent environments
across each stage of the SDLC. This
helps organizations create reproducible
environments that are fast and easy to workwith from development through testing andon into production.
Now that we have a base understandingof what containers are, the next section
highlights the benefits containerization
brings to DevOps. Afterward, we discuss the
specific aspects of CI/CD where containers
can have the most effect.

The benefits ofcontainerization in DevOps
At the heart of DevOps are lightweight,
repeatable processes that automate thesoftware development process. However,modern applications are increasingly
complex, particularly as they grow to include
many different services.
Containers help simplify that complexity
through greater standardization andrepeatability—and that translates to a faster,higher-quality, more efficient SDLC. GitHub
provides tools that help companies adopt
and manage containers in their DevOps
practice. Through this experience, GitHub
has identified key areas organizations
need to consider to successfully integratecontainers into their SDLC.

PAG E — 2 5

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts

The benefits of containerization include:• Portability: Even seemingly small
differences in the underlying environment
can impact how code runs. That’s why thesaying “It works on my machine” is rarely
meaningful—and is often somewhat of ajoke. It’s also why the saying “Write once,
run anywhere” has been a recurring goalfor people looking to improve softwaredevelopment practices. Containers
help organizations accomplish this bybundling up everything an applicationneeds into consistent and portableenvironments that make it easier tostandardize application performance.
• Scalability: Containers can be deployed
and configured to work with one anotherin a larger system architecture throughthe use of orchestration management
tools such as Kubernetes. These
tools can also be used to automate
the provisioning of new containerizedenvironments to scale with real-time
demand. That means properly configured
containerized environments can be
rapidly scaled up—or scaled down—withlittle to no human intervention.
• Cloud-agnostic: When configured for
portability, containers can run anywhere—
whether that’s a laptop, bare metal server,
or cloud provider platform. And because
containers abstract away underlying
platform differences, they mitigate therisk of platform lock in. You can also use
containers to run applications acrossmultiple cloud platforms and switch fromone provider to another.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B• Integration into the DevOps pipeline:
Containerization platforms are often
designed to be inserted into larger
automation workflows. That makes them
ideally suited to DevOps where CI/CD
tools can create and destroy containers
automatically for tasks such as testing oreven deployment into production.
• Efficient use of system resources:
Unlike virtual machines, containers areoften more efficient and require lessoverhead. There’s typically no hypervisor
or additional operating system that’s
native to a container. Instead, container
tools provide just enough structure to
make each container a standalone
environment that leverages the sharedresources of the host system wherever
possible—and that includes theunderlying operating system, too.
• Facilitate faster software releases:
Containers can be used to simplify
larger and more complex applications
by dividing their underlying codebases
into smaller run-time processes thatwork together. This helps organizations
accelerate each step of the SDLC
because it enables practitioners tonarrow their focus to a specific part of an
application rather than working with theentire, wider codebase.
• Flexibility: Containers bring inherent
flexibility to the SDLC by enablingorganizations to quickly provision morecomputing resources to meet real-time
demand. They are also often used tocreate redundancies to support greaterapplication reliability and uptime.

PAG E — 2 6

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts• Improved application reliability andsecurity: By making the application
environment part of the DevOps pipeline,
containers face the same quality
assurance as the rest of the application.
And although containers work together,
the isolated environment provided bya container makes it easier to prevent
issues in one part of the application from
impacting the wider system.

2. Test: Containers can be quickly
provisioned and retired as necessary.
Rather than needing to manually
maintain explicit test environments or
wait for configuration scripts to build
an environment, a container can beprovisioned and deployed automaticallyat scale. That way, tests run faster andwith less need for human intervention
to build test environments.

Containers provide a modern way to develop
software efficiently at scale. They provide
flexibility and repeatability that pair well with
fundamental DevOps practices. In the next
section, we will explore how containers canenhance the CI/CD process.

3. Release: Once all the tests pass,a CI/CD pipeline’s build phase results
in a container image that is then stored
in a container registry. Once that image
exists, much of the work that would
usually take place in the release anddeploy phases is already complete.
Orchestration tools such as Kubernetes
then take care of managing where
the containers are deployed and how
they interact.

How containers workin CI/CD
A CI/CD pipeline can be thought of as
the conveyor belt that drives the DevOps
workflow. To be effective, a CI/CD pipeline
must balance speed with thoroughness.
Without speed, a CI/CD flow risks backlogs
as commits occur faster than they canmake it through the pipeline. Without
thoroughness, people will lose faith in the CI/
CD pipeline as problems slip into production.
Here’s how containerization boosts bothaspects of CI/CD at key stages:
1. Integration: By using containers,
you don’t have to start from scratchwhen integrating code changes to thelarger codebase. You can create abase container that already holds theapplication’s dependencies and modifythat during the integration phase.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

The usage of containers in a DevOps CI/
CD workflow for their predictability andscalability reflects foundational DevOps
principles. While using containers is not
an absolute requirement of DevOps,
organizations that use containers effectively
tend to be higher functioning on the DevOps
maturity model. Containers are seen as anatural fit to reduce the friction of modern
application development by allowing
increased consistency and repeatability. It is
this consistency and repeatability, along withreliability, that is essential for any successful
DevOps practice.

PAG E — 2 7

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts

Security in DevOps(DevSecOps)
DevOps has transformed how manyorganizations build and ship software.
But until recently one aspect of the SDLC
has remained outside DevOps: security.
DevSecOps seeks to correct that by baking
security into the SDLC in the same waythat DevOps prioritizes quality, speed, anddeep collaboration throughout all stages ofsoftware development.
DevSecOps seeks to build security into
every step of the SDLC. This ideally meansthat security-related tests (automatedand not) take place at each stage fromcoding to merging branches to builds,
deployments, and on into operation of
production software. Moreover, DevSecOps
advances the idea that everyone working
on a product is accountable for its security.
This helps teams catch vulnerabilities before
they make it to production and reduces theneed for late-stage, manual security reviews,
which can slow down software releases.
Organizations that adopt DevSecOps
typically see advantages that include:• Reduced risk of data breaches:
DevSecOps seeks to make code
secure by design. A combination of
secure coding cultural practices, securedeveloper environments, and automatedsecurity tests throughout the SDLC
help reduce the chances of security
vulnerabilities or flaws making it into
production software.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B• Improved compliance: DevSecOps
practitioners often use automation to
enforce code compliance and integrate
policy enforcement tooling directly into
the CI/CD pipeline.
• Greater confidence in dependencies:
The modern technology stack depends
heavily on third-party code, often frompublic package repositories. DevSecOps
practitioners frequently leverage toolingand automated tests to identify potential
issues before a software release.
• Value gets to end users faster:
By creating a security-first culture
and applying automated checks,
DevSecOps reduces the need for
distinct security reviews that slow
down code deployments.
Building a successful DevSecOps practicerequires building security in every stage of
the SDLC. This varies from one organization
to another, and often different industries
will have different regulations that mustbe followed. With DevSecOps, building
security into each phase of the SDLC
doesn’t mean implementing onerous
controls, which can slow down softwaredevelopment. Quite the opposite. Security
in effective DevSecOps practices becomesa part of the release itself, leading to fasterand more secure deployments.

PAG E — 2 8

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts

Best practices
DevSecOps argues that security needs tobe embedded across the SDLC. Whether
your organization already practices
DevOps or you’re looking at how to adopt a
DevOps culture, here are the foundational
best practices you need to establish a
DevSecOps practice:• Create a DevSecOps culture: Successin DevSecOps relies on everyone taking
responsibility for security. That means
each person in the SDLC codes, builds,
tests, and configures application andinfrastructure settings defensively. Just
like DevOps, DevSecOps thrives in an
open culture where each individual works
together to build the best and mostsecure product possible.
• Design security into the product:
DevSecOps seeks to design security
into products from the initial planningstages to deployed production-level
code. This means security work isplanned alongside feature work, andpractitioners are provided security
knowledge and testing throughout eachstage of their development work. The goal
is to make security an everyday part ofyour team’s work.
• Build a threat modeling practice:
The seeds of security vulnerabilities
are often sown before a line of code iswritten. Model potential threats during
the planning phase and design yourinfrastructure and the application’s
architecture to mitigate those issues.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

And periodic penetration testing, wherea trusted person attempts to break into
your system, can help unveil weaknesses
you may miss in your threat models.
• Automate for speed and security:
Automated testing is used throughout theSDLC to ensure the right security checks
happen at the right time. That gives
people more time to focus on building
the core product while ensuring security
requirements are met.
• Plan security checkpoints in yourproduct development: Identify transition
points in your SDLC where the risk profilechanges. That could be the point at whicha developer merges their code into themain branch, which might increase thepotential for that code to be run on themachines of colleagues and eventuallyreach production. In that case, opening apull request might be a good trigger event
for automated security checks, along withthe appropriate manual escalations.
• Approach security failures as learning
opportunities: Building on DevOps’
culture of continuous improvement, a
successful DevSecOps practice strives
to turn security incidents into learning
opportunities. This can be accomplishedby leveraging audit logs, building incident
reports, and modeling malicious behavior
to improve tooling, testing, and processes
to further secure your applications
and systems.

PAG E — 2 9

C o n ti n u o u s i n tegratio n a n d co n ti n u o u s deploy m en t co n cepts• Stay on top of dependencies:
Understanding and mitigating thepotential threats from dependencies
is critical to your product’s security.
Apply the same threat modeling andautomated testing to your dependencies
as to your in-house code. GitHub has
identified and shared details of tensof millions of threats in open-source
software, helping organizations anddevelopers be more aware of andavoid vulnerabilities.
• Build your analytics and reporting
capabilities: Continuous monitoring is a
critical part of a DevSecOps practice—and that includes real-time alerts,
system analytics, and proactive threat
monitoring. By measuring every aspectof your application and your DevSecOps
pipeline, you can create a common
point for understanding application
health. Reporting dashboards and alerts
highlight problems early. When a problem
does occur, the telemetry you’ve set
up—such as application-level logging—
provides insight for incident resolution
and root cause analysis.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U BCreating a DevSecOps culture begins bymaking security everyone’s responsibility.
This can be a big change for manyorganizations. Traditionally, security wassomething developers left in the handsof security professionals. There was often
friction since engineering teams looked
at security practices as an impediment toshipping software fast. In more extreme
cases, security was merely a rubber stampin the process.
DevSecOps fundamentally seeks to change
this perception by making security as coreto the SDLC as writing code, running tests,
and configuring services. Just like how the
DevOps model brought developers andoperation teams together, DevSecOps
brings security to the forefront. Each newfeature or fix begins with considering
its security implications. Security andcompliance policies are enforced throughautomated tests. For modern organizations,
DevSecOps becomes just “DevOps”:
security is baked into all aspects of theSDLC workflow.

PAG E — 3 0

DevOps planning,
tools, andcapabilities
Automation, continuous monitoring, andcontinuous feedback are essential parts of
the DevOps model.
As an umbrella term, DevOps tools include any number
of applications that automate processes within the SDLC,
improve organizational collaboration, and implementmonitoring and alerts. Organizations will often invest inbuilding out a “DevOps toolchain,” or collection of tools to use
in its DevOps practice, to address each stage of the SDLC.

Our philosophy is to build
automation and great DevOps
for the company you will betomorrow.”
Todd O’Connor
Senior SCM Engineer at Adobe

A DevOps toolchain is a core tenant of any DevOps practice,helping organizations apply automation to the SDLC andimprove their ability to deliver higher-quality software faster.
It’s also one of the more tangible aspects of DevOps.
Some organizations will invest in an “all-in-one” platform tobuild their DevOps toolchain. Others will integrate different
best-of-breed solutions to create a toolchain. But critically,
there is no one-size-fits-all approach to DevOps or building a
DevOps toolchain.

Guide to tools
Each stage of the DevOps pipeline has uniqueconsiderations that one or many tools can help solve.
Over the next few sections, all eight stages of the DevOps
pipeline are reintroduced along with various considerations
to keep in mind when selecting tools. A single tool might
account for several stages of the DevOps pipeline.
Conversely, a single stage in the DevOps pipeline can be
represented by multiple tools. Regardless of the tools being
used, the most successful organizations are going to havecohesive flow and integration between each of the stages
in the DevOps pipeline.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 3 1

D e vO ps pla n n i n g , tools , a n d capabilities

In this section, we’ll look at how DevOps
tools can shape your strategic planning,communication, and roadmap for the future.

DevOps planning andcollaboration tools
In large part, DevOps seeks to bringpreviously siloed teams together acrossall stages of the SDLC—and that starts at
the planning stage. From chat applications
to project management tools, there are
a number of tools organizations canimplement in their DevOps toolchains tobetter align and encourage collaboration inan organization during its planning stages.
DevOps planning and collaboration tools
generally fall into two buckets:• Product and roadmap planning: Having
a centralized place to plan, track, andmanage work is a foundational capability
for any modern development team—and
DevOps organizations, too. The best tools
help organizations build plans, sprints,
and roadmaps while being able to assign
and track work from the initial plans
to the delivered end product. Need an
example? Try looking at our own public
product roadmap plans, which we buildusing projects on GitHub.
• Team communication: Maintaining
communication throughout the planning
process is key to spurring collaboration—and having a preserved record ofconversations that led to a given decision
can be incredibly helpful. Tools such as
GitHub Discussions, chat applications,and issue trackers that enable teamB U I L D YO U R D E VO P S P R AC T I C E O N G I T H U Bconversations are key here. GitHub
provides apps to help your team integratewith Slack or Microsoft Teams. The
best tools will integrate with your projectplanning, too. That means you can turna discussion into an executable piece ofwork or turn an idea into a discussion if
more conversation is needed before work
can start.

DevOps build tools
Once developers commit code changes toa central repository, the build stage begins—
and that means using version control tocreate shared repositories, provisioning
development environments, and integrating
code, among other things.
At this stage, organizations can typically takeadvantage of the following DevOps tools:• Version and source control: A
version control system is designed toautomatically record file changes andpreserve records of previous file versions,which enables code rollbacks, historicalreferences, and multiple code branches
allowing developers to collaboratively
code and work in parallel. Platforms
such as GitHub offer version control
and source control with features suchas pull requests, which enable individual
developers to get reviews on proposed
code changes before they are integrated
into the main code branch. The best
version and source control platforms
integrate with your broader DevOps
toolchain and enable product teams
to collaborate across the SDLC.

PAG E — 3 2

D e vO ps pla n n i n g , tools , a n d capabilities• Pre-production development
environments: In a DevOps practice,developers need to leverage virtualenvironments that mirror production as
closely as possible. These environments
are identical to one another and easy
to provision, so that all developers canquickly build and test code changes inconsistent environments. Organizations
will often leverage containerization
platforms and registries such as
GitHub Packages to build standardized,
pre-production environments fordevelopment teams. Ideally, theseplatforms should integrate into thesource control solution so that whena team member commits new code,it triggers the automated provisioningof a pre-production environment.
• Cloud-based IDEs: Cloud-based IDEs
offer comprehensive development
environments that are pre-configured
and can be quickly provisioned. These
are an increasingly popular tool in
DevSecOps (and development circles
more broadly, for that matter) since they
help standardize developer environments,
including security configurations acrossmachines. And since they’re centrally
managed, cloud-based IDEs also
keep code off an individual developer’s
computer, which can improve overall
development security. Tools such as
GitHub Codespaces also feature deep
integrations into core DevOps platforms.
This can improve development speeds by
cutting down the amount of time it takes
to spin up a developer environment—andreducing the need to wait for runningbuilds and tests locally.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B• IaC: The rise in cloud infrastructure, orInfrastructure as a Service (IaaS), hasmade it simpler to quickly provisionresources to meet real-time demand.
It’s also introduced a need amongorganizations to manage complex cloudbased infrastructure at scale. IaC draws
on DevOps best practices to provisionand manage cloud infrastructure
resources from a version control systemsuch as GitHub via YAML files. These files
specify a CI/CD workflow automationthat is triggered by an event such asa pull request, code commit, or code
merge. Once this event happens, theworkflow automates the provisioning
and management of cloud infrastructure
resources. Tools such as GitHub Actions
offer this type of integration, which makes
it easier to manage infrastructure fromyour repository with CI/CD.

DevOps CI tools
CI is a mainstay of any DevOps practice andcombines the cultural practice of frequent
code commits with automation to integratethat code successfully and create builds.
• CI: As a practice, CI often involves
committing multiple code changes each
day to a shared repository and using
automation to integrate these changes,
applying a series of automated tests
to the merged codebase to ensure its
stability, and preparing the codebase
for deployment. This level of automation
requires deep integration between aversion control solution and the larger
CI/CD platform, which enables DevOps
organizations to build CI/CD pipelines

PAG E — 3 3

D e vO ps pla n n i n g , tools , a n d capabilities

that are triggered by a code commit.
When you’re looking for a good CI
solution, you’ll want to make sure it easily
integrates with your version control
solution. This integration is key to making
sure you can build an automated pipelinethat starts as soon as your development
teams commit code changes.
A good example of this level of integration
comes with the GitHub platform, whichfeatures platform-native CI/CD via
GitHub Actions and also features anumber of pre-built integrations for thirdparty CI/CD services. You’ll also want tomake sure that whatever CI/CD platform
you choose can automatically apply tests
at all stages of the SDLC and includes
native support for containerization
platforms.
• Automated testing: Automated testing
tools are a core part of any DevOps
toolchain. Most platforms will offer
automated testing as a capability,
making it simple to incorporate
automated tests into key parts of thepipeline—for instance, after a codechange is merged to the main branch.
The goal is to have a comprehensive
testing strategy with basic unit tests,
integration tests, and acceptance tests
that are applied at key points in the
SDLC. The best testing tools integrate
seamlessly with—or are part of—your
CI/CD platform and offer built-in code

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U Bcoverage and testing visualization. You’llalso want to look for testing platforms
that enable matrix build testing
capabilities or allow you to simultaneously
test builds across multiple operating
systems and runtime versions. It’s also
a good practice to ensure that yourautomated test solution of choice comeswith monitoring and alerts that integratewith your chat application of choice. Thismeans that if something breaks, you canquickly get a notification and work to fix
whatever the underlying problem is. Tools
such as GitHub Actions, for instance,
can be used to send alerts to chatapplications once a test fails for quicker
remediation.
• Packaging: Once code changes clear
all tests in a CI/CD pipeline, they arepackaged into independent units of codeand prepared for deployment. DevOps
organizations will typically leverage apackage manager such as GitHub
Packages to facilitate the delivery ofsoftware packages to a shared repository
in preparation for a release. Package
managers help remove the need for
manual installations and help bundle
code dependencies within a given project.
There are different package managers
for different code libraries—but you should
ideally look for a solution that integrates
with your version control system and your
CI/CD platform.

PAG E — 3 4

D e vO ps pla n n i n g , tools , a n d capabilities

DevOps CD tools
CD builds upon CI/CD by removing
the need for human intervention whenreleasing software. Instead, a CD practiceapplies automation to every stage of
the SDLC. That means if a code change
clears all automated tests, it is deployed to
production. These tools support CD:• Automated deployment: Automateddeployments are a core part of CD
and having a toolchain that supports
automated deployment. These
capabilities are typically present in most
CI/CD platforms. However, there is noone-size-fits-all approach to buildingout a CD pipeline—and it won’t work withevery application or environment. If you
decide to invest in CD, look for platforms
that readily support the development andmanagement of multiple environments.
Importantly, you’ll want a solution thathelps protect you from “server drift,”or differences between development,
pre-production, and production
environments. You’ll also want to consider
a platform that supports blue-green
deployments, which enables you to slowly
migrate traffic from an old version of an
application to a new release to ensure
its stability in production. At GitHub, we
provide deployment dashboards and CI/
CD visualization displays as part of ournative CI/CD tool GitHub Actions—and we
consider these core features for any CD
toolchain. This is meant to give DevOps
organizations full visibility into different
code branches, automated test results,
audit logs, and ongoing deployments asthey happen.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B• Configuration management:
Configuration management is a process
where technology teams manage thedifferent environmental configurations
necessary in the core infrastructure
and application systems across thelife of the product.It’s also somethingthat is frequently paired with CI/CD andversioning control via automation. Just
as a CI/CD pipeline applies automation
across the SDLC, configuration
management tools automatically apply
configuration changes in response to
trigger-based events. These automatedworkflows can be used to orchestrate
and manage container clusters withplatforms. GitHub repositories and issues
make it easy for IT professionals to workwith systems that produce text-based
configuration files for both IaC and
Configuration as Code (CaC).

Continuous testing tools
In a DevOps practice, testing doesn’t stop at
CI/CD—it’s an ongoing practice that extends
throughout the SDLC. And more importantly,
DevOps seeks to replace siloed QA teams
with a continuous testing practice thatleverages automation and holistic testing
strategies across the SDLC.
Each DevOps organization will design
its own continuous testing strategy inaccordance with its needs. GitHub Actions
provides workflow automation related totesting and supports a rich set of open
source and commercial testing tools. Every
continuous testing strategy will leverage
a combination of the following test types
across the SDLC:

PAG E — 3 5

D e vO ps pla n n i n g , tools , a n d capabilities• Unit testing: Unit tests are a way of
testing small units of code to verify
that they are structured correctly withisolated components. They are also
the easiest tests to build and the fastest
to execute, making them a foundational
test to automate in any continuous
testing practice.
• Integration testing: Once you commit
code changes to a repository, integration
tests ensure build stability, and that thecodebase continues to work successfully.
These tests are used to identify defects
that emerge when different application
processes and code units are merged
together. Integration tests are commonly
automated to begin as soon as codechanges are committed to a codebase
and test the interplay of multiple parts ofan application.
• End-to-end and regression testing:
Building on integration testing, end-toend and regression tests are applied aftera codebase is packaged and staged ina pre-production environment. These
tests are used to check if any old defects,
bugs, or issues are reintroduced by codechanges. Regression testing is commonlyused before and after deployments toensure that an application works as
expected and does not contain any
previously identified issues.
• Production testing: After an application is
deployed, production-level tests monitor
application health and stability—andidentify any issues before they cause
problems for end users. Importantly,
these tests help organizations identify
any potential problems in a production

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U Benvironment with live user trafficthat can’t be fully replicated in a preproduction environment.

DevOps operations andcontinuous monitoring tools
A successful DevOps practice touches
every stage of the SDLC—and that includes
production-level software, too. This means
companies need to invest in core operations
and continuous monitoring tools to evaluate
application and infrastructure performance.
If used correctly, these tools can help
continuously identify potential issues acrossthe SDLC:• Application and infrastructure
monitoring: Application andinfrastructure monitoring are corecomponents of a successful continuous
monitoring practice. The best tools
offer 24/7 automated monitoring of theapplication and infrastructure health andgive DevOps practitioners alerts whensomething goes wrong—and visibility into
what the underlying problem might be.
Ideally, you’ll want to monitor application
health in pre-production and production
environments to track any process issues
or areas to improve overall performance.
This is also true for your underlying
infrastructure where monitoring can leadto insights on how to improve your IaC
and configuration management policies.
Try looking for a tool that integrates
with your version control tool and chatapplications so you can immediately
send alerts to the right people and create
issues to outline the scope of work fora solution.

PAG E — 3 6

D e vO ps pla n n i n g , tools , a n d capabilities• Audit logs: Auditing is a central part ofan effective operations and continuous
monitoring practice—and resolving any
incidents if and when they happen. They
give DevOps practitioners a record ofwhat happened, where it happened, andwhen it happened, and can be criticalto build behavioral models that led to
an issue and improve application andinfrastructure health. Look for DevOps
tools that have live logs and auditing
retention periods to equip your teams with
the information they need to improve coreservices and application performance.
• Incident and change tracking: The
primary goal of DevOps is to helporganizations ship higher-quality software
faster through deep collaboration andautomation. And that means tracking
incidents and changes as they ariseand sharing them with the right peopleis critical. To build a successful DevOps
toolchain, you’ll want to incorporate toolsthat surface incidents and changes on
your core DevOps platform and sharedrepositories. The more centralized you
can keep all reports on incidents andchanges, the better. The goal is to createa single source of truth that makes it
easier to identify and fix issues.
• Continuous feedback: A core tenetof DevOps, continuous feedback isa practice that focuses on tracking
user behavior and customer feedback
about your core products and building
actionable data to inform future
investments in new features and system
updates. This can include NPS survey
data about how users are navigating yourproduct. It can also include tracking andmodeling user behavior in the productB U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

itself. To build a continuous feedback
practice, you’ll want to identify core areas
in your product and even outside it inplaces like social media and reviews
where you can identify unexpected user
behavior and customer pain points. Look
for tools that enable you to model andanalyze user behavior. You also might
consider social listening tools, which you
can use to track historical patterns onsocial media and review sites.

Security and
DevSecOps tools
As DevOps has evolved as practice, it has
underscored the need to move past more
traditional approaches to security, which
was often siloed from the core SDLC. To
ensure you’re shipping high-quality code,
making security a core part of the DevOps
practice is important. This practice iscommonly called DevSecOps, whichseeks to integrate security into every
stage of the SDLC and make it a core
part of CI/CD pipelines.
Companies that invest in DevOps often
find the need to invest in also building a
DevSecOps practice to ensure software
security. This typically involves several
tools that help organizations model
potential threats and apply automatedsecurity testing at key stages of theSDLC. While organizations often try to
grab individual tools to create a solution,
integrated products such as GitHub
Advanced Security can reduce the frictionof bringing DevSecOps to your teams. By
complementing their DevOps toolchain with
DevSecOps tools, companies will often look
for the following solutions:

PAG E — 3 7

D e vO ps pla n n i n g , tools , a n d capabilities• Threat modeling: Here’s a truism: it’s a
lot easier to find security vulnerabilities
and potential weak points when you’redeveloping software instead of after
you’ve released it. Threat modeling is apractice that DevSecOps practitioners
will engage in from the early planningstages of the SDLC to anticipate any
issues and develop plans to solve them.
DevSecOps organizations today will
also invest in threat modeling tools thatleverage automation and monitoring toproactively identify threats and mitigation
efforts. The best tools survey applicationand infrastructure threats and willautomatically track changes in theunderlying codebase and infrastructurearchitecture. Look for solutions that can
integrate with your core DevOps toolchain
to provide updates to relevant people
on your team and show risk evaluation
scores throughout the SDLC.
• Security dashboards: Having a single
view of your security profile including
potential risks, testing coverage, alerts,
and more is critical for any DevSecOps
practice. Security dashboards are often
used to collate and break down all
relevant security information and provide
a quick way to triage issues and assign
tasks. At GitHub, we include a security
overview page with GitHub Advanced
Security to help showcase risk categories
across projects and repositories andalert details, too. Ideally, you should look
for tools that integrate with your wider
DevSecOps security toolchain and offer asingle view of your security profile.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B• Static application security testing(SAST): SAST tools are used to evaluate
code before it is run to identify any
potential security risks or vulnerabilities.
Importantly, these tools do not need arunning system to execute but can be
performed on a static codebase. The best
tools will integrate directly into a sharedrepository and seek out any security
vulnerabilities, conduct dependency
reviews, scan for any confidential
passwords or secrets, and identify coding
errors before they make it into production.
These tools will also make it simple to find,triage, and prioritize fixes for any problems
in your codebase. You’ll ideally want tolook for a solution that integrates withyour repository and can be automatedto build out issues based on analysis.
At GitHub, for instance, we have a SAST
tool called Dependabot that analyzes
all dependencies for any known security
vulnerabilities—and it’s directly integrated
into every repository on the platform.
• Dynamic application security testing(DAST): DAST is used to imitate malicious
attacks on an application to find any
potential vulnerabilities that might risk its
real-world security. DAST tools typicallyanalyze applications in pre-production
environments to help DevSecOps
practitioners identify any possible
security flaws before they make it into
production. These flaws typically include
underlying issues attackers can exploit
to run SQL injection attacks and crosssite scripting (XSS) attacks, among otherthings. The best DAST tools will integratewith your CI/CD platform of choice so you
can automate their deployment within
the wider SDLC.

PAG E — 3 8

D e vO ps pla n n i n g , tools , a n d capabilities• Interactive application security testing(IAST): IAST solutions are used to identify
and profile risks and vulnerabilities
in running applications—most often
earlier in the SDLC before a releaseis made. These solutions leveragesoftware instrumentation to monitor andcollect information in pre-production
environments through manual andautomated tests. The best IAST solutions
will include software composition
analysis (SCA) tools to identify any opensource component vulnerabilities.
• Container image scanning: Due to theirlightweight architectures, containers havemade it simpler for DevOps organizations
to build, test, deploy, and update
applications in a fast and flexible manner.
But large-scale container environments
also introduce security risks due to thenumber of surface areas and potential
for vulnerabilities. To mitigate against
any risks, DevSecOps practitioners willleverage container scanning tools to
identify issues in the container registry,scan container clusters at runtime, andprevent vulnerabilities from making it
into production. Look for tools that canbe integrated into your CI/CD pipeline
and automated to run at specific points
in your SDLC before a deployment—
including the build, integration, andpackaging stages.

Monitoring tools
Monitoring is a core part of a successful
DevOps practice and a critical way to bothunderstand and detect any potential issues
before they make it to production—andsurface any issues that may show up
in production.
B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U BContinuous monitoring
Not so long ago, monitoring was costly.
Tools would take up precious system
resources and require manual intervention.
Moreover, the data these tools provided
would often take time to parse throughand act upon. As a result, organizations
typically only monitored mission-criticalprocesses such as coding issues andproduction-level performance.
Today, collecting data is much easier due tomore advanced tooling—but the amount ofdata has also vastly increased. That meansorganizations now need to determine how
best to manage, interpret, and act uponmuch larger volumes of data.
Continuous monitoring is a practicethat seeks to solve this issue by building
monitoring into every part of the SDLC.
Its primary goal is to enable the rapid
detection of any potential issues andprovide real-time feedback.
A continuous monitoring practice willleverage a series of tools and an automatedseries of tests to evaluate new code and the
production performance of an application,
as well as its underlying infrastructure. The
primary goal is to provide an automated,
360-degree view of all systems and ensure
the right people know when and where
to intervene.
The best continuous monitoring practices
often prioritize collecting as much data as
possible to audit systems in their entirety
and analyze potential operational issues
as well as compliance and security risks.

PAG E — 3 9

D e vO ps pla n n i n g , tools , a n d capabilities

Implementing monitoring tools
in your DevOps practice
Just like the move to DevOps itself,
establishing a successful DevOps
monitoring strategy requires a mix ofculture, process, and tooling. And while
you can take inspiration from how otherorganizations manage monitoring, theprecise model you adopt will be driven
by the unique needs of your organizations
and your SDLC.
There are plenty of frameworks that offer
guidance as to what data to capture. But
knowing where to implement monitoring is aquestion of optimization. What questions doyou need to answer? What data do you needto get those answers? How will you act onthat data? Who should be involved?

Capabilities you should look forin DevOps monitoring tools
There is a rich choice of tooling to help
you build monitoring into your DevOps
practice. The precise products you choose
will depend on the shape of your SDLC andyour application’s infrastructure. But there
are two core initial questions you should ask
when evaluating monitoring tooling:
Is it actionable? Does the tool integrateback into your DevOps pipeline and withyour other tooling to enable you to automate
actions and alerts based on its data?
Does it tell you something new? Generating
more data is easy but more data demands
attention, fills up storage, and needs to be
maintained. Choose tools that open up new
avenues of monitoring, rather than thosethat offer marginal gains.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U BThere are several areas where monitoringshould be implemented in a DevOps
practice, and some are more obvious thanothers. Tools to monitor the infrastructureand network are used to understand how
constraints such as memory and CPU
are impacting your application. At theapplication layer, application performancemonitoring (APM) tools are used toshowcase signals about your application’s
performance. These tools provide insights
into how to better optimize your application.
GitHub has features for monitoring CI/CD
workflows with GitHub Actions, aggregating
security findings with GitHub Advanced
Security, and providing developer velocity
metrics with organizational insights.
Tooling is often the most visible aspectof a DevOps practice. It is a practicalmanifestation of the DevOps culture andprocesses that influence every stage of theSDLC. In DevOps, tools are often used toapply automation wherever possible, create
feedback loops, and free up organizational
resources. By encouraging feedback
loops through automated monitoring andreporting tools, DevOps helps teams build
more resilient software. When problems
arise, DevOps automation and tooling help
deploy fixes into production faster than
traditional software development practices.
DevOps isn’t implemented simply bypurchasing a set of tools, but tools that areopen and collaborative in nature can foster
DevOps principles. State-of-the-art DevOps
tools, along with a high-functioning DevOps
culture, can provide organizations with animmense competitive advantage.

PAG E — 4 0

Conclusion: DevOps
as a framework todeliver value
If you ask 10 people to define DevOps, you’relikely to get at least five different answers.
Some people might focus on the practical implementationof DevOps—CI/CD, test automation, and so on—and they’ll
call it a process. Others might call DevOps a methodology
with a set of processes that work together under a coherent
philosophy. But both definitions miss the larger point:
DevOps consists of a set of practices that are adaptableto each business that adopts them.
It’s better to understand DevOps as a framework forthinking about how to deliver value through software.
It’s more than a single methodology or collection ofprocesses. It’s fundamentally a set of practices—both
cultural and technological.
Tooling is often the most visible aspect of DevOps, but
DevOps is not a single tool. A DevOps transformation starts
with a cultural change intended to shift how we think about
expertise and responsibility. Information is the currencyof a DevOps pipeline. The key consideration is whether
that information can flow freely between stages, which
is facilitated by culture and process as much as it is bytechnology.
Once the foundation of a high-functioning DevOps culture isin place, tooling can absolutely influence the overall successof a DevOps practice in an organization. The best DevOps
culture, with continuous learning feedback loops, requires
tooling capable of allowing cohesive flow from one DevOps
stage to the next. The combination of people, processes,
cultural practices, and technologies all working together isthe indicator of a successful DevOps practice. Only wheneach pillar is working in unison can DevOps’ benefits offaster delivery, increased quality, and more scalable products
be achieved.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 41

Resources• What is the DevOps Model? Exploring foundational practices
in DevOps• DevOps fundamentals: Defining DevOps principles• Should we think of DevOps as a methodology?
• What is a DevOps pipeline? A complete guide• The fundamentals of continuous integration in DevOps• The fundamentals of continuous deployment in DevOps• What is containerization?
• DevSecOps explained• A guide to DevOps tools and DevOps automation toolchains• DevOps monitoring tools: Automating your DevOps
monitoring processes

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 42

Build your DevOps
practice on GitHub
GitHub is an integrated platform thattakes companies from idea to planning
to production, combining a focused
developer experience with powerful,fully managed development, automation,and test infrastructure.
GitHub’s comprehensive suite of tools brings the entire
DevOps pipeline into a single toolset. To assist in planning,
GitHub Issues and Projects provide an innovative,
developer‑first approach to work management. Once theidea has been planned, developers can start working oncode in an isolated development container that is identical totheir co-workers with GitHub Codespaces. When the featureis ready to be reviewed, pull requests within GitHub allow
developers to collaborate and receive real-time feedback.
GitHub Actions is the automation platform used for CI, CD,and automating anything and everything in between. GitHub
Packages is used to store, manage, and distribute software
packages. To keep your code secure and secrets out ofsource control without disrupting developers’ flow, leverage
the GitHub Advanced Security toolset. By using GitHub
and its features, every stage of the DevOps pipeline canbe enhanced.
As the world’s largest and most advanced development
platform, GitHub helps millions of developers andcompanies collaborate, build, and deliver faster. And withthousands of DevOps integrations, you can build with thetools you know from day one—or discover new ones. Get thecomplete developer platform today and join over 83 million
developers and 4 million organizations developing software
on GitHub.

B U I L D YO U R D E VO P S P R AC T I C E O N G I T H U B

PAG E — 4 3

Got questions about GitHub Enterprise?

We can help.
Visit our GitHub Enterprise page orconnect with our sales team.

W R I T T EN BY G I T H U B W I T H