►
Description
Want to know how to properly setup Red Hat OpenShift CI/CD pipelines and GitOps processes? Don't know what CI/CD stands for? Continuous Integration (CI) and Continuous Delivery (CD) are methods to automate the build, test and release of new software versions. In this episode, we'll explain the basics, cover some of the challenges of CI/CD pipelines, and learn why Red Hat OpenShift is a good solution for this. So join us to dig into what steps are needed for administering CI/CD services on OpenShift, and find out how CI/CD can help you become more agile by automating and streamlining the steps involved in going from an idea to a final product.
Follow us:
Randy Russell https://www.linkedin.com/in/randy-russell-0312243
Jaafar Chraibi https://twitter.com/ChraibiJc
Scott McBrien: https://twitter.com/
What is the Level Up Hour?
Every Wednesday at 9am ET we stream live demos on how Red Hat Enterprise Linux (RHEL) users and admins can benefit their organizations and improve their careers by learning how to use containers, Kubernetes, and Red Hat OpenShift.
Learn more at:
https://red.ht/leveluphour
http://red.ht/3ayHlHI
How to participate in the The Level Up Hour:
Watch on YouTube every Wednesday at 9amET
Chat with us on Discord https://discord.gg/5VMVGJt
Check out our GitHub repo https://github.com/level-up-hour/
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
https://www.openshift.com/
https://github.com/openshift/
#RedHat #OpenShift #tluh
A
A
A
A
A
A
B
So
I'm
joined
today
by
my
colleague,
scott
mcbrian,
otherwise
known
as
stabby,
and
we
have
our
guest
today
vincent
the
maester
and
mayor
friedman,
who
are
going
to
share
some
of
their
knowledge
about
what
all
of
this
is
about.
When
you
hear
these
these
letters
cicd,
I
just
want
to
remind
everybody:
please
do
like
subscribe
and
share
to
everyone.
B
Let
people
know
that
we're
on
air
and
let's
jump
right
into
this,
so
we're
talking
today
a
little
bit
about
about
get
ups
and
cid
cicd
pipelines,
and
so
you
know
like
a
lot
of
acronyms
these
get
I
have
bandied
about,
and
everybody
assumes
that
everybody
knows
what
they
are
but
vincent.
Maybe
why
don't
you
share
with
us?
What,
with
a
sea
ice,
what
is
cicd.
C
So
I
think
the
ci
part
is
kind
of
close.
Like
everybody
understand
the
ci
part,
I
think
for
everybody,
it
means
continuous
integration
and
it
means
all
of
even
continuous
integration
can
mean
different
things
for
different
people,
but
usually
it
means
I
build
on
each
commit
or
hpr
which
whatever,
but
on
each
change
that
me
and
my
team
do.
C
C
The
cd1
is
like
really
really
more
difficult,
because
people
will
put
different
meanings
behind
cd,
it's
gonna
be
continuous
deployments,
it's
gonna
be
continuous
delivery
and
and
if
you
dig
a
little
bit
more
into
those
two
and
even
more-
I
I
I
don't
have
any
other
meaning
in
my
head,
but
it
can
depend
different
things
like
continuous
deployment,
at
least
in
mind
means
anytime.
There's
a
change
is
deployed
somewhere,
but
continuous
delivery
doesn't
necessarily
mean
this.
B
Explain
to
us
our
audience
again,
thinking
that
above
the
folks
who
are
coming
more
from
that
infrastructure
background.
What
is
it
when
you're?
What
is
it
you're
doing
when
you're
doing
integration?
Forget
it
continuous
forget
making
it
continuous
when
you
do
an
integration
exercise?
What
is
it
that
the
developer
is
doing.
A
So
I'll
try
to
to
look
at
this
from
the
infrastructure
perspective,
and
I
have
to
start
with
the
words
continuous
integration,
unfortunately,
because
the
the
whole
essence
of
continuous
integration
is
to
supply
confidence
that
proposed
changes
will
actually
work
as
intended
and
and
as
vincent
said
there
are.
There
are
many
perspectives
to
to
look
at
ci
and
where
it
happens,
it
can
either
happen
on
on
a
pull
request.
It
can
happen
after
the
merge,
so
different
schools
tell
different
stories
as
to
what
ci
is,
but
essentially
from
from
the
infrastructure
perspective.
A
A
C
A
C
C
C
When
we
talk
about
continuous
data
rates,
it
encompass
a
broader
scope,
it
can
be
the
whole
process
that
goes
from
source
code
commits
to
the
actual
deployment,
and
in
this
process
there's
there
can
be
manual
approval
there
can
be.
If
the
sets
of
events-
that's
gonna,
I
don't
know
for,
for
example,
for
container
image.
That's
gonna
run
some
security
checks
on
an
image
and
wait
for
it
to
get
back
et
cetera.
So
the
continuous
deployment
is
just
a
smaller
view
of
what
continuous
delivery
is.
D
And
so
this
is
a
change
in
thinking
and
says:
hey,
let's
take
a
lot
smaller
bytes
of
that
elephant,
so
that
we
can
have
a
lot
less
risk
at
each
incremental
change
so
that
overall
we're
getting
to
a
better
outcome
with
our
software
product.
And
so
you
know
by
breaking
up
the
changes
to
be
much
smaller
and
more
consistent,
we're
minimizing
the
amount
of
risk
to
our
infrastructure
for
each
individual
change
rather
than
being
like.
Okay,
we're
we're
running
this
version
on
this
operating
system
cool.
Let's
completely
change
everything
and
redeploy
it.
D
B
But
at
the
end
of
the
day,
the
your
strategy
for
testing
integration
and
pushing
that
thing
out
has
to
be
consistent
with
having
that
actual
design
right
all
right.
So
that's
that's
that
world
of
cicd,
and
so
we've
talked
a
little
bit
about.
Why
would
people
implement
cicd,
and-
and
I
guess
I
I
would
ask
again
vincent
and
mayor-
is:
is
there
something
that
we've
missed
here
that
if,
if
we're
thinking
about
you
know
an
I.t
organization
that
might
not
be
doing
this?
C
I
think
mars
said
confidence.
I
think
this
is
the
main
really
main
benefit,
because
the
more
you
build,
the
more
you
try
things
the
more
you
test,
your
your
changes,
the
more
you
will
be
confident
that
it's
going
to
work
when
you
actually
deploy
it.
So
I
would
say
the
main
benefit
is
going
to
be
confidence,
so
that
kind
of
confuses
driven
development,
and
I
would
also
assume
that
the
more
people
will
drive
will
go
towards
cicd
the
more
they
will
have
the
will
to
automate
things
and
simplify
their
day-to-day
work.
C
A
I
think
it
will
also
reduce
a
lot
of
the
day-to-day
effort
allowing
people
at
the
various
companies
to
focus
on
what
matters
and
what
and
the
things
that
are
more
interesting.
I
mean
I
can
do
the
same
thing
over
and
over
again,
eventually
I'll
get
tired.
I
want
something
to
something:
someone
or
doesn't
matter
something
to
do
it.
B
Right
well-
and
you
know
what
you
were
just
saying
suggest
to
me-
and
this
you
know
I
think
is
understood
to
be
an
underlying
truth
too,
is
that
there
has
to
be
a
bit
of
a
culture
change
within
an
organization
once
you
start
going
down
this
path.
Is
that
it's
not
enough
to
simply
say
that
you
have
erected
the
infrastructure
and
the
you
know
the
pipelines
that
everything
flows
through
there
has
to
be
a
different
way
of
thinking
and
acting
and
working
together.
A
A
We
need
the
ci
cd
pipeline
to
be
able
to
implement
traceability
in
such
a
way
that
no
matter
where,
in
the
in
either
the
supply
chain
or
in
the
environments,
you
look,
you
can
see
exactly
where
everything
came
from
what
pipeline
deployed
those
changes.
Where
was
that
pipeline
created?
What
triggered
the
pipeline?
What
are
the
the
code
changes
that
were
introduced,
or
what
is
the
process
that
caused
the
current
environment?
To
look
like
it
does
so,
traceability
is
super
important.
A
I
also.
I
also
think
that,
to
a
certain
degree,
what's
important
in
these
processes
and
something
that's
important
to
design
up
front
is
reproducibility.
We
want
the
pipelines
to
generate
the
same
results
every
time
they
run,
regardless
of
when
they,
when
they
run
and
and
with
that
also
comes,
also
comes
thoughts
about.
A
When
am
I
going
to
do
each
action
in
my
pipeline,
and
am
I
okay
for
choosing
to
do
several
actions
more
than
once?
One
example
would
be
if
you're
deploying
onto
openshift
and
you
use
container
images
and
you
deploy
something
promote
something
to
production.
It's
important
that
the
promotion
notion
stays
with
you,
as
in
I
am
promoting
a
certain
version
of
my
of
my
code
base
of
my
of
my
binaries
artifacts
deployment
manifests
whatever
it
is,
I'm
promoting
something
that
was
already
built
and
tested
in
stage.
A
So
there
are
I've,
seen
multiple
examples
of
pipelines
that
build
the
container
image
more
than
once,
for
example,
once
for
the
deployment
in
state
one
for
production.
So
I
try
to
avoid
these
things
already
in
the
design
phases
of
the
pipeline
and
and
and
practically
one
of
the
important
things
to
to
consider
is
how
the
pipelines
match
the
current
working
practices
of
the
organization.
A
One
example
will
be
the
branching
strategy.
The
cicd
pipelines
need
to
match
the
branching
strategy
for
them
to
actually
deliver
what
they
need
to
deliver,
which
is
a
seamless
experience
for
a
developer
from
merging
their
code.
To
that
code.
Being
in
production,
so
it
has
to
match
the
current
working
processes
that
are
already
established
and
and
obviously
more
technical
things
like
the
structure
of
the
different
repositories
and
whether
there
are
differences
and
what
will
they
be
and
how
do
you?
How
do
you
generalize
everything
into
a
single
concept
and
then
implement
the
differences.
B
B
C
A
C
And
this
used
to
be
something
you
didn't
really
have
a
choice
in
the
past,
but
now
with
with
the
rise
of
container
images.
This
is
right.
If
you
design
your
steps
and
your
pipeline
correctly,
you
each
and
every
actual
unit
of
work
doesn't
even
need
to
know
that
it's
part
of
a
pipeline,
you
just
need
to
have
a
set
of
inputs,
a
set
of
outputs
and
and
not,
and
then
you
can
use
this
elsewhere.
I
don't
know
today
you
you're
using
tekton
for
your
ci
cd
tomorrow,
it's
going
to
be
something
else.
C
If
you
design
it
well,
you
just
kind
of
have
to
move
to
a
new
language
of
description,
but
the
actual
core
value
of
what
your
ci
cd
does.
Is
there,
and
usually
you
see,
this
is
one
of
the
pitfalls
you,
you
tend
to
tie
yourself
a
lot
to
whatever
the
tool
you're
using
and
then,
when
this
tool
is
not
maintained
anymore
or
when
it's
like
a.
B
So,
on
that
note
mayor,
I
do
want
to
return
back
to
that
question
on
the
on
the
branching.
Again,
I
want
to
sort
of
explore
some
of
the
pitfalls
that
were
that
an
organization
might
bump
into
when
they
are
doing
ci
cd.
You
called
that
out
and
I
can
kind
of
imagine
that,
but
give
us
a
little
bit
more
color
around
what
happens
if,
for
example,
your
branching
strategy
is
not
consistent
between
your
pipeline
and
and
and
how
you
actually
do
branching
in
your
code
base.
A
So
I
think
that
vincent
actually
answered
that
question,
maybe
without
even
understanding
it,
the
one.
The
pitfall
that
he
mentioned
was
not
tying
your
ci
cd
system
into
the
orchestrator
or
build
tool
like
jenkins
or
whatever
else
you're
using
now.
We've
all
done
it
in
the
past.
We
only
you
only
learn
what
not
to
do
by
actually
doing
it.
In
the
past,
I
even
have
blog
posts
saying
you
should
tie
to
the
build
system.
A
Let's
stick
to
the
git
example
and
when
you
stick
to
git
to
either
tag
your
artifacts
or
define
what
you
want
to
deploy
and
promote
and
when
you're
actually
loosening
yourself.
Decoupling
yourself
from
the
build
system
by
using
the
git
commits,
for
example,
a
relation
between
a
ci
cd
between
cicd
pipelines
and
branching
strategy
may
be.
A
Whenever
someone
merges
something
to
the
development
branch
right
assume.
Some
an
organization
is
working
with
git
flow.
Whenever
someone
merges
to
the
develop
branch,
we
want
an
image
built
and
deployed
to
the
dev
environment,
and
then
you
have
the
main
branch
and
whenever
someone
merges
or
something
gets
merged
into
the
main
branch,
we
want
the
image
the
artifacts
built
again
and
then
we
want
to
deploy
to
stage.
A
So
that
is
already
a
connection
to
a
possible,
very
minimal,
merging
strategy,
with
a
develop
branch
and
a
main
branch
and-
and
that
may
also
connect
to
the
previous
points
about
continuous
deployment
or
delivery,
which
is
indeed
the
difference
in
the
process.
And
if
there
is
a
button
involved
there
in
the
middle
or
not
or
at
least
that's
what
the
legend
says
and
when
you
want
to
this.
A
So
everything
from
the
main
branch,
at
least
in
our
branching
strategy,
goes
directly
to
the
stage
environment
after
it's
been
tested
in
a
dev
environment
prior
and
when
we
want
to
promote
something
to
production,
we
again
go
to
emerging
to
a
branching
strategy,
which
is
don't
do
anything
just
choose
a
commit
shot
that
worked
in
stage
and
promote
that.
So
we're
very
gitopsy
in
that
way
and
we
are
decoupled
from
the
build
system,
which
is
a
pitfall,
and
we
also
did
a
sort
of
connection
between
a
git
branch
and
an
environment.
A
B
All
right,
yeah,
so
scott
anything
you
want
to
add
on
any
of
this.
You
know
because
I
think
this
is
a
natural
transition
for
us
to
maybe
start
talking
about
about
what
are
some
of
these
tools
that
people
use,
because
because
I
think
there
are
things
that
we
offer
and
that
can
help
with
this.
But
before
I
turn
to
that,
is
there
anything
from
your
experience
or
from
what
you
hear
from
customers
that
seem
to
be
some
of
the
pitfalls
that
they're
bumping
into.
D
I
was
just
really
excited.
I
mentioned
this
in
chat
to
hear
mayor
talk
about
promoting
artifacts
throughout
the
pipeline
instead
of
rebuilding
at
each
stage,
because
you
know
there's
been
more
than
once,
where
maybe
even
at
the
crimson
haberdashery,
where
production
systems
in
no
way
match
dev
or
stage
you
don't
find
out
until
you
actually
deploy
it,
and
it's
like,
oh
no,
so
it
was
that
was
excellent.
B
All
right
well,
so
let
me
come
back
to
this
question.
Then
you
know
on
the
tooling
and-
and
you
know
vince,
you
raised
some
interesting
questions
in
points
about
sort
of
where
the
build
system
fits
in.
But
let's
look
at
this
from
a
broader
perspective
in
terms
of
what
is
the
tooling
that
people
are
using
to
be
able
to
build
effective,
ci
cd
pipelines?
What
is
it
that
that
we're
recommending
and
thinking
that
are
tools
that
can
lead
to
success
in
a
variety
of
organizations.
C
So
I
think
the
the
the
tool
that
everybody
knows
is
and
and
where
everybody
has
a
kind
of
a
love-hate
relationship
with
is
jenkins.
It
has
been
around,
for
I
don't
know,
probably
20
years
or
so,
and
this
is
like
this
shows.
This
is
up
until
even
now
there's
new
alternative
and
we
are
developing
new
alternative,
but
up
until
now,
I
think
this
is
still
the
main,
the
main
tool
that
everybody
knows.
C
It
comes
with
a
lot
of
pitfalls
because
it
it
started
20
years
ago,
so
containers
doesn't
know
cube.
It
doesn't
know,
there's
a
lot
of
things,
it
doesn't
know,
and
it
has
been
architecture
with
this
plug-in
mechanism
with
this,
which
is
super
nice
super
awesome,
but
when
you
have
1
billion
plugins
and
how
you
manage
updates
it's
right,
it's
like
it.
It
comes
with
a
lot
of
problems
and
on
the
openshift
side
we
do.
C
We
did
a
ship
with
a
jenkins
instance
in
openshift
three
we
still
do
in
in
g4,
but
those
are
kind
of
really
hard
to
maintain
and
administer
mainly
because
it's
been
depending
on
what
you
use
of
your
cluster
and
what
teams
are
there?
You
might
need
or
want
a
different
championship
for
each
team,
because
each
team
has
different
needs.
Each
team
might
want
to
build
and
need
this
plugin,
the
other
one,
the
other
plugin
but
different
version,
etc.
B
Oh,
what
a
coincidence
so
so
scott!
Let
me
just
let
me
let
me
divert
a
bit
from
that.
So
certainly
jenkins,
it's
been
around
for
a
long
time
and-
and
I
think
vince
makes
a
great
point
that
that
it
precedes
in
many
ways
some
things
that
are
really
sort
of
central
to
the
world
of
cicd.
At
this
point,
but
you
know
you're,
you
get
feedback
from
our
rel
customer
base
are.
Is
there
any
other
tooling?
D
I
mean
I
think
that
jenkins
is
kind
of
the
widely
used
tool
for
a
lot
of
stuff,
but
because
it's
used
for
a
lot
of
things
as
vincent
pointed
out
it
it
gets
really
gnarly,
because
to
do
everything
well,
you
can
do
or
to
do
everything
you
could
do.
No
single
thing
really
well,
there's
a
been
a
bunch
of
other
kind
of
sas
offerings
that
people
can
use
and
but
yeah,
I
think
jenkins
is
kind
of
the
beast.
Everyone
knows.
B
B
You
know
some
an
organization
to
do
when
they
have
this
objective
of
building
cicd
pipelines
that
you
know
achieve
those
objectives
we
talked
about
earlier
and
that
you
know
in
some
way
can
align
to
their
particular
approach
to
to
building
code
and-
and
you
know,
to
their
application
life
cycle.
So
mayor
tell
me
a
little
bit
about
you
know
what
openshift
brings
to
this
picture
that
maybe
has
been
missing,
or
that
is
especially
effective.
A
A
We
use
jenkins
job
builder,
so
it's
easier
for
us
to
compose
different
jobs
of
different
types
and
and
to
even
allow
our
users
to
to
to
take
advantage
of
that.
But
eventually,
I
think
the
the
the
common
correct
characteristic
and
and
what
we've
been
going
for,
or
what
what
vincent's
team
have
been
going
for
and
we
received
as
customers
is,
the
concept
of
of
of
building
small
small
boxes
and
stacking
them
together
in
every
way
that
we
want
so
openshift
pipelines.
They
come.
A
They
come
in
in
a
very
it's
a
very
generic
tool.
Every
pipeline
that
you
can
imagine
eventually
is
a
pipeline
and
a
pipeline
is
divided
into
tasks
and
each
task
may
have
one
step
or
more
and
that's
and
that's
the
the
concept
and
when
you
are
able
to
build
different
pipelines,
but
have
the
steps
reusable.
A
It
brings
a
huge
advantage
and-
and
it's
not
even
some-
I
mean
with
jenkins
specifically,
you
would
need
to
actually
define
each
and
every
job
and
and
find
your
way
to
reuse
components
with
yaml
magic
and
things
of
that
sort,
which
is
never
fun.
We
ended
up
one
time
with
a
5
000
line
file
of
janky's
job
builder,
definitions
for
for
a
single
project
for
a
single
product,
now
you're
running
and
our
team
currently
runs
over
50..
A
So
imagine
what
would
have
happened
if
we
kept
going
that
route,
but
I
think
what
openshift
brings
to
the
table
is:
is
the
elasticity
that's
the
most
important
feature
that
it
brings,
and
that
is
the
reason
we
migrated
all
our
cd
processors
from
jenkins
to
openshift
pipelines
because
of
the
elasticity,
no
matter
how
many
we
used
to
fight
with
jenkins,
we
used
to
tell
tenants
not
to
promote
to
too
frequently
not
really.
In
those
words
right,
we
told
them
yeah.
A
We
were
encountering
overload
constantly
with
too
many
deployments
happening
at
the
same
time
and
with
openshift.
It
just
doesn't
happen
because
the
cluster
can
be
defined
with
autoscaling
and
you
deploy
as
many
resources
as
you
want,
also
need
to
clean
up,
because
these
are
custom
resources
and
lcd
etsy.
C
Yeah,
I
was
going
to
say
I
think,
just
to
add
to
that.
One
of
the
goal
of
appreciative
pipeline,
which
is
based
on
the
upstream
projection,
was
to
also
kind
of
speak,
the
same
language
or
be
more
close
to
what
you
used
to
deploy,
because
in
the
end,
right
that
openshift,
pipeline
or
tecton
is
just
an
extension
on
top
of
cube.
We
are
using
clds,
etc.
So
you're
you're
gonna
be
able
to
use
everything
single
tool
that
we
that
you
use
to
manage
your
clusters,
etc.
C
You
can
use
them
also
with
tecton,
and
that's
that's
kind
of
was
one
of
the
the
goal
and
yeah
as
mars
said
like
one
of
the
other
goal,
was
composibility
and
reusability
be
able
to
easily
define
tasks
with
multiple
steps,
but
things
that
are
reusable
so
that
you
define
them
once
you
can
even
share
them
somewhere
and
we
do
have
a
community
sharing
place
somewhere
for
command,
used
tasks
and
and
and
from
there.
You,
you
just
like
get
your
pipeline,
and
you
occur
straight.
A
I
think
you
hit
the
goal
on
spot
with
customers
reusing
the
same
systems
they
already
used
to
deploy
their
services.
We
did
exactly
the
same
thing,
our
team,
which
is
a
customer
of
openshift
pipelines.
We
have
this
repo
that
we
use
to
define
and
deploy
all
the
services
that
we
run
into
different
openshift
clusters
and
and
openshift
pipelines
just
came
naturally
into
that
picture.
We
reused
the
same
system,
of
course,
and
it
was
one
of
the
one
of
the
best
migrations
that
we
did
from
jenkins
to
openshift
within
the
same
system.
B
B
B
B
A
All
right
so
so,
I
think
first
of
all,
the
the
definition
of
roles
may
be
different
in
every
organization
and
and
eventually
we
need
to
to
formulate
the
relationship
between
the
different
roles
in
an
organization
in
order
to
decide
who
does
what
a
sort
of
I'll
use
a
word.
My
team
uses
a
lot
a
contract
between
each
layer
of
people
supplying
in
so
in
our
in
our
team.
For
example,
we
are
responsible
for
the
cd
process
as
a
whole,
our
the
services
that
we
run
the
development
teams.
A
They
come
with
their
source
code
and
we
have
a
sort
of
a
contract
that
they
put
their
deployables
in
their
in
their
code,
repo,
and
we
are
responsible
for
the
pipelines
themselves
and
and
they
are
receiving
that
as
a
service.
So
in
this
example,
the
ops
team
is
responsible
for
not
only
supplying
the
pipelines
but
also
for
building
designing,
maintaining
them,
while
the
developers
in
this
equation
are
responsible,
in
our
case
at
least,
to
define
their
pipelines
in
a
declarative
way.
We
have
this
system,
I
started
talking
about
I'll,
say
its
name.
A
App
interface
contract
reconcile
go
look
at
our
github
organization.
It's
awesome
so
so
this
system
allows
the
teams
that
that
we
service
to
define
in
a
declarative
way
what
they
want
deployed
where,
according
to
the
branching
strategies
we
mentioned
earlier
so
they're
going
to
say
something
like
this
is
my
repo
and
in
this
path,
you'll
find
my
deployable.
I
want
it.
A
C
A
B
B
C
C
C
Building
the
code
testing
the
code
etc
to
their
needs,
with,
of
course,
discussion.
Negotiation
contract
with
the
the
operational
role
but
like
it,
it
becomes.
Your
pipeline
becomes
a
set
of
elements
that
are
either
dev
responsibility
or
obvious
responsibility.
The
pipeline
itself
might
be
on
the
responsibility,
but
you
usually
you
have
like.
C
B
Well,
I
know
I
followed
along
and-
and
I
think
this
is
what
what
one
of
the
things
that
comes
across
here-
is
that
it
has
to
be
a
very
collaborative
process
in
which
it's
it's
not
something
that
can
simply
be
installed,
and
now
you
have
this
thing.
That
does
the
thing
it's
there's
a
long,
long
series
of
again
negotiations.
B
B
The
way
you
do
them
now,
you
want
to
move
to
a
new
and
better
way,
but
at
the
same
time
it's
not
like
you
want
to
give
up
the
way
you
do
everything,
and
so
that's
from
a
developer's
perspective
or
from
the
ops
perspective.
It's
let's
take
the
things
that
work
for
us,
but
then
maybe
move
in
some
new
directions
with
ci
cd,
but
also
anticipate.
B
How
do
we
really
actually
push
our
apps
out
as
opposed
to
what
we
imagine
you
know
we're
not
you
know
we're
an
organization
that
might
not
imagine
itself
as
being
an
amazon.
You
know
for
a
netflix
or
whomever
that
you
know
is
pushing
out.
10
000
code
changes
a
day
that
implies
a
somewhat
different
ci
cd
pipeline.
It
implies
a
different
relationship
between
the
developers
and
the
ops
and
many
other
things
right.
B
So
let
me
ask
you
know
if
we
just
get
a
little
more
specific
here,
you
know
what
are
the
administrative
tasks
you
know
what
is
what
is
day
two
for
setting
up
your
your
open
shift
pipelines.
You
know
what
does
that
look
like
for
an
organization,
typically
understanding
that
it's
gonna
vary
from
from
work
to
work.
B
A
All
right
so
I'll
try
to
just
to
tell
a
bit
from
our
experience
what
what
we
had
to
do
so,
I
think,
some
of
the
day
two
operations
as
always
day,
one
is
usually
to
get
started
and
and
get
things
working
and
day.
Two
is
usually
the
improved
part
or
iterate
part
the
day.
One
operations
on
on
openshift,
for
example,
day
one
provision,
a
cluster.
They
do
upgrade
the
cluster.
A
A
So
how
are
you
going
to
onboard
new
teams
into
your
process
that
you've
created
in
in
your
in
your
day?
One
operations?
How
are
you
going
to
handle
an
issue
with
your
pipelines
by
by
by
making
a
single
change
and
having
it
applied
to
all
your
different
environments
into
all
the
different
pipelines
that
are
reusing
this
small
package?
A
So
I
think
a
lot
of
the
data
operations
actually
depend
on
how
you
plan
to
deploy
your
resources
and
that's
again,
that's
a
that's
a
perspective
of
how
you
deploy
your
services,
so
openshift
pipelines
really
just
doesn't
bring
anything
new
into
this
concept.
You've
every
organization
was
already
thinking
of
these
things.
How
do
I
deploy
and
how
do
I
fix
my
code
faster
and
and
those
pipelines?
They
are
just
code
and-
and
I
think
this
is
one
of
the
most
important
things
yeah.
B
All
right
well
yeah,
so
you
know
it's
it.
Ordinarily,
we
hear
a
lot
of
talk
about
day,
two
and
so
on,
but
I
think
the
maybe
the
moral
of
the
story
that
I'm
getting
from
you
today
is
that
you
need
to
get
your
day
one
right,
because
that's
where
you
actually
set
up
the
the
things
that
you're
hoping
will
will
provide
all
these
benefits
down
the
road.
B
B
There
is
that,
on
the
one
hand,
what
we
are
trying
to
do
with
cicd,
and
so
much
of
the
you
know
how
things
are
being
approached
in
this
space
now
is
really
around
trying
to
be
very
agile,
but
at
the
same
time,
if
you're
trying
to
get
all
of
this
right
at
the
same
time,
that's
starting
to
not
sound
so
agile,
and
so
that,
in
my
mind,
raises
raises
this
paradoxical
question:
is
how
do
you
evolve
your
cicd
pipelines
over
time?
Because
you
want
to
make
those
good
decisions
up
front?
B
C
I
I
think
mark
said
something
very
interesting
on
and
the
fact
that
how,
when
you
have
multiple
teams
or
even
multiple
users,
on
your
your
cluster,
that
are
doing
pipelines
and
sharing
things,
how
you
keep
them
up
to
date,
with
whatever
change
you
provide
to
the
pipeline
or
to
the
tasks
themselves,
and-
and
this
is
where
I
think,
when
you
set
up
this-
is
kind
of
for
me
the
day
to
work
of
day.
One
would
be,
I
discovered
the
thing.
Oh,
this
is
nice.
This
is
using
cube
semantics
et
cetera.
C
I
I
can
create
something
and
it's
going
to
be
available,
etc.
But
then
the
data
will
be
how
I
keep
this
available
for
everybody.
Where
is
my
source
of
truth
and
and
from
there?
What?
What
should
I
use
to
update
my
python?
It's
it's
kind
of
easy
there.
It's
like
how
do
I
build
containers
by
building
containers
in
containers?
This
is
a
bit
similar
like
you
can
definitely
have
pipelines
that
manage
actually
the
delivery
of
your
pipelines
in
your
classrooms,
and
you
got
the
food
done.
C
All
all
of
our
pipeline
does
reusable
tasks
right,
they're,
all
defined
somewhere
in
the
social
proof,
which
is
one
of
the
guitars
here,
and
we
do
have
pipeline
itself
updating
itself
validating
itself
and
keeping
any
sort
of
usage
of
this
in
the
cluster.
But
this
is
kind
of
there's
there's
going
to
be
as
much
approaches
as
there
is
teams
almost
like.
I'm
sure,
I'm
assuming
what
would
be
different
from
what
mars
team
does
and
is
going
to
be
different
from
elsewhere.
There's.
B
Well,
actually,
emerging
patterns
gets
me
into
one
of
one
of
the
sort
of
last
questions
in
my
mind,
and
that
is
you
know:
where
is
the
technology
in
support
of
cicd
going?
You
know
in
in
sort
of
that
next
step,
the
next
phase?
What
are
what
are
some
of
the
things
that
you
see
happening
in
this
space
and
that
might
be
might
be
changing,
let's
say
over
the
next
year
or
so.
C
Well,
so
I
think
every
everything
is
is
happening
on
containers
everything
like
every
single
ci
cd
system
right
now,
as
containers
as
its
core
or
some
sort
of
view
of
containers.
Github
action
is
like
you
can
see
them
as
containers
because
they
are
using
the
actual
distribution
format,
even
though
they're
running
vm
behind
the
scene,
but
so
I
think
at
least
I'm
going
to
speak
as
the
lead
of
tecton
is.
C
I
wish
something
like
tekton
would
become
kind
of
a
standard
of
reusability
and
and
by
standard
I
really
mean
the
actual
smallest
unit
in
tecton,
which
is
the
task
because
I
mean
there's
gonna,
be
lots
of
different
ways
to
do
things,
but
when
you
do
want
to
do
a
go,
build
it's
gonna
always
be
the
same.
So
if
you
have
the
image
and
and
a
set
of
parameters
that
you
can
give,
then
your
your
actual
tasks,
never
gonna
change.
C
If
I
don't,
if
github
action
and
gitlab
deals
with
the
name
and
pipeliners
code
from
openshift
or
something
else
is
if
they
are
all
talking
tecton,
then
it's
kind
of
a
win,
because
you
don't
need
to
only
use,
give
up
action
for
on
github
or
bitlab
on
github.
At
start,
you
just
need
to
you,
can
choose
whatever
fits
your
team
or
what
you
think
is
the
important
part
for
your
team,
and
then
you
you
rely
on
whatever
is
able
to
provide
you.
A
Of
course,
but
this
is
a
two
perspective
conversation.
If
you
ask
ops
people,
it
goes
into
being
more
more
abstract
really,
and
if
you
ask
deaf
people
it's
going
away,
they
don't
want
to
be
aware
of
of
see
icd.
They
want
things
to
work
like
we
don't
want
clusters,
we
want
abstract
concept
and
we
want
our
servers
running.
It
doesn't
matter
what's
underneath,
so
I
think
I
agree
with
vincent
everything
is
going
towards
abstractions
and
the
less
you
know
the
the
less
you
know
and
it
still
works
and
as
long
as
everything.
D
B
All
right
well,
thank
you,
gentlemen,
for
for
joining
us
today.
This
has
been
incredibly
incredibly
informative
about
the
world
of
cicd
those
four
letters
get
used,
so
so
so
much
and
and
yet
I
think
that
sometimes
there's
not
a
lot
of
clarity
about
what
what's
under
the
hood
and
what
this
really
involves
and
entails
so
anyway.
Thank
you
again.
B
It
is
that
time
for
us
to
talk
about
sweet,
sweet
internet
points
and
again
here's
where
they're
we're
at
in
the
leaderboard
niren
dev
is
narrowly
ahead,
narrowly
ahead,
and
so
we
will
check
back
in
in
you
know
when
I
we
have
our
next
show
and
we'll
see
how
that
looks.
But
again,
please,
like
please,
share,
please
tell
friends
about
it
when
you
join,
please
ask
us
questions.
Let
us
know
if
there's
anything
that
that
you
would
like
for
us
to
cover
in
future
sessions.