►
From YouTube: Crossing the Divide: How GitOps Brought AppDev & Platform Teams Together! - Priyanka "Pinky" Ravi
Description
Crossing the Divide: How GitOps Brought AppDev & Platform Teams Together! - Priyanka "Pinky" Ravi, Weaveworks
Priyanka, now at Weaveworks, and Russ, her former colleague at State Farm will share their varied experiences of application change management and how they updated their process to follow the GitOps methodology. Together, they will emphasize the benefits of adopting GitOps by commiserating on the elaborate difficulties and contorted solutions of earlier alternative deployment strategies. Priyanka and Russ come from different sides of the Application / Platform development team divide, and each bring their own historical context and separate understanding of how a deployment system should function! Be prepared to hear horror stories and tales about those systems that should never be told, about the worst solutions that should never have been built, and problems that should never have needed to be solved - and what it looks like on the other side.
A
Okay,
so
yeah
as
scott
mentioned.
This
is
what
we're
talking
about.
I
am
priyanka
ravi.
I
also
go
by
pinky
and
I
am
a
developer
experience
engineer
at
weaveworks.
Those
are
my
puppies
just
any
chance
to
get
show
them
off
and
then
okay,
so
I'm
gonna
basically
be
treating
this
as
kind
of
like
a
little
story.
A
Time
session,
I'm
gonna
be
sharing
some
user
experiences,
mine
included,
and
so
I've
interviewed
a
few
people,
some
that
are
actually
speaking
here
today,
which
is
kind
of
cool,
and
I'm
gonna
share
those
with
you
as
well.
So
first
up,
it
is
my
story,
so
I
actually
only
recently
joined
weaveworks,
maybe
like
five
months
ago,
and
before
that
I
was
actually
working
at
a
large
insurance
company
in
the
u.s
called
state
farm
and
at
state
farm.
A
I
actually
was
part
of
a
small
team
that
was
called
the
delivery
engineering
team
where
we
implemented
git
ops
from
scratch.
So
we
it
all
started
a
long
time
ago,
when
I
first
joined
state
farm,
the
way
that
code
went
into
production
was
very
tedious
and
time
consuming.
You
had
to
go
to
a
vendor
tool
and
submit
a
request,
and
then
your
manager
would
go
and
approve
it,
and
then
there
would
be
like
a
change
window
and
if
you
were
lucky
it
would
take
days
to
get
into
production,
but
more
likely
it
might
take.
A
You
know
a
week
or
maybe
even
a
couple
weeks,
so
definitely
not
an
ideal
solution.
I'm
sure
there
had
like
that
that
story's
not
like
alien
to
some
people,
I'm
sure
other
people
have
been
in
that
situation,
but
eventually
there
was
another
option
introduced
at
the
company
that
we
called
the
automated
software
change
option.
I
think
it
was
using
like
urban
code
and
that
reduced
the
time
two
hours,
which
was
great
at
the
time,
but
you
know-
oh,
I'm
still
wearing
my
mask.
A
Sorry,
that's
probably
way
better
okay,
so
that
made
it
a
lot.
It
was
that
made
it
a
lot.
Obviously
a
lot
quicker
to
get
to
production,
but
we
could
do
better,
and
then
we
had
a
developer.
Who
was
actually
on
my
team
at
the
time
go
to
kubecon
and
he
came
back
talking
about
this
thing
called
get
ups,
and
this
was
like
a
few
years
ago
and
he
was
like
wow.
This
thing
sounds
so
cool
and
you
know
we're
already
using.
A
We
were
using
gitlab
at
the
time
and
we
might
as
well
just
take
advantage
of
that
to
meet
our
compliance
standards
and
you
know,
make
the
developers
lives
easier
and
it's
fast.
So
we
ended
up
forming
this
small
team
of
at
the
time,
just
three
people
and
we
you
know
we
faced
a
lot
of
pushback
at
first.
There
were
people
in
the
change
management
space
right,
because
an
insurance
company
there's
a
lot
of
auditing
and
they
also
had
a
bank.
So
there's
a
lot
of
financial
stuff
as
well,
and
they
they
said.
A
Oh,
my
goodness,
you
have
to
meet
so
many
compliance
requirements
and
we
can't
actually
go
this
route
until
you
meet
all
of
these
these
requirements,
and
so
we
created
a
lot
of
tools
internally,
such
as
like
cli,
to
get
things
into
the
config
repo,
and
then
we
also
use
terraform
to
create
those
config
repos
and
keep
them
locked
down.
So
managers
could
approve
in
there
and
that
whole
process
was
a
lot
of
work
to
meet
those
requirements,
but
eventually
we
did.
Then
we
heard
from
managers.
A
Well,
we
don't
actually
want
to
have
to
log
into
gitlab,
because
we've
never
had
to
do
that
before
to
look
at
code
and
now
you're
telling
us
we
have
to
go,
approve,
merge
requests,
and
so
that
was
the
next
step.
And
but
the
thing
that
really
kept
us
going
is
that,
on
the
other
hand,
we
heard
from
developers,
if
you
can
make
this
work,
then
you'd
be
our
heroes,
because
this
would
simplify
our
lives.
We
don't
have
to
go
to
a
separate
tool
to
get
approval
and
all
that
stuff
right.
A
It's
all
just
in
what
they're
used
to
so
that
kept
us
going
and
eventually
we
did
get
it
set
up.
Actually,
the
first
platform
we
we
were
trying
to
get
it
set
up
for
was
aws,
not
kubernetes
actually,
and
so
we
we
set
up
all
these
tools
and
everything,
and
then
kubernetes
was
the
next
beast
that
we
tackled.
A
It
was
very
exciting
because
we
actually
that
that
was
my
first
introduction
to
flux,
but
the
challenge
there
was
a
new
one
where
at
state
farm
kubernetes
had
already
been
in
production
for
a
couple
years.
There
was
a
team
that
was
the
dedicated
kubernetes
platform
team
and
they
had
been
doing
this
for
a
while
right.
So
we're
trying
to
come
in
and
be
like.
Oh,
let's
change
entirely
how
you're
doing
what
you're
doing
we're
gonna
change
the
way
that
namespaces
get
created,
we're
going
to
change
the
way
that
users
get
onboarded.
A
I
mean.
That's,
that's
not
going
to
be
an
easy
conversation
right,
they're
not
going
to
happily
be
like.
Yes,
please
change
our
process,
so
we
had
to
do
a
lot
of
work
with
them.
We
did
a
lot
of
proof
of
concepts
to
show
them
that
it
wasn't
so
bad
and
that,
like
you
know
this
is
a
very
simple
thing
to
do
and
at
the
same
time
there
was
already
a
ui
in
place
to
get
new
people
onboarded.
A
That
was
the
way
that
they
had
been
doing
it
and
then
it
would
call
off
to
the
api
and
do
all
these
other
things
right.
So
we
just
used
the
same
ui.
To
then
create
like
it
was
a
pipeline
to
create
the
yamls
for
the
flux
multi-tenancy
repo,
to
create
those
new
name
spaces,
so
that
flux
could
then
pick
it
up
and
just
create
those
name
namespaces,
and
that
at
least
made
them
feel
a
lot
better.
A
Because
then
the
the
users
that
have
already
been
using
that
whole
way
of
getting
onboarded
onto
kubernetes
at
the
company
didn't
feel
any
difference
right.
They
don't
care
how
it
gets
created
as
long
as
it's
the
same
experience
and
it
does
get
created
so
that
also
helped
bridge
that
gap
with
them
and
eventually
they
actually
were
really
excited
about
it
and
they
took
ownership
of
it
too.
A
So
that
was
like
a
great
accomplishment
for
us
as
well,
and
I
I
want
to
add
too
that
well,
I
don't
know
what's
happening
at
the
bottom,
but
I
want
to
add
to
that.
We
would
never
have
been
able
to
do
it
as
quickly
as
we
did.
We
got
it
up
and
running
within.
We
got
get
ups
going
within
a
year.
It
wouldn't
have
happened
if
we
didn't
have
leadership
buy-in.
I
think
leadership.
A
Buy-In
is
a
huge
thing,
like
it's
a
great
asset
to
have
if
you
can
get
it
because
if
the
leaderships
are
telling,
if
the
leaders
are
telling
you
know,
teams
that
hey
this
is
the
direction
we're
going
in
things
are
so
much
smoother.
Otherwise
it's
a
lot
harder
to
get
different
teams
to
buy
into
this
aspect
as
well
to
make
a
change
because
they're
like
it's
already
working.
Why
would
I
want
to
even
do
that?
So
that
was
my
experience.
A
The
next
one
I
want
to
talk
about
is
actually
kind
of
funny,
because,
if
you're
at
my
talk,
you're
actually
missing
her
talk,
and
so
this
is
actually
app
flyers,
their
their
their
experience.
And
so,
if
you
like,
since
you're
here,
I
really
encourage
you
all
to
go
check
out.
I
let's
talk
on
online
later.
A
A
A
So
basically,
what
they
did
is
they
created
a
cross-platform
team
because
they
had
seven
platform
teams
in
in
their
platform
group
and
they
had
representatives
from
each
of
them
and
they
they
actually
use
flux
in
the
base,
and
then
they
added
a
bunch
of
common
like
additional
custom
tooling
on
top
as
well
like,
I
said,
I
really
recommend
you
check
out
her
talk
to
to
find
out
more
about
how
they
actually
did
it.
But
their
initial
reaction
to
get
ops
was
not
the
same.
Experience
that
I
had
theirs
was
not
fireworks.
A
It
was
actually
the
developers
were
not
excited
about
it
at
all.
They
were
actually
very
apprehensive
of
of
it
because
they
didn't
like
the
fact
that
their
environment
was
changing
and
the
way
that
things
had
to
go
were
you
know
different
suddenly,
so
they
actually
solved
that
by
using
different
representatives
from
each
of
the
r
d
teams
and
and
basically
created
like
this
champions
group,
and
then
they
were
able
to
then
go
back
and
take
that
back
to
their
teams
as
well
as
well
as
they
actually
had
leadership
buy-in
as
well.
A
So
their
cto
actually
did
a
talk,
and
everything
about
you
know
like
get
ups
being
the
way
to
go,
so
that
also
helped
make
people
realize
like
yes,
this
is
the
direction
we
should
go
and
they
felt
better
about
it
if
they
heard
their
leaders
saying
it
right
so
and
for
them
building
out
their
good
op
solution
actually
brought
on
amazing
results.
It
reduced
all
their
developer,
pain
points
and
it
increased
the
number
of
development
developments
per
minute
for
them
as
well.
A
So
that's
very
exciting,
okay,
so
another
one
I
want
to
talk
to
talk
about
is
so
this.
This
user
is
someone
I
interviewed
that
actually
works
for
a
sas
company.
So,
interestingly,
when
I
was
talking
to
them,
I
got
their
company
perspective
as
well,
but,
like
I
also
got
to
hear
some
some
of
the
stories
that
they've
seen
other
people
have
as
well,
so
for
them
they
have
a
bunch
of
microservices
and
they
were
actually
using
azure.
So
they
didn't
even
have
get
ups
like
in
place
at
all
and
not
kubernetes.
A
So
there
they
created
a
team,
a
dedicated
team
to
start
kubernetes,
but
they
had
the
opportunity
to
actually
create
git
ops
alongside
kubernetes
and
they're.
Actually,
their
end
goal
is
to
actually
have
everyone
on
kubernetes
using
git
ops
as
well,
and
they
so
they
actually
said
that
they
like
flux,
because
it's
a
set
and
forget
type
thing.
A
Basically,
this
one
was
so
they
were
using
imp
terraform
to
set
up
their
infrastructure,
which
is
not
uncommon
right
where
it
gets
really
crazy
is
that
they
were
using
terraform,
basically
to
what
it
was
doing.
It
was
creating
sorry.
I
have
to
read
this
because
it's
it's
like
not
something
I
could
even
memorize,
because
I
can't
write
my
brain
around
it.
A
It
was
insane
it's
a
crazy
process.
I'd
never
heard
of
anything
like
that,
but
I've
heard
of
some
some
other,
like
you
know,
situations
similar
so
getting
something
like
that
into
production,
literally
even
a
simple
website.
Ui
took
them
an
hour
after
they
told
me
about
that.
Their
next
words
were
literally.
If
they
had
been
using
git
ops.
A
They
were
very
new
to
kubernetes,
but
they
pointed
out
that
even
they
were
able
to
get
like
wrap
their
heads
around
the
concept
of
git
ups
really
easily,
which
was
pretty
exciting
to
hear,
because
you
know
it
makes
me
happy
that
it's
not
so
convoluted
that
people
can
just
understand
it,
even
if
they
have
a
basic
understanding
of
kubernetes,
so
anyone
can
really
do
it
and
yeah.
So
I
last
thing
I
want
to
end
on
here
in
the
on
for
this
user
story:
is
they
they
actually
had
a
really
good
point?
A
They
they
brought
up.
I
think
that
what
they
said
is
they
they
keep
hearing
this
misconception,
and
I've
heard
it
too
is
basically
getups
is
just
the
deployment
part
of
it.
It's
not
the
whole
ci
process,
so
all
those
tests
and
scans
and
everything,
sometimes
people
think
that
that
they
get
a
little
confused
of
like
what
does
flux
do
or
what
does
like
any
of
these
get
ops
tools
do,
and
so
by
that
point
by
the
time
flux
comes
along
the
test
scans.
A
B
B
So
sorry
to
to
you
all,
but
previously
I
was
working
at
virginia
tech
and
at
virginia
tech
we
were
building
a
a
platform.
Just
like
this.
The
many
of
the
stories
that
you've
just
shared
with
us
and
get
up
was
a
good
separation
point
between
the
platform
teams
and
the
application
developers
and
there's
kind
of
two
things
I
want
to
bring
up
that
github's
helped
solve
for
us.
B
When
we
first
got
started,
we
we
recognized
that
there
was
a
missing
piece
of
how
do
we
provide
kind
of
a
web
interface
kind
of
thing,
because
mostly
the
dashboards
out
there,
if
anybody's
ever
run
a
kubernetes
dashboard?
Good
luck,
trying
to
present
that
to
the
lay
person
and-
and
so
we
we
built
our
own
dashboard-
that
took
a
lot
of
the
the
different
components
and
kind
of
one
person
presented
in
a
read-only
manner,
as
git
ops
would
support.
B
But
one
of
the
things
that
we
did
with
that
dashboard
was
that
we
would
highlight
specific
problems
or
things
that
were
going
on.
So
then,
it
would
kind
of
help
nudge,
the
application
developers
along
and
one
of
one
of
the
really
neat
things
that
happened
out
of
that
was,
since
all
their
the
the
teams
are
using
git
to
kind
of
version
control
their
their
deployments.
B
So
many
ways
as
a
platform
engineer
using
get
ops,
helped
us
kind
of
see
where
the
common
stumbling
blocks
for
our
our
developers
were
and
and
how
can
we
help
them
out?
Another
aspect
that
we
were
pretty
interested
in
too
is
going
to
application,
developer
teams
and
simply
saying
hey:
here's
a
platform.
Congratulations!
B
Now
you
have
to
learn
how
to
write
all
this
kubernetes
stuff,
good
luck,
and
so
we
had
a
lot
of
developers
come
back
and
like
okay,
I'm
writing
a
service.
What
the
heck
is
a
selector
and
what
are
these
labels
and
what
all
and
all
this
stuff-
and
it
was
just
so
complicated,
so
we
did,
we
did
a
lot
of
experimenting
internally.
B
If
can
we
use
the
the
compose
spec?
You
know.
A
lot
of
the
teams
are
already
using
docker
compose
for
development.
Can
we
use
that
same
specification,
add
some
extension
fields
and
say:
okay
for
a
port,
here's
an
x-host
field
and
we
can
convert
that
and
and
use
something
that
they're
already
familiar
with
and
convert
that
into
the
manifest
that
they
could
be
deployed
on
the
cluster,
and
we
had
some
pretty
good
success
with
that.
B
I'd
love
to
still
do
some
experimenting
with
that,
but
I
think
there's
some
work
as
a
community
that
we
can
do
to
kind
of
raise
that
abstraction
level
for
the
developer
teams,
but
I
think
git,
ops
and
this
kind
of
this
boundary
layer
between
the
platform
teams
and
the
development
teams.
It's
right
for
a
lot
of
really
cool
work
and
development
there
as
well.
So
did
you
see
your
name?
Oh
yeah,
I
didn't
even
say
my
name
pinky's.
B
A
So
one
thing
that
I
really
like
about
michael's
story
too
that's
different
than
mine
is
that
they
got
to
stand
up
kubernetes
and
get
ups
at
the
same
time.
So
it
was
like
the
same
team
that
managed
both,
and
so
the
cool
thing
is
like
if
you
haven't
already
stood
up,
kubernetes
and
you're
here
to
get
started
with
both
it's
it's
a
great
opportunity
to
get
started
with
both
you
don't
have
to,
like
you
know,
retroactively
fit
get-ups
into
like
your
existing
kubernetes
structure,
which
is
cool.
A
If
you
have
that
opportunity,
if
you
don't,
I
mean
it
still
works
right,
I'm
here
to
like
I'm
here
as
proof
that
that
still
is
possible
but
yeah.
So
that's
that's
kind
of
what
we
want
to
say
too
is
like
you
really
can
do
this,
it's
it
like.
We've
both
implemented
ourselves
and
no
matter
how
crazy
your
situation
seems.
I
mean
there's
a
lot
of
really
crazy
situations
out
there.
I
think
we've
both
heard
stories
that
are
insane
in
our
time
working
with
flux,
but
it's
totally
doable
you
can.
A
You
can
definitely
make
it
work
and,
as
I
mentioned
before,
if
you
do
get
leadership
by
and
it
makes
it
so
much
easier
and
then
another
thing
that
I
forgot
to
mention
with
my
experiences
I
is,
is
like
doing
a
lot
of
talks
to
actually
help
developers
get
started
with
it.
I
think
that
really
helps.
I
did
a
lot
of
talks
when
I
was
at
state
farm
to
actually
promote
it
and
then
make
people
feel
a
little
more
comfortable
with
it.