The Heart of DevOps

1 The Five Practices at the Heart of DevOps

1.1 The Five Practices of DevOps

• Infrastructure as Code
• Configuration Management
• Continuous Integration
• Continuous Delivery
• Automated Testing
In this course, we will explore these practices and much more!

1
2 Quiz Question
Below are the five parts of the DevOps lifecycle we just discussed. Can you
match each of them with its description?

2.1 Description
2.2 Part of the lifecycle
Integrate code into source control to get fast feedback on its development.

2.3 Continuous Integration

Automate the provisioning of resources to be more agile and better control the
environment.

2.4 Infrastructure as Code

Make every change ready for release as soon as possible.

2.5 Continuous Delivery

Control and automate the execution of testing to get frequent feedback.

2.6 Automated Testing

Control and manage changes in a standard and repeatable way.

2.7 Configuration Management

3 Definition of DevOps
These definitions come from The Agile Admin blog and Chef’s DevOps page.
There are a lot of different definitions out there, but we felt like this might be
the best way to explain. Not so much of a definition, but more so a description.
It is when the development team and operations teams, usually distinct and
separate teams, work together to develop and deliver applications and services
at high velocity. It involves a shift in culture and tries to do away with ”us vs.
them” and instead is inclusive:

3.1 Development roles

include people like developers or software engineers, and also everybody who’s
involved in making the software before it hits production, like product managers
and QA testers.

2
3.2 Operations roles
likewise include everyone who is involved in running and maintaining produc-
tion, systems engineers, DBAs, network engineers, security folks, and so on.

4 A Brief History of DevOps

4.1 Question 1 of 2
Which of the following are Core DevOps concepts? (Select all that apply.)

• Infrastructure as Code
• Don’t Repeat Yourself
• Take Your Time
• Customer First
• Shared Responsibility
• Move Fast and Break Things

4.2 Question 2 of 2
Below are the DevOps principles in the video. Can you match each with the
correct description?

4.3 Description
4.4 Principle
Customer First
Prioritize the people who ultimately ”keep the lights on.”
Write code that allows us to create the same environment anywhere, for
anyone.

4.5 Infrastructure as Code

DRY
Use abstractions and variables to avoid unnecessary repetition.
Have good documentation and a configuration that is version controlled.
CI/CD and automated testing to reduce downtime.
See Dev and Ops as ”one team” and avoid the ”blame game”.

4.6 Configuration Management

High Availability
Shared Responsibility

3
5 Infrastructure as Code
5.1 Lesson
5.2 Downloads
5.3 Intro to Infrastructure as Code
Infrastructure as Code is the first of the five core practices of DevOps.
Infrastructure as code gives us a huge advantage in defining, deploying, up-
dating, and destroying our infrastructure. Some key benefits are:

• Instead of having to request development environments and wait for tickets

to be fulfilled, we can use self-service to allow users to deploy their own
environments.
• Version control
• Increased documentation
• Automated testing and validation.

Infrastructure as code falls into 5 categories:

• Custom Scripts
• Configuration Management Software
• Server templating
• Orchestration
• Provisioning

6 Configuration Management
6.1 Lesson
6.2 Downloads
Configuration Management is the second of the five core practices of DevOps.
Configuration management is important to DevOps operations because:

• We always want to be able to build and deploy a working copy of our

software at any time.
• Some items of our configuration may change, rendering our software un-
deliverable.
• When we take care to implement configuration management practices, we
avoid unexpected failures and can carefully test our code.

4
 The goals of configuration management are:

• Configuration identification and control

• Build and process management

• Environment management
• Version control

6.3 Question 1 of 4
Here are the configuration management tools we just discussed. Can you match
each one with the correct description?

6.4 Description
6.5 Tool
Ensures environments and builds are consistent and repeatable

6.6 Infrastructure as Code

Provides a common location to store code, with tracked changes.

5
6.7 Version Control Software
Tells us what was changed and why.

6.8 Documentation
Tells us what the configuration of the infrastructure should be.

6.9 Documentation
Stakeholders who approve changes in configurations

6.10 Change Advisory Board

6.11 Question 2 of 4
Documentation is a crucial part of configuration management, and it can take a
number of different forms. Which of the following are forms of documentation?
(Select all that apply.)

• README files

• Release notes
• Wiki pages
• Comments in code

• Git commit messages

6.12 Question 3 of 4
Which of the following best describes the function of the README?

• Documentation (mainly for external customers) that summarizes all changes

from the last version to the current version.

• A version-controlled place to keep detailed references for internal cus-

tomers.
• Documentation of individual line-of-code issues (e.g., giving type hints,
flagging TODO items).
• Documentation that has everything someone needs to be able to get your
project up and running.

6
6.13 Question 4 of 4
Which of the following best describes the function of release notes?

• Documentation (mainly for external customers) that summarizes all changes

from the last version to the current version.
• A version-controlled place to keep detailed references for internal cus-
tomers.

• Documentation of individual line-of-code issues (e.g., giving type hints,

flagging TODO items).
• Documentation that has everything someone needs to be able to get your
project up and running.

7 Quiz - Writing Commit Messages

7.1 Lesson
7.2 Downloads
7.3 Quiz: Commit Messages
As we mentioned on the last page, Git commit messages are a crucial form
of documentation-particularly for times when things go wrong! Remember,
commit messages are entered any time a change in code is submitted, and it
describes the change and what is affected.
On this page, we’ll look at characteristics of good commit messages.

7.4 Characteristics of Good Commit Messages

Good commit messages should:

• Have a subject and a body; summarize the changes in 50 characters or

less, then provide detail.

• Use imperative language (e.g., ”refactor get data function for readability”)
• Wrap long messages. It’s ok to write long commit messages, but use
newlines to wrap them.
• Explain what was changed and why.

It helps a lot to look at some concrete examples. The following are real
examples of commit messages from open source projects. Beneath each is an
explanation of why it is a good or not-so-good commit message.

7
7.5 Example 1
Bug Fixes
• Lacks context. What bugs were fixed?
• Lacks detail. How were the bugs fixed?
There is a big difference between a bug fix when a bug leads to too much
output in the command line if a certain flag is set, and a bug fix that leads to
a critical security vulnerability. A commit message should be clear.

7.6 Example 2
Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-
ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it
turns out this was one of the culprits in the recent build breakage. The class-
loader hacking causes subtle downstream effects, breaking unrelated tests. The
test method is still useful, but should only be run on a manual basis to ensure
CGLIB is not prematurely classloaded, and should not be run as part of the
automated build.
• Way too long-it should have an easy-to-read summary up front
• No wrapping of message
• Lack of imperative language
• Editorializes: ”The test method is still useful, but should [...]”
It’s OK to write long commit messages, but remember that these are being
used to prioritize merges, to find bugs, and to communicate context about a
change.

7.7 Example 3
Add tests for ImportSelector meta-data
• Clear and concise
• Tells you what was done where

7.8 Example 4
fix types taken by HMAC(), HMAC Update()
HMAC() and HMAC Update() take size t for ’n’ and ’len’ respectively.
• Has a summary and body
• Uses imperative language
• Tells us exactly what changed and why.

8
7.9 Practice
Now that you know the principles of good commit messages, let’s get some
practice reading some examples and identifying which principles they violate.

7.10 Question 1 of 4
Have a look at this commit message:
Update get refs function to reduce overhead and handle case where references
are in non-standard formats
Which principle does this violate?

• Have a Subject and a Body

• Wrap long messages

• Explain what was changed and why
• Use imperative language in summary

7.11 Question 2 of 4
Here’s another:
Add type hints for ’update trigger’ - ’update trigger’ takes
Which principle does it violate?

• Wrap long messages

• Have a Subject and a Body

• Explain what was changed and why

• Use imperative language in summary

7.12 Question 3 of 4
And here’s another:
Update load data’ function changed
Which principles does it violate?

• Wrap long messages

• Explain what was changed and why
• Use imperative language in summary

9
7.13 Question 4 of 4
And here’s the last one:
added exception handling
Exception handling lets us deal with the case where assertion fails
Which principles does it violate?

• Wrap long messages

• Use imperative language in summary
• Explain what was changed and why
• Have a Subject and a Body

7.14 Quiz Question

Mark the things that a configuration management tool should do.

• Configure Environment Variables

• Create EC2 Instances
• Install Dependencies
• Wash Dishes
• Start/Stop Services
• Deploy Applications
• Run CloudFormation Templates
• Identifying Customers

7.15 Competing Priorities

7.16 Unplanned work
7.17 Deconflict competing priorities
7.18 Question 1 of 4
For each of the stakeholders below, indicate whether they are an internal or
external customer.

7.19 These are the correct matches.

7.20 Stakeholder
7.21 Internal or external
Leadership at your company

10
7.22 Internal
Someone who buys your product

7.23 External
Developers at your company

7.24 Internal
Someone who pays for your company’s service

7.25 External
7.26 Question 2 of 4
Pretend you’re a DevOps engineer at a medical device company whose primary
job is to create development environments for developers of embedded medical
device software. Who, among the following, are likely customers for your work?
(Select all that apply.)

• Software Developers
• Hospitals
• Patients
• A car dealership
• Insurance companies
• The CEO of your company

7.27 How do I Prioritize?

• Depends on the business
• See the bigger picture
• Ask questions
• When in doubt, call it out
• Never sacrifice stability for new features

7.28 Question 3 of 4
Generally speaking, everything you do should ultimately be in service of...

• External customers
• Internal customers

11
7.29 Question 4 of 4
You’re working on a planned feature for an environment you’re developing when
you get an email from customer support. The email reads:
Hey! We’ve got an outage with a customer. It looks like when they input
a string that’s too long, their entire application crashes. The PM told me that
you’re the person for the job, and said that we need this fix in Friday’s build.
What should you do?

• Features generate value for customers and make them happy - stick to the
plan.
• Never prioritize features over bugs. Let the feature slip and fix the bug.
• You can do both! Finish the work you’ve started and then fix the bug.

• Send your manager an email and ask what to do.

8 When DevOps Does Not Work

8.1 Lesson
8.2 Downloads
It can be difficult to switch to Agile methodologies. The keys to success are to:

• Create a culture of version control and documentation

• Ensure code is DRY

• Use Infrastructure as Code

• Automate testing

Even outside of Agile frameworks, these DevOps concepts will help you. As
you move along in your DevOps journey, demonstrating how much better things
could be if you also moved to an Agile development method may help you.

8.3 Question 1 of 2
When should you not make the switch to Agile?

• When you are mid-project

• When your company already has a DevOps model in place
• When you don’t have an expensive ticketing system in place

• Before you read Accelerate

12
8.4 Question 2 of 2
Is it a good idea to use infrastructure as code in a non-Agile environment?

• Yes-it still provides a codified, unified, version-controlled environment for

development, testing, and deployment
• Probably not-infrastructure as code will be ineffective when it is not sup-
ported by an Agile environment

9 Models of Software Development

9.1 Lesson
9.2 Downloads
9.3 Software Development Lifecycle
The Software Development Lifecycle (SDLC) can be implemented through sev-
eral different development models, such as:

• The waterfall model

• The v-model
• The spiral model

• The agile model

Our goal in looking at these models is to get a general idea of why the first
three-waterfall, v-model, and spiral-have significant limitations. This will help
us understand why we want to go with an agile approach in this course. Note
that you do not need to memorize every detail of these models; rather, try
to understand what the problems are with the first three, and how the agile
approach solves these problems.
Our intent here is to give you a very brief, high-level overview of these
methodologies-mainly so that you have an idea of where Agile fits in. We will
get into a more detailed discussion of Agile development in the next lesson.

9.4 Question 1 of 5
Match the Software Development Life Cycle (SDLC) methodology to its appro-
priate description.

13
9.5 These are the correct matches.
9.6 Description
9.7 Methodology
A linear model which flows only in one direction until the maintenance stage,
with a single integration and test step.

9.8 Waterfall
A linear model with testing for each design step

9.9 V-model
Repeated cycles of identification, design, build, and evaluation

9.10 Spiral
Short cycles through the steps of requirements, design, development, testing,
deployment, and review.

9.11 Agile
9.12 Question 2 of 5
The main problem with the waterfall model is...

• Too efficient
• Difficult to go back and change design based on testing results

• Linear models do not let you go back and maintain your code
• Testing is too onerous

9.13 Question 3 of 5
The main problem with the v-model is...

• There is too much testing

• It is extremely rigid and inflexible

• It produces software too early
• There is no definition of ”done”

14
9.14 Question 4 of 5
The main problem with the spiral model is...

• Not defined end point

• Inflexible, linear model
• No testing phase
• Risk analysis takes too long

9.15 Question 5 of 5
The main advantage of the agile approach is...

• Clear, immutable plan

• Gets you venture capital funding
• It’s the only SDLC methodology which supports Python
• Fast feedback

10 Fundamentals of CI/CD
10.1 Continuous Integration
The practice of merging all developers’ working copies to a shared mainline
several times a day. It’s the process of ”Making”. Everything related to the
code fits here, and it all culminates in the ultimate goal of CI: a high quality,
deployable artifact! Some common CI-related phases might include:

• Compile
• Unit Test
• Static Analysis
• Dependency vulnerability testing
• Store artifact

10.2 Continuous Deployment

A software engineering approach in which the value is delivered frequently
through automated deployments. Everything related to deploying the artifact
fits here. It’s the process of ”Moving” the artifact from the shelf to the spotlight.
Some common CD-related phases might include:

• Creating infrastructure

15
 • Provisioning servers
• Copying files
• Promoting to production
• Smoke Testing (aka Verify)
• Rollbacks

10.3 The CI/CD Pipeline

10.4 Key Terms

• Pipeline: A set of data processing elements connected in series, where the
output of one element is the input of the next one.
• Continuous Integration: The practice of merging all developers’ working
copies to a shared mainline several times a day.
• Continuous Delivery: An engineering practice in which teams produce and
release value in short cycles.
• Continuous Deployment: A software engineering approach in which the
value is delivered frequently through automated deployments.
• Infrastructure as Code: The management of infrastructure using code.
• Provisioning: The process of setting up IT infrastructure.
• Artifact: A product of some process applied to the code repository.
• DevOps: A set of practices that works to automate and integrate the
processes between software development and IT teams.
• Testing: A practice that seeks to ensure the quality of the software.

16
10.5 Question 1 of 3
Match the key terms to definitions.

10.6 These are the correct matches.

10.7 Definition
10.8 Term
A set of data processing elements connected in series, where the output of one
element is the input of the next one.

10.9 Pipeline
The practice of merging all developers’ working copies to a shared mainline
several times a day.

10.10 Continuous Integration

An engineering practice in which teams produce and release value in short cycles.

10.11 Continuous Delivery

A software engineering approach in which the value is delivered frequently
through automated deployments.

10.12 Continuous Deployment

The process of setting up IT infrastructure.

10.13 Provisioning
A set of practices that works to automate and integrate the processes between
software development and IT teams.

10.14 DevOps
10.15 Question 2 of 3
Given the scenario below, which of the concepts would address the team’s pain
points?
There have been several human errors when deploying the product version
of a complicated application over the past 6 months. The team has a detailed
deployment checklist, but there is always something that doesn’t get done quite
right. The company has tasked you with finding a solution to the problem.

• Continuous Integration

17
 • Continuous Deployment
• Neither

10.16 Question 3 of 3
Given the scenario below, which of the concepts would address the team’s pain
points?
You are involved in the development of an application in a large company
where there are contractors who live in different time zones. The team is divided
into 3 groups to cover several functionalities at the same time. Your team is
having major issues with conflicting code and a neglected unit test suite.

• Continuous Integration

• Continuous Deployment
• Neither

10.17 Stage
10.18 Coding
10.19 Human
10.20 Code Review
Human, Subjective, Inconsistent

10.21 Human/CI - Static Analysis

Compile/Lint

10.22 Human
10.23 CI
Merge/Integrate

10.24 Human
Run Unit Tests
Human, Hit or Miss, Easily Bought Off with Pressure

10.25 CI
Run Integration Tests
Human, Hit or Miss, Easily Bought Off with Pressure

18
10.26 CI
Verify Dependency Security
Human, Often Not Done
Deploy to Test Env
Human, Problematic, Missed Steps

10.27 CD
Team Test
Human, Time Consuming

10.28 CD - Automated Acceptance Tests

Deploy to Client

10.29 CD
Client Test
Human, Problematic, Missed Steps

10.30 Human, Often Unnecessary If Pre-Development Ac-

tivities are On Point
10.31 Human - Maybe Not Needed If We Can Build Con-
fidence
Infrastructure
Human, Problematic, Missed Steps, Stressful

10.32 CD
Deploy to Production
Human, Problematic, Missed Steps, Stressful

10.33 CD
Smoke Test in Prod
Human, Inconsistent
Automated Smoke Tests (Subset of AAT’s)
Rollbacks
Human, Problematic, Missed Steps, Stressful

10.34 CD
Promoting Production
Human, Problematic, Missed Steps, Stressful

19
10.35 CD
Celebrate!

10.36 Human
10.37 Human
10.38 When to use CI/CD
You Might Need CI/CD If You Are...

• Investing more time in a release cycle than delivering value

• Wasting time every time we finish a feature on merge issues

• Code gets lost because of botched merges
• Unit test suite hasn’t been green in ages
• Deployments contribute to schedule slip

• Friction between ops and development departments

• Only one engineer can deploy a system
• Deployments are not cause for celebration

10.39 No Free Lunch

No pain, no gain, right? Did you think CI/CD was going to solve all your woes
and ask nothing in return? Think again!

• No more manual deploying to environments

• No more modifying environment settings in GUI’s

• No more neglecting the unit tests

• No more leaving broken code in place
• Requires a high level of discipline
• Requires additional skills to maintain and extend automation

20
10.40 Quiz Question
What are the signals that you need CI/CD?

• Investing more time in a release cycle than delivering value

• Deploys are not cause for celebration
• Code gets lost because of botched merges

• Features are not well enough defined

• Deployments cause schedule slip
• Developers write unmaintainable code
• Only one developer can deploy

Both sides of the business/tech divide need to involve the other side in
decisions so that our companies can be stronger and make a better impact on
the world. But, since you’re the one taking this course, it’s probably going to
be up to you to start the conversation. You can start by bringing your business
leaders into the discussion about CI/CD and Continuous Delivery.
Use this as an opportunity to translate the technical terms into words that
matter to the business-minded people in your company. Convince them to move
in the direction of Continuous Delivery based on the very real benefits it can have
for your company, not just some cool technical features that make developers
happy. By bringing the business side of the house into the discussion, you’ll be
better positioned to make real change!

10.41 One Team

• Technical Team
• Business Team

We Need to Translate CI/CD Concepts into Words Our Stakeholders Can

Understand

10.42 Question 1 of 2
Business leaders are not knowledgeable about Continuous Delivery and therefore
should not make the decision of whether or not to adopt it.

• True
• False

21
10.43 Question 2 of 2
Based on what you know so far, in what way is Continuous Integration/Delivery
related to the issue of business value and profit?

• It ensures that your software product is user tested and well-liked by users.
• It ensures that your software product is always in a working state, which
helps ensure customer satisfaction.
• It ensures that code from different developers is integrated into a central
code base.

10.44 Benefits of CI/CD

10.45 Why Is Translation Important?
If the decision-makers in your company can’t understand why something is im-
portant or adds value, they might not approve it. This usually isn’t because
they’re ignorant or trying to be difficult, this is often because they don’t under-
stand how the technical changes translate into benefits for the company. Using
language they understand will make everyone’s lives better and easier!

10.46 Technical Language Value Translation

• Catch Compile Errors After Merge: Reduce Cost: Less developer time on
issues from new developer code
• Catch Unit Test Failures: Avoid Cost: Fewer bugs in production and less
time in testing
• Detect Security Vulnerabilities: Avoid Cost: Prevent embarrassing or
costly security holes
• Automate Infrastructure Creation: Avoid Cost: Less human error, Faster
deployments
• Automate Infrastructure Cleanup: Reduce Cost: Less infrastructure costs
from unused resources
• Faster and More Frequent Production Deployments: Increase Revenue:
New value-generating features released more quickly
• Deploy to Production Without Manual Checks: Increase Revenue: Less
time to market
• Automated Smoke Tests: Protect Revenue: Reduced downtime from a
deploy-related crash or major bug
• Automated Rollback Triggered by Job Failure: Protect Revenue: Quick
undo to return production to working state

22
10.47 Quiz Question
Match technical benefits to business benefits.

10.48 These are the correct matches.

10.49 Technical Benefit
10.50 Business Benefit
Catch Compile Errors After Merge
Less developer time on issues from new developer code
Catch Unit Test Failures
Fewer bugs in production and less time in testing
Automate Infrastructure Creation
Less human error, Faster deployments
Deploy to Production Without Manual Checks
Less time to market
Automated Smoke Tests
Reduced downtime from a deploy-related crash or major bug

10.51 Best Practices for CI/CD:

• Fail Fast: Set up your CI/CD pipeline to find and reveal failures as fast
as possible. The faster you can bring your code failures to light, the faster
you can fix them.

• Measure Quality: Measure your code quality so that you can see the posi-
tive effects of your improvement work (or the negative effects of technical
debt).
• Only Road to Production: Once CI/CD is deploying to production on your
behalf, it must be the only way to deploy. Any other person or process
that meddles with production after CI/CD is running will inevitably cause
CI/CD to become inconsistent and fail.
• Maximum Automation: If it can be automated, automate it. This will
only improve your process!
• Config in Code: All configuration code must be in code and versioned
alongside your production code. This includes the CI/CD configuration
files!

10.52 Deployment Strategy

• Big-Bang: Replace A with B all at once.

23
 • Blue Green: Two versions of production: Blue or previous version and
Green or new version. Traffic can still be routed to blue while testing
green. Switching to the new version is done by simply shifting traffic from
blue to green.
• Canary: Aka Rolling Update, After deploying the new version, start rout-
ing traffic to new version little by little until all traffic is hitting the new
production. Both versions coexist for a period of time.
• A/B Testing: Similar to Canary, but instead of routing traffic to new
version to accomplish a full deployment, you are testing your new version
with a subset of users for feedback. You might end up routing all traffic
to the new version, but that’s always the goal.

10.53 Quiz Question

Deployment is an important topic. There are many deployment strategies to
choose from, make sure you know the common ones we discussed.

10.54 These are the correct matches.

Replace a new version with the old version all at once

10.55 Big-Bang
There are two versions of production, the previous version and the new ver-
sion. Traffic can still be routed to the old while testing the new. When ready,
switching to the new version is done by simply shifting traffic.

10.56 Blue Green

After deploying the new version, start gradually routing traffic to the new ver-
sion until all traffic is hitting the new production. Both new and old versions
coexist for a period of time.

10.57 Canary
Testing your new version with a subset of users. Once satisfied with the results,
routing all traffic to the new version.

10.58 A/B Testing

10.59 Blue Green Deployments
The Router: Directs traffic between BLUE (old) - GREEN (new)

• Router Option: Description

24
 • Load Balancer: Instant switch for FrontEnd or BackEnd
• CDN: Instant switch for front-end web apps.
• DNS: A bit slow because of DNS propagation.

10.60 Common Jobs

• Step: Description
• Integrate Code in a Build: Compile and create artifact
• Ensure Infrastructure is Present: Create green infrastructure
• Provision the Environment: Configure green instance, migrate DB, etc
• Deploy Artifact: Copy artifact files to instance
• Switch Router: Redirect traffic to new version
• Destroy Old Release Environment?: Clean up blue env (optional)
• Notify The Team (Successful): Celebrate!

10.61 Quiz Question

Select the best sequence for a Blue Green Deployment.

• Compile, Unit Tests, Provision, Sanity Test, Deploy, Switch the Router,
Smoke Tests, Notify Team of Success. Destroy Old Environment
• Compile, Unit Tests, Provision, Deploy, Smoke Tests, Switch the Router,
Sanity Test, Destroy Old Environment. Notify Team of Success
• Compile, Unit Tests, Provision, Deploy, Switch the Router, Destroy Old
Environment, Smoke Tests, Notify Team of Success
• Compile, Unit Tests, Provision, Deploy, Smoke Tests, Switch the Router,
Destroy Old Environment, Notify Team of Success

10.62 Ensuring Quality - Key Points

Consistency and quality go hand-in-hand. Consistent processes–like starting a
CI/CD pipeline, which executes the exact same tasks in the exact same order
every time–can ensure that the released application is high-quality because au-
tomated testing tasks can be added in multiple places throughout the various
stages of the CI/CD pipeline.
We can ensure and increase software quality by adding tasks that run auto-
mated tests specific to the application that is being built and deployed. There
could be multiple suites of automated tasks - maybe one suite runs just after
the application is built and only tests core functionality, and a different suite

25
runs just after the application is deployed and simulates user behavior. The
more we can effectively test software prior to its release to the end users, the
higher the quality will be.
We will go deeper into the importance of automated testing in an upcoming
lesson.

10.63 Quality Releases

10.64 Question 1 of 2
What is the biggest advantage to adding automated tests to the CI/CD pipeline?

• It makes managing automated tests easier.

• It replaces the need for unit tests.

• It eliminates the need for a human in the build and deployment process
• QA’s test suites can be stored in source control

26
10.65 Question 2 of 2
CI/CD pipelines are consistent because:

• They execute the exact same tasks, in the exact same order
• They make it easy to automate tasks
• They support manual deployments
• They can deploy one-off code

10.66 CI/CD Tools

10.67 Lesson
10.68 Downloads
10.69 CI/CD Tools
10.70 Tools
Plenty of tools exist that can handle the entire CI and CD pipeline. Some tools
can be installed on your own hardware, while others are cloud-based services.

10.71 Common Features

Whether your tool is on-prem or a SaaS product, it will likely have at least the
basic features of any CI/CD system. Getting to know these common features
will help you to be a little more ”tool agnostic”.

• Feature: Comments
• Scoped Environment Variables: These are Environment variables that
are built-in or defined at various scope levels including account, project,
pipeline and job.
• Steps: A step is an instruction that should be run during a job in order
to accomplish a single goal.
• Jobs: A job is made up of a group of steps that should run in a specific
order.
• Job Images: Jobs can take advantage of various pre-existing Docker images
that provide an environment in which to run steps.
• Agents: An agent is a machine, either physical or virtual, that responds
to the CI/CD system to run jobs on-demand.
• Pipelines: A pipeline is a set of instructions to run a group of jobs in
parallel or sequentially and according to a pre-determined dependency
tree.

27
 • File Sharing: File sharing in the CI/CD context is the ability to share files
between jobs, even though the jobs might be run on completely different
images or agents.
• Code-Based Configuration: Code-based configuration enables engineers to
build configuration files that define and control CI/CD pipelines. These
files can be saved to disk, shared with others, and versioned in source
control.
• Failure Branching: Failure branching allows engineers to write instructions
that should be run only in the event of a job failure.

10.72 Installable/On-Prem
Your team may prefer an on-prem CI/CD server running closer to the develop-
ment team. There are a lot of great options with varying pricing models. One
major benefit to an on-prem CI/CD server is a high degree of control. On the
other hand, an on-prem CI/CD server requires time from someone in the team
to maintain. The list below has a few options, but certainly not all!
• Tool: Creator/Maintainer: Differentiators
• Jenkins: Various Contributors: Vibrant open-source community, 100%
free
• Gitlab Community: Gitlab: Open-source, installable version of the popu-
lar cloud-based service, 100% free
• Team City: JetBrains: Very mature, JetBrains support
• Team Foundation Server (TFS): Microsoft: Seamless integration with Mi-
crosoft products, Microsoft support

10.73 Cloud-Based
Some teams prefer to use cloud-based services since they require much less time
to maintain and configure. The list below is far from exhaustive. There are
many many options out there. These are just a few of our favorites.

10.74 Types of development environment

The main development environments are
• Local
• Development (Sandbox)
• Integration
• Staging
• Production

28
10.75 How Does Continuous Integration Work?
10.76 Necessary Steps of Successful CI
• Maintain a code repository
• Automate the build
• Test the build
• Commit frequent changes
• Build each commit
• Fix bugs immediately

10.77 Building Blocks of the CI/CD Pipeline

10.78 Build Stages
Think of stages like categories or types of jobs. Stages are used to group jobs
and control timing.

• Stage: Description
• Build: Everything that has to do with making code executable in produc-
tion (e.g., Compile). The goal is to produce an artifact.
• Test: All automated tests that verify at the code level.
• Analyze: Any static analysis on the code or checking of dependencies.
• Deploy: Anything to do with creating server instances or copying pre-built
application files to an instance.
• Verify: Any tests that can be run against a running instance of the appli-
cation, often against a pre-production instance.
• Promote: Replacing the current production environment with the new
version which was just built and deployed.
• Revert: Rolling back or undoing changes in case any verification fails after
deployment.

10.79 The CI/CD Pipeline

10.80 Characteristics of Healthy CI Pipelines
We want to create healthy, consistent pipelines in order to create a better build
process!

• Highest Priority When the Build is Broken

29
 • Trusted Members of the Team

• Have the Same Abilities as any Member of the Team

• Enforce Team Quality Rules
• Communicate Useful Information
• Shorten Feedback Loops

• Don’t Require Stacks of Documentation

• Automated to the End!

10.81 Quiz Question

Mark all the characteristics of a healthy CI system.

• Build passes and fails equally on CI and locally

• Always sends zip files of code to the manager on failure
• It does not require human intervention in its majority
• Includes jobs to ensure the quality of the code

• Notifies every relevant stakeholder of every unit test failure

• Runs quickly
• Easy to maintain without much documentation

30
10.82 Continuous Deployment
Continuous Deployment can be an incredible tool in your arsenal. Not only
does CD save time, but it opens some unexpected doors that have a ripple
effect over the entire organization. Let’s take a look at where CD fits into the
overall Software Development Lifecycle.

10.83 Where does CD fit in the SDLC?

• While CI is all about code, CD is all about the deployment of the artifact.

• CI produces the artifact, whether it’s a docker image, a zip file, or an

executable.
• CD Validates the artifact, builds the infrastructure needed to run it, and
sets the artifact in motion.
• CD affects earlier stages of development over time because team members
see quick deployments and begin slicing features into smaller pieces to take
advantage.

10.84 Time to Deploy!

10.85 What will I need to add CD?
• Buy in from decision-makers.
• Automation skills, which you are learning in this course.
• Access to servers or cloud resources.
• Time to build automation.

10.86 What will I lose when I add CD?

• The ability to tinker with the servers manually.
• The opaque wall of secrecy around one dev’s way of deploying.

• Free pizza from the deployment all-nighters.

10.87 What will I gain when I have CD?

• Automated deployments to QA, Staging, Prod.

• More time to develop features.

• Generate more confidence amongst stakeholders.

31
10.88 Continuous Delivery and Continuous Deployment?
Ultimately, both can be used to get the product to production (i.e., the user).
The big difference is that in continuous delivery, there could be a manual step
of approval to update to production. With continuous deployment, production
happens automatically without explicit approval.
Continuous delivery automates the entire software release process.

10.89 Quiz Question

Mark the things that are part of CD concept

• Compile Code

• Promote to Production
• Run Unit Tests
• Run Smoke Tests
• Rollback

• Analyze Code

10.90 Case Study: Effects of Continuous Delivery (B)

DevOps, Agile, Lean, Kanban, Scrum... all great things, all exciting buzz words,
each the subject of many conferences, blogs and courses. But, not a single one
of those amazing concepts or methodologies will make a real difference until we
allow them to change how we think about the value we deliver to our customers.
Continuous Delivery doesn’t replace anything, but rather it enhances every-
thing.

11 Continuous Delivery
11.1 Lesson
11.2 Downloads
11.3 Continuous Delivery
Continuous Delivery is a software development practice where code changes
are automatically built, tested, and prepared for a release to production. It
expands upon Continuous Integration by deploying all code changes to a testing
environment and/or a production environment after the build stage.

32
11.4 Key Concepts
• Automated Testing: Ensures that the software is reliable and reduces
the need for manual testing.
• Staging Environment: A pre-production environment used for final
testing before deployment to production.
• Deployment Pipeline: Automates the steps required to get the software
from version control into the hands of users.

11.5 Benefits of Continuous Delivery

• Faster Time to Market: Automating the software release process re-
duces the time to deliver new features and updates.
• Improved Productivity and Efficiency: Automating manual tasks
frees up developers to focus on feature development.

• Reduced Risk: Smaller, more frequent updates reduce the risk of each
deployment.
• Increased Release Frequency: Allows organizations to release software
more frequently and predictably.

11.6 Question 1 of 3
Which of the following is a key benefit of Continuous Delivery?

• Increased manual testing

• Slower time to market

• Reduced risk of each deployment

• Less frequent updates

11.7 Question 2 of 3
What is a staging environment used for in Continuous Delivery?

• Initial code development

• Final testing before deployment to production

• Version control
• Automated code integration

33
11.8 Question 3 of 3
What does a deployment pipeline automate?

• The steps required to get the software from version control into the hands
of users
• The initial coding process

• Manual testing procedures

• Version control management

12 Conclusion
12.1 Lesson Review
In this course, we explored the core practices of DevOps, including Infrastruc-
ture as Code, Configuration Management, Continuous Integration, Continuous
Delivery, and Automated Testing. We discussed the importance of these prac-
tices in modern software development and how they contribute to more efficient,
reliable, and rapid software delivery.
We also delved into the specifics of Continuous Integration and Continuous
Delivery, understanding their key concepts, benefits, and how they fit into the
overall software development lifecycle. By adopting these practices, teams can
achieve higher productivity, reduced risk, and faster time to market.
Thank you for joining us on this journey through the heart of DevOps. We
hope you found this course informative and valuable in your quest to improve
your software development processes.

34