►
From YouTube: Continuous Integration and Continuous Delivery Pipelines for Beginners and Managers - Ann Marie Fred
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Continuous Integration and Continuous Delivery Pipelines for Beginners and Managers - Ann Marie Fred, Red Hat
Virtual Track
Speakers: Ann Marie Fred
If you keep hearing about Continuous Integration or Continuous Delivery, but you don’t know what these CI/CD Pipelines really do, this is the talk for you. We’ll run through a series of tasks or steps that are commonly handled by CI/CD pipelines. For each, we’ll see what the task does, why it’s important, what inputs and outputs are involved, and what side effects to expect. If you already use CI/CD, this talk could inspire you to do more, especially in the realm of DevSecOps and compliance automation. Build your CI/CD foundational knowledge based on shared vocabulary from the CD Foundation Interoperability SIG! #SBOM
A
Hey
everybody:
this
is
anne-marie
fred,
I'm
a
senior
principal
software
engineer
at
red
hat
and
today
I'm
going
to
talk
to
you
about
ci
cd
pipelines.
This
is
geared
towards
beginners
and
managers,
but
I'm
going
to
throw
in
a
few
interesting
things
for
people
who
are
typing
in
interface,
nerds
or
interested
in
the
interoperability
of
pipelines
as
well.
A
A
I
also
spent
three
years
helping
out
as
a
devops
days
conference
co-organizer
and
I'm
currently
active
in
a
couple
products
in
the
linux
foundation
and
cd
foundation,
including
the
interoperability
sig
and
the
artelias
project.
I
spent
three
years
as
an
hr
manager,
which
helped
me
learn
a
lot
about
compliance
and
privacy
and
security
regulations.
A
A
A
A
So
this
is
a
talk,
that's
geared
to
beginners,
but
I
hope
experts
will
get
something
out
of
it
as
well.
If
you're,
a
beginner,
think
about
how
you
might
use
these
different
tools
and
techniques
in
your
own
development
processes
and
if
you're
an
expert,
please
read
between
the
lines
and
think
about
how
you
can
help
us,
standardize
the
inputs,
outputs
and
side
effects
of
each
of
these
tools
and
techniques
to
make
them
more
reusable.
A
A
So
the
interoperability
sig
aims
to
enable
a
dialogue
in
the
interoperability
area
by
bringing
ci
cd
users
together
with
the
open
source
projects
and
just
a
couple
things
to
highlight
here.
They
they
want
to
promote
the
needs
of
the
users
who
face
challenges,
constructing
these
complex
end-to-end
flows,
using
different
tools
and
technologies,
and
also
explore
the
synergies
between
and
enable
collaboration
across,
the
different
projects.
A
So
why
does
a
shared
vocabulary
even
matter?
Well,
as
a
user
of
ci
cd
pipelines,
I
want
to
be
able
to
think
and
talk
about
them
with
people
who
use
different
tools
in
a
coherent
way.
The
devops
world
is
open,
there's
many
different
tools
and
techniques.
We
don't
want
to
be
locked
into
one
and
it
really
helps
if
we
can
share
best
practices
with
each
other,
and
we
also
need
to
have
one
tool:
that's
generating
some
outputs,
another
one,
that's
consuming
those
inputs,
so
we
need
to
have
these
tools
understand
each
other.
A
At
this
website,
the
the
interoperability
sig
vocabulary
website
you'll,
see
things
like
common
terminology:
that's
used
by
ci
cd
tools
as
well
as
source
code
management
tools,
technologies,
a
mapping
of
terms
which
I'll
show
you
a
little
screenshot
of
later
between
the
different
tools.
So
you
can
see
you
know
if
this
means
step
means
the
same
thing
as
task
and
another
tool
and
also
the
shared
vocabulary.
A
A
So,
as
a
software
professional,
I
want
to
automate
as
much
of
my
manual
tool
as
possible,
like
software
development
deployment
operations,
to
support
these
all,
have
many
repetitive
tasks
and
they're
boring
and
they're
a
waste
of
time
unless
we
automate
them.
So
some
organizations
have
people
who
specialize
in
such
automation.
A
Continuous
delivery
is
a
software
engineering
approach
in
which
teams
produce
software
in
short
cycles,
ensuring
that
the
software
can
be
reliable,
leased,
reliably
released
at
any
time
and
when
releasing
the
software
without
doing
so
manually
contrast
with
continuous
deployment.
That's
a
software
engineering
approach
in
which
software
functionalities
are
delivered
frequently
through
automatic
deployments.
So
in
continuous
delivery.
The
software
functionalities
are
frequently
delivered
and
potentially
capable
of
being
deployed,
but
are
not
actually
deployed.
A
A
stage
is
a
unit
of
work,
that's
one
degree
smaller
than
a
pipeline,
and
these
may
be
implemented
sequentially
in
parallel
or
in
some
combination
of
both
and
then
a
step
is
the
next
smaller
unit
of
work
about
two
degrees
smaller
than
a
pipeline,
and
this
is
something
you
can
think
of.
That
would
typically
be
implemented
as
several
lines
of
code.
A
So
here's
an
example
of
that
mapping
table
that.
I
was
talking
about
from
the
website
that
I
pointed
you
to
you
can
see.
You
know
there's
some
consensus
about
what
generally
a
pipeline
is,
but
like
harness
maps
pipeline
to
a
different
level
than
the
others,
and
some
of
them
call
it
a
workflow
right.
A
A
A
Now,
pipeline
steps
or
tests
are
where
the
low
level
implementation
happens
and
that's
what
we're
going
to
talk
about
most
of
the
time
here
now
as
a
pipeline
developer.
If
I
know
where
to
look,
hopefully
I
can
find
pre-implemented
pre-tested
steps
and
reuse
them
in
my
pipelines,
but
I
may
have
to
write
them
from
scratch.
A
A
You'll
have
a
workspace
where
you
can
read
and
write
files,
a
way
that
you
can
securely
store
and
retrieve
secrets
that
you
need
in
the
pipeline
a
way
to
return
results,
including
success
or
error
codes,
a
way
to
control
whether
execution
continues
or
stops
from
that
step.
You
know
we'll
continue
on
to
further
steps,
or
will
it
end
right
there
and
then
log
storage
in
retrieval
facilities.
A
First,
a
few
terms
that
you
might
see
in
here
I'll
talk
about
software
source,
binary
source
generated
software
and
generated
binaries,
so
software
source
includes
all
your
human,
readable
files
that
come
into
your
pipeline,
usually
from
your
source
code
management
system,
things
like
source
code,
configuration
files,
documentation,
source
files,
your
declared
dependencies,
like
your
package
lists
and
baseline
composition.
Information
like
if
you
have
lock
files
in
your
search
control
system,
then
your
binary
source
are
executables
that
are
inputs
into
your
pipeline.
Things
like
your
executable
software
dependencies,
your
container
images
and
virtual
machine
images.
A
The
generated
software
is
generally
outputs
from
your
pipeline,
and
these
are
human
readable
files
like
compiled
software,
generated
configuration
files,
compiled
documentation
and
baseline
or
composition.
Information
that's
been
generated
by
the
pipeline
like
new
file,
new
lock
files
or
bill
of
materials,
and
then
your
generated
binaries
are
executables
that
are
out
output
to
the
pipeline.
Like
executable
software,
container
images
and
virtual
machine
images.
A
A
This
is
also
called
things
like
initialize
start
prepare
workspace
or
orchestrate
and
as
an
output
of
this
you're,
going
to
get
your
secrets
ready
for
you
to
use
your
pipeline
environment
and
your
pipeline
workspace
as
inputs,
you
might
have
your
triggers
or
your
cross
parameters
and
maybe
you're
specifying
the
pipeline
container
image,
name
and
version,
or
what?
What
version
of
software
of
your
programming
language?
You
intend
to
use
right,
interesting
side
effects.
It
might
be
setting
up
some
persistent
storage
or
another
method
for
the
pipeline,
steps
to
share
inputs
and
outputs
with
each
other.
A
General
in
a
test
step,
we'll
run
a
test
suite,
so
examples
of
these
might
be
unit
tests,
integration
tests,
acceptance,
tests,
performance
tests,
canary
tests,
a
b
test
smoke
tests,
code
coverage
checks.
There
are
many
different
kinds
of
tests
you
can
run
and
most
pipelines
will
run
more
than
one
of
these
and
we'll
get
outputs
like
the
test
results
and
test
coverage
reports.
A
In
a
tag
step,
we'll
annotate
source
code
and
artifacts
and
images,
and
so
on
with
information
such
as
the
version
number
and
description,
so
this
is
like
generated
metadata
and
we're
going
to
tag
it.
So,
for
example,
we
might
be
adding
tags
to
a
certain
commit
or
version
in
our
source
code
management
system
or
in
our
image,
repository
in
a
publish
step,
we'll
upload
software
artifacts
and
documentation
to
another
repository.
A
A
A
Then
we
verify
the
deployment
to
make
sure
it
was
successful.
Sometimes
it's
called
this
is
called
a
smoke
test
and
as
inputs,
we'll
use
those
routes
and
secrets
that
we
got
from
the
previous
step
and
run
some
quick
tests
against
the
environment
and
we'll
get
back
our
deployment,
verification
results
and
records.
A
A
A
Secret
detection
detects
secrets
in
the
source
code,
other
software
or
documentation,
for
example,
if
somebody
actually
accidentally
commits
a
password
or
an
ssh
private
key
or
something
into
their
source
code.
There
are
tools
that
can
detect
that
automatically.
For
you,
an
interesting
side
effect
of
this
is
that
the
tools
are
often
capable
of
also
revoking
the
secrets
automatically,
which
is
honestly
a
great
feature,
because
it
protects
developers
from
leaving
a
hole
in
your
environment,
a
security
hole
and
they'll
usually
notice
the
problem
more
quickly
when
their
keys
stop
working.
A
A
A
remediate
step
is
one
that
can
find
and
automatically
fix
known
vulnerabilities
for
application
package,
dependencies,
container-based
images
and
operating
system
packages.
Often
what
a
remediate
step
will
do
is
search
your
dependency
list
or
graph
for
dependencies
with
known
vulnerabilities,
then
look
for
a
later
version
of
those
dependencies.
That's
still
within
the
range
that's
specified
in
your
package
list
automatically
update
to
that
latest
version
and
then
rebuild
and
retest
interesting
side
effect.
A
This
might
actually
cause
a
running
system
to
be
updated
if
you're
watching
so
say
your
mediate
step
actually
generates
a
new
container
image
and
publishes
it
to
your
repository.
If,
then,
you
have
another
system,
that's
watching
for
new
versions
in
your
published
repository
and
pulling
them
into
your
production
systems.
This
can
actually
happen
automatically,
which
can
be
good
or
bad
depending
on
how
much
you
trust
your
testing.
A
A
scan
step
is
where
you
use
it
any
tool
to
do
verification
of
software
and
documentation
other
than
testing.
So
examples
of
this
include
static
code
analysis,
linting,
checking
for
known
vulnerabilities
in
your
code
or
your
binaries.
Dynamic
security.
Scans
testing
license
checks
to
make
sure
that
the
licenses
of
the
software
that
you're
using
are
compatible
with
what
you're
using
it
for
and
code
smells.
A
A
A
A
So
here's
an
example
of
a
prototype
that
uses
these
types
of
standard
steps
that
I
created
in
tecton,
so
you
can
kind
of
see
how
it
works.
So
you
see
here
at
the
left,
there's
a
setup
stage
or
step
sorry
and
then
clones
the
source.
It
does
a
build
it
packages,
things
it
does
a
discovery
of
the
dependencies.
A
A
And
after
we've
provisioned
and
published
what
we
need,
then
we
can
go
ahead
and
deploy
to
our
test
environment
and
verify
it,
and
we
can
do
some
scans
like
twist
lock
and
some
acceptance,
tests
and
dynamic
security
testing.
Then
we're
going
to
clean
up
our
deployment
and
record
the
results
of
that
and
at
the
end
kind
of
cut
off
there
we'll
send
a
slack
message
to
the
team
reporting
on
how
it
went
also
up
here.
A
A
And
there's
even
more
available,
so
in
an
analyze
step
you
provide
additional
processing
and
analytics
based
on
the
results
of
a
previous
activity.
Sometimes
these
are
called
things
like
metrics
score
grade
or
parse,
and
it
will
generate
some
kind
of
analysis
report
that
can
either
be
used
for
further
automation
or
for
people
to
just
watch
and
see
what
the
health
of
the
system
is.
A
A
message
step
is
where
you're
going
to
send
a
message
to
another
system,
for
example
a
slack
message
or
an
email.
We
have
another
type
of
step
called
create
request,
that's
different,
because
the
pipeline
doesn't
necessarily
need
to
store
a
link
or
handle
for
the
message.
It's
just
to
send
it
and
forget
it.
Sort
of
thing.
A
A
A
If
you
try
to
write
a
perfect
uncustomizable
pipeline
for
everybody,
you're
just
going
to
end
up
with
50
different
pipelines
that
you're
maintaining
so
the
solution
we
want
is
that
we
can
chain
together
trusted
steps
and
tasks
into
a
customized
pipeline
while
still
knowing
that
the
steps
were
trusted
and
that
we
know
what
the
steps
we're
checking
and
in
order
to
do
that,
we
need
standard
stepper
task
types.
So
this
is
a
starting
point
that
lets
us
build.
What
we
need.