►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Panel Discussion: GitOps & Best Practices for Cloud Native CI/CD - Allison Richardet, Asteris, LLC; Laura Tacho, CloudBees; Ivan Pedrazas, State Street; Tracy Miranda, CloudBees; and Alexis Richardson, Weaveworks
Cloud native technologies enable organisations to scale rapidly and deliver software much faster than before. To do this, organisations need to rethink their CI/CD systems and the best practices their teams use with Kubernetes. GitOps, operation by pull request, is a new paradigm and set of best practices for cloud native. But what does it mean and how can organisations go about adopting it for their CI/CD needs? This panel provides insights into GitOps, best practices for CI/CD for cloud native and tooling that can help automate these practices. It also features end user stories of their experiences learning the best ways to setup CI/CD for their specific applications and needs.
https://sched.co/MPYm
A
Hey
everybody
we're
gonna,
get
started
with
our
panel
discussion
of
get
ops
and
best
practices
for
cloud
native
CI
CD.
Our
moderator
is
Allyson
Richard
it
and
we,
our
participants,
are
Tracy
Miranda,
who
is
director
of
open
source
community
at
cloudBees,
Ivanpah
Drossos,
the
Solutions
Architect
at
State,
Street
Alexis,
Richardson
who's
running
a
little
late
and
will
be
sitting
in
one
of
those
chairs
and
Laura
tacho.
The
director
of
engineering
at
cloudBees
thanks.
B
C
Hello
can
hear
me
yeah,
so
get-ups
verifies
this
operation
by
pull
request
and
probably
say
it's.
You
know
characterized
by
the
fact
that
you're
doing
all
the
operations
in
pull
request
get
is
the
source
of
truth,
and
every
change
you
make
is
observable.
So
there's
a
lot
more
to
it,
which
will
sort
of
cover,
but
just
in
terms
of
pure
definition,
yeah
get
ops
operation
by
pull
request.
E
Expert
we're
off
to
a
great
start,
so
one
thing
how
many
of
you
are
using
already
some
type
of
configuration
is
code
where
you
might
have
like
some
yeah
moles
somewhere.
Okay,
almost
everyone
great
the
animals
are
amazing.
So
one
of
the
questions
that
we
often
get
asked
is
sort
of.
If
I'm
using
configuration
as
code.
E
Am
I
doing
the
get-ups,
and
the
answer
is
kind
of
like
possibly
actually
but
configuration
is
code
is
just
a
small
part
of
get
ops
if
you're
also
introducing
those
other
changes
to
your
workflow,
such
as
operation
by
pull
requests
that
sort
of
completes
the
circle
for
get
up
so
think
of
configuration
as
code
as
sort
of
part
of
it
and
get
ops
is
more
representative
of
all
of
the
workflows
around
how
you
handle
and
introduce
change
to
your
production
system.
I.
B
D
For
a
long
time,
but
the
operations
is
not
that
clear,
but
what
is
happening
recently
is
that
we've
pushed
all
the
automation
all
the
way
down
to
one
time,
and
so
now
we
write
code
in
one
text
with
real
artifacts,
and
then
we
put
something
in
gate
that
repairs
the
other
parts
like
the
singing
part,
which
is
ends
up
running
in
my
cluster
or
in
my
cloud
right.
That's
helping
to
bring
all
these
things
that
we
know
at
the
auditing
and
knowing
about
it.
What
and
when
and
opening
Alexis
and.
F
D
E
It
sort
of
get
is
become
the
single
source
of
truth
for
your
source
code.
So
why
not
make
it
the
single
source
of
truth
for
everything
that's
running
in
production,
get
as
a
pattern
as
a
tool
is
useful
beyond
just
the
scope
of
source
code
repositories.
So
it's
taking
all
the
amazing
good
stuff
of
why
we
love
get
as
developers
and
allowing
that
to
be
borrowed
begged
borrowed
stolen
across
different
functions.
Our
engineering
team.
F
G
The
role
of
the
modern
Orchestrator
is
very
important
tools
like
kubernetes
terraform,
categorize
jenkins
axis,
in
the
same
bucket,
it's
an
orchestration
tool
which
are
able
to
take
responsibility
from
a
system
owner
and
automate
functionality.
So
that
being
able
to
do
that
and
then
drive
it
through
a
developer.
Workflow,
that's
familiar
is
powerful
for
the
enterprise
also
get
is
audited.
So
you
took
a
lot
of
boxes
if
you're
in
sales
context
as
a
vendor.
C
You
know:
what
do
you
need
to
do
that
and
I
think
it
Ops
becomes
really
fundamental,
especially
when
you're
running
things
in
kubernetes,
and
you
know,
you've
got
all
these
different
clusters
and
you've
got
things
running.
We
don't
know
where
you
know,
how
do
you
fund
them
and
mentally
get
to
that
speed
with
the
quality
and
you
have
to
start
with
get-ups.
D
Yes,
there's
a
part
of
communication
of
to
your
credibility
of
the
applications
that
we
have
to
look
at
as
well.
I
like
the
fact
that
we
can
define
something
engage,
and
we
know
that
that
will
true
that
down
our
our
platform,
our
solution,
that
we
have
a
way
of
a
standardizing
and
making
sure
that
everything
runs
and
does
what
we
supposed
to
do.
I.
We
don't
have
someone
that
magically
does
commands
here
and
there
it
is.
D
G
Think
it's
two
things
one.
It
provides
an
operating
model
so
when
we
go
and
talk
to
customers-
and
they
say,
there's
all
this
new
stuff-
kubernetes
docker
container,
d-link,
addy,
Misti,
Oh
blah
blah
blah
blah.
What
does
it
all
mean
for
me?
How
do
I,
how
do
I
use
this
thing?
Do
I
need
to
change.
My
teams
to
develop
has
continued
to
be
developers.
What
is
this
sre
thing?
I've
heard
people
talking
about?
Is
that
part
of
it
too?
G
And
if
you
break
down
the
world
in
to
build
orchestration,
using
tools
like
Jenkins
or
circle,
see
I
and
then
immutable
up
the
mutable
artifacts
that
can
be
deployed
and
then
autonomic
orchestration
to
manage
deployment
and
runtime
and
monitoring.
Then
you
give
people
a
simple
way
to
think
about
it
all
which
gives
them
roles
that
the
developers
build,
and
they
can
also
take
responsibility
for
operations
by
using
the
observability
tools
that
come
with
these
runtimes.
G
B
E
Definitely
and
I
think
it
ops
and
a
lot
of
the
developer
tools
that
developer
patterns
that
we
use.
Sometimes
it's
easy
to
look
at
them
and
sort
of
think
they're.
A
silver
bullet
that
are
gonna
solve
all
of
your
organisation's
problems,
but
in
reality
those
patterns
still
need
to
be
operated
by
humans.
The
one
thing
I
love
about
git
Ops,
is
that
it
does
feel
perhaps
a
bit
more
democratic
in
a
lot
of
ways,
because
everything
just
is
codified
and
right
there
and
get
for
you.
E
So,
for
example,
if
you
want
to
make
a
change,
you
have
to
have
documentation
for
it.
It's
sort
of
like
a
you
know,
self,
documenting,
workflow
and
I
think
it
helps
teams
work
a
little
bit
more
collaboratively
together,
because
all
of
the
conversations
that
might
have
been
happening
in
different
places
are
now
just
gonna
happen
and
get
because
that
diff
is
there
and
it's
a
central
part
of
the
process.
So
it
does
have
a
really
positive
impact
in
the
way
that
teams
can
work
together.
E
But
I
think
that
maybe
the
word
of
caution
is
that
if
you're
gonna
introduce
a
workflow
or
something
like
get-ups
to
your
team,
you
do
need
to
pay
attention
to
the
human
side
of
it
and
make
sure
that
the
people
who
need
to
work
within
the
system
understand
why
they're
doing
it
and
why
it's
important
to
them.
Otherwise,
it's
gonna
fail
and
that's
not
really
a
get-ups
failure.
That's
kind
of
a
cultural
failure.
D
The
culture
impetus
is
here
just
find
that
the
fact
that
now
we
have
an
audit
log
of
all
the
all
the
actions
in
the
cluster,
so
with
them,
it
happens
something
that
these
are
interesting,
that
we
don't
have
heroes
anymore,
I,
like
we,
we
don't
deploy
and
we
don't
fix
a
system.
We
submit
pull,
requests
and
match
right.
For
how
long
are
we
going
to
be
keep
saying
like
who
can
deploy,
instead
of
who
has
who
has
a
beautiful
request
or
who
can
match?
I
get
this.
This
is
a
shift
culturally
things
change.
D
C
Yeah
people
people
are
hard.
So
if
I
take
an
example
from
like
well
I'll
talk
about
Jenkins
X
and
it
has
these
environments,
you
know,
production,
environment,
staging
environment
and
that's
what
managed
by
get
up
so
everything
you
know
it's
stored
in
git,
but
when
we
talk
to
people
about
it,
they
immediately
will
ask
you
know
like
how
is
the
code
set
up,
how
many
repos
do
you
have
and
and
then
people
really
care?
C
It's
like,
oh
well,
if
you
want
everything
to
be
in
one
repo,
can
we
do
that
and
even
that,
just
something
as
simple
as
that
of
multiple
repos
versus
one
repo?
It's
it's
like
a
big
leap.
It's
like!
If
you
don't
want
to
do
it
the
way
the
tool
is
set
up,
then
you
know
it's
almost
like.
Okay,
we're
not
doing
it
like
that,
because
it
doesn't
work
for
how
I
think
it
should
be
and,
like
you
know,
mono
repos
up
people
are
getting
religious
about
it.
So
you
know
how
do
you?
G
Hell,
yes,
is
the
answer
to
your
question:
Automation
is
probably
the
biggest
cultural
change
caused
by
computers
and
automation
in
delivery
of
technology
is
clearly
very
challenging
to
many
organizations
the
more
regulated
they
are
typically
the
more
gateways
they
have
in
terms
of
say,
the
release
process,
and
so
automation
has
to
be
tempered
by
the
ability
to
stop
it.
Go
manual
will
have
a
gateway
which
includes
somebody
giving
permission,
coaching
people
that
then
they
can
give
permission
through
the
mechanism
of
a
git.
Merge
is
very
interesting
and
challenging
to
people.
G
Who've
never
touched
a
developer
tool
before
also
you
know,
we
have
a
lot
of
customers
who
say
things
like
well.
We've
worked
really
hard
to
separate
development
from
operations,
and
now
we
feel
happy
that
when
we
hand
over
to
operations,
they
can
run
systems
and
fix
things
when
things
go
wrong.
2:00
in
the
morning
and
now
DevOps
is
telling
us
that
actually
developers
get
to
do
this
instead,
which
is
completely
the
opposite
of
everything.
G
We've
been
taught
about
how
to
keep
our
systems
reliable
and
secure,
so
that
is
immensely
challenging
for
people,
but
it's
not
get
ops.
That's
doing
this,
it's
DevOps
and
continuous
delivery
and
continuous
integration
that
have
been
do
for
sometime
it's
just
now.
These
large
organizations
are
adopting
a
technology
kubernetes,
that's
forcing
them
to
face
this
for
the
first
time
and
then
finally,
I
think
that
you
know
fundamentally,
as
Laura
pointed
out,
guid
is
a
collaborative
technology.
G
E
Interesting
thing
that
Ivan
and
I
talked
about
in
the
speaker,
lounge
just
before
this
was
get
ops
as
a
way
to
prevent
heroism,
because
everything
is
just
written
down
and
there's
no
sort
of
like
sneaky
configuration
management
happening.
You
know,
like
it
just
kind
of
prevents
opportunities
for
people
to
make
bad
choices
or
try
to
over
complicate
things,
because
they
want
to
be
perceived
as
a
hero
or
come
in
and
fix
the
day,
and
that
was
sort
of
an
interesting
thing
that
we
hadn't
really
thought
about.
E
G
Remind
me
of
something
else
which
is
related,
but
slightly
different,
which
is
DevOps
and
gear.
Ops
change
how
we
think
about
reliability.
So
when
I,
I'm
just
turn
50
over
the
weekend.
So
I'm
old
enough
to
remember
when
reliable
systems
meant
you
mustn't,
lose
data,
Thank,
You
Tracy,
you
mustn't
lose
data.
E
I
think
it
it
creates
some
kind
of
psychological
safety.
Imagine
what
your
life
would
be
like,
because
I'm
guessing
that
a
lot
of
you
in
the
audience
today
do
not
go
to
work
and
push
something
to
production,
thinking,
man
if
this
goes
wrong,
it's
totally
fine
and
I'm
not
going
to
get
in
trouble
at
all.
That's
you
know
not.
Every
team
has
that
culture,
but
when
things
are
codified
and
you're
using
get-ups
disaster
recovery
becomes
a
much
easier
thing.
E
It's
almost
assumed
that
everything
is
gonna
break
whenever
you
make
a
change,
but
you
have
that
that
way
to
recover
very
quickly.
So
yesterday,
a
funny
thing
happened
during
the
cdf
summit,
where
we
had
a
demo
of
jenkins
acts
and
just
a
little
bit
before
the
demo
was
scheduled
to
go
on
james
dragoon
who's.
One
of
the
engineers
working
on
jenkins
x,
who
I
think
is
in
this
room
somewhere
just
completely
blew
away
the
cluster.
E
So
this
was
just
you
know
just
before
getting
on
stage
in
front
of
a
group
about
this
size.
He
just
like
accidentally
totally
messed
up,
but
it
wasn't
even
an
issue
and
the
demo
went
on
just
fine
because
everything's
in
good-
and
it
was
just
a
matter
of
like
typing
a
couple
commands
and
everything
was
back
up,
so
it
had
like
a
pretty
night.
You
know
negligible
impact
on
the
overall
quality
of
life.
C
D
B
B
G
F
Believe
one
of
them
is
she's,
those
people
are
facing
is
okay.
Putting
everything
and
get
is
fine,
but
how
much
testing
do
I
need
to
be
sure
that
what
I'm
pushing
into
production
will
not
crash
prevention?
We
say
if
we
talked
about
failings
happening,
but
I
went
to
avoid
at
least
partially
the
failures
to
see
them
before,
and
what
what
impact
does
that
happen
to
Linden's
available
needs
to
be
developed.
E
Think
that
yeah,
we
don't
know
I,
think
that's
more
of
a
question
about
like
how
much
testing
is
enough
testing
and
not
really
about
get-ups
right,
but
to
your
point
tests
only
tell
you
when
things
are
definitely
broken.
They
will
never
tell
you
when
things
are
working
as
expected.
So
that's
just
sort
of
the
inherent
gotcha
with
any
kind
of
automated
testing
is
that
you're
you're
gonna
see
when
things
are
broken
sure,
but
they're
certainly
gonna
be
times
when
a
broken
change
can
make
it
through
a
green,
build
and
I.
E
Think
the
point
here
and
kind
of
the
point
about
being
able
to
revert
back
to
the
the
previous
known
good
state
is
that
the
time
that
it
takes
you
to
recover
is
the
key
metric
to
look
for,
in
addition
to
whatever
coverage
level
that
you
need.
So
that's
an
important
metric,
not
just
test
coverage,
because
test
coverage
can
be
a
little
bit
meaningless
depending
on
how
well
the
tests
are
written,
but.
D
There's
something
interesting
in
your
question
when
Gibbs
is
not
about
what
you
do
is
how
you
do
it
I
like
these.
These
things
will
happen
regardless
of
ketones
like
you
and
you
will
push
it
back
or
whatever
I
think
like
littles
gives
you
the
process
that
this
is
tender
and
you
can
actually
what
happens
with
those,
because
you
define
the
whole
process,
you
can
attest
there
easily
and,
and
you
can
have
the
current
e,
that
whatever
you
push,
it
follows
a
cycle.
I
yeah.
G
You
want
to
be
able
to.
We
find
that
we
do,
as
we
said,
opted
get
ups
ourselves
that
we've
worked
so
me
run
over
all
of
our
communities.
First
is
this
way
we
did
more
and
more
testing
in
production
and
we
felt
the
need
for
more
and
more
tools
to
observe
what
is
happening
do
during
and
after
a
deployment,
and
then
we
felt
the
need
for
more
automation
around
setting
up
alerts
so
that
when
the
deployment
has
done
you
can
go
on
to
a
new
task
can
be
alerted
if
something
went
wrong
later.
G
So
you
get
you
get
inevitably
pushed
into
a
world
where
you
have
to
take
observability
more
seriously.
If
you
start
working
in
this
way,
because
you've
got
the
way
that
your
Ops
works
is
by
having
a
desired
state
in
your
config
system
and
your
immutable
repos
and
then
in
the
preserved,
State
and
you're,
constantly
reconciling
the
two
and
provided
the
updates
on
both
can
be
atomic.
If
you
can
have
a
transactional
system,
you
need
to
be
able
to
observe
the
running
system,
to
have
your
other
source
of
truth.
B
G
H
G
C
Recommendation
yeah
I
think
it's
just
kind
of
sometimes
pioneering
things
or
bringing
in
the
tools
we
often
see
internally
with
teams
there's
the
change
happens
because
of
a
champion
of
someone
who's
gone
ahead,
brought
in
these
new
tools
started
using
them
and
other
people
kind
of
gravitate
towards
that
system.
Just
seeing
that
you
know
she
has
the
uptime
here's
how
we
manage
this,
here's,
how
I'm
you
know
not
doing
all
that
fluffy
waste
of
time
stuff
to
kind
of
fix
things
over
and
over
again.
D
Been
doing
it
and
the
answer
is,
it
depends.
So
my
advice
is
that
look
every
every
group
of
people
have
different
interests
and
you
have
to
find
what
is
with
a
one,
and
this
friction
everywhere.
I'll
see
you
with
Gibbs.
What
you
do
is
basically
standardized
a
question
and
and
get
out
of
your
way
and
for
Deb's
is
one
thing
for
operators.
There's
a
different
thing
for
project
managers
is
different
things
as
well.
I
like
do
you
have
to
when
you
pitch
the
tops.
D
You
have
to
know
you
audit
and
you
have
to
say:
okay,
that's
excellent,
I'm,
really
here
you're
a
developer.
You
have
these
problems
with
with
get-ups,
you
solve
it,
and
then
it
allows
you
to
go
faster
right
like
when
we,
when
we
go
and
say
well,
we
have
a
classical
development
and
you
have
the
automation
and
every
dollar
push
that
you
do.
D
So
you
have
all
these
different
different
aspects
that
touches
different
groups
and
the
main
thing
with
etops
is
no
technologies
is
people's
and
process
and
we're
changing
that,
and
that
is
hard
right
and
so
I
don't
have
a
standard
answer
for
your
company
but
yeah.
It's
look,
look
at
your
groups
and
how
you
can
help
them
and
I
mean.
G
If
you,
if
you
won
one
proof,
point
is
onboarding
new
developers.
So
one
of
the
question
comes
to
questions
around
communities
is
what
do
I
have
to
learn
to
use
communities,
it
seems
complicated
and
if
you
can
have
an
app
and
bring
in
complete
new
developers
and
show
them
that
they
can
make
changes
through
exercising
their
will
power
of
the
config
without
necessarily
having
to
learn
the
Cuban
Eddie's
API
in
full.
You
could
get
people
up
to
speed
on
helping
to
move
the
app
forward
very
quickly.
So
that's
a
good
experiment
for
proof
point.
C
A
question
for
the
audience
who
considers
themselves
to
be
doing
get-ups
at
the
moment,
okay
and
who
considers
who
thinks
that
the
organization
should
be
doing
get-ups
and
going
forward
you
like
so
yeah,
so
go
back
to
your
organization,
say
I
went
to
Cuba
on
everyone's
doing
get
ups
and
everyone
should
be
doing
get
ups.
We
should
be
it's
a
bit
yeah.
I
I
G
You
know
we
would,
we
would
normally
do
a
redeployment
on
an
earlier
good
state.
Okay,
but
you
know
there's
things
you
can
get
like
badly
behaved
containers
and
you
can
get
tools
which
kind
of
spot
this
and
root
them
out.
That
would
be
part
of
your
observability
and
validation
step.
There's
lots
you
can
do.
This
is
an
advanced
topic.
We're
interesting
question.
Yeah.
G
B
C
D
What
is
the
impact
of
me
putting
this
file
here
in
gatoring
get
poach
and
then
things
happen
in
finder,
because
that's
that's
the
the
body
of
victims,
it's
not
that
you
to
keeps
it
apply
or
whatever
it
is
about
the
process
and
and
how
it
changes.
How
one
thing
goes
to
get
and
then
all
the
stuff
happens
right
then
you
can
have
a
web
hook
that
goes
and
Jenkins
o-silk
a
CI
and
and
keeps
it'll
apply.
That's
not
the
point.
The
point
is
about
the
process.
D
E
This
actually
works,
and
this
is
what
it
feels
like
as
a
developer
on
this
team
to
work
on
this
application.
So
I
would
recommend
starting
there
so
that
you
can
educate
yourself,
learn
a
bit
more
about
it
and
then
eventually
become
an
advocate
and
champion
for
it.
Within
your
own
organization,
I've
been.
D
Writing
a
tutorial
for
flies
that
basically
have
you
with
mini
cube
to
deploy
applications
like
refine
and
stuff
I
like
you
can
you
can
go
to
make
it
happen
and
run
it
and
file
bugs
because
I'm
sure
that
I
screw
up
something,
but
so
remember
that
that
is
the
process.
The
important
thing
is
not
the
tolling
I
like
the
tallest
is
just
not
important
like,
and
we
cannot
give
you
as
a
standard
answer,
because
it
depends
on
what
you
do
and
how
you
do
it.
That's
exactly
the
problem
you
want
to
tackle.