►
From YouTube: GitOps Driven Deployments on OpenShift - Everett Toews (Deloitte) - OpenShift Commons Briefing
Description
GitOps Driven Deployments on OpenShift - Everett Toews (Deloitte)
The industry is determined to deliver value ever more rapidly, safely, and securely across software development lifecycle environments. One way to achieve this is through GitOps.
In broad terms, GitOps is about applying the Git workflow to operations. I took this idea and narrowed it down to exactly one use case, using Git to drive deployments on OpenShift. In this presentation I’ll walk-through all of the components used to enable GitOps driven deployments all the way from development to production for a real-world enterprise client.
About the speaker:
Everett Toews (Senior Specialist Lead Platform Engineer at Deloitte New Zealand) is working to improve the developer experience of building cloud native applications through a combination of development, operations, testing, documentation, and continuous integration/deployment. He’s interested in composing distributed systems using APIs, SDKs, CLIs, containers, and cloud. He likes to teach what he learns along the way.
A
A
B
Yeah
thanks
a
lot
Diane
appreciate
that-
and
it's
it's
great
to
be
speaking
here
on
open
ship,
so
I
wanted
to
give
everyone.
You
know,
walk
everyone
through
some
some
ideas
and
concepts
around
get-ups
driven
deployments
on
open
shift,
and
as
Diane
mentioned,
this
is
kind
of
the
culmination
of
years
about
a
year's
worth
of
work.
A
little
more
actually
at
a
client
I
have
here
working
with
Deloitte
digital
in
in
New
Zealand.
B
So
just
a
quick
intro
of
myself,
my
name
is
Everett
Caves
I
know,
tabes,
looks
nothing
like
it
sounds:
it's
okay,
I
get
it
all
the
time
I'm
eat,
Abe's
on
github,
Twitter,
Linkedin
and
and
my
blog,
where
I
actually
have
a
kind
of
a
summary
of
this
presentation
as
well.
You
can
reach
out
to
me
on
any
of
those
if
you
like,
I'm
a
platform
engineer
with
Deloitte.
B
but
I'm
actually
Canadian
coming
from
Canada.
So
let's
get
right
into
it,
get
ops.
So
what
what
is
get
ops
if,
if
you're
unfamiliar
with
the
term,
really
broadly
speaking,
it's
like
all
about
applying
the
git
workflow
to
operations.
You
know
that
is
the
the
essentially
the
maintenance
of
of
applications.
You
know
running
on
machines
somewhere,
you
know
and
all
throughout
my
career
and
and
I
would
imagine
likely
yours
too.
You
know
we
just
keep
putting
more
and
more
things
in
source
control
and
now
git
is
kind
of
the
dominant
stores,
control.
B
B
That's
that's
part
of
the
developer
experience
too
very
much
so,
and
so
we
can
apply
that
to
operations
as
well,
and
so
I
took
this.
This
one
use
case
of
applying
that
to
deployment
at
a
client.
So,
let's
start
at
the
end,
I
want
to
give
you
an
idea
of
exactly
what
this
means
and
how
it
all
works,
and
it's
probably
not
gonna,
make
a
whole
lot
of
sense.
B
Honestly,
when
you
first
see
it,
but
then
I'm
gonna
go
and
explain
every
every
piece,
every
concept
and
and
that
the
the
real
end
hopefully
will
have
a
better
idea
of
how
it
all
fits
together.
So
here's
the
flow
of
how
this
actually
work,
how
a
deployment
actually
works
via
get
ops
on
an
open
shift,
though
someone
proposes
a
new
version
of
the
application,
the
pull
request
when
that
pull
request
gets
merged,
webhook
fires
and
the
new
version
is
rolled
out
to
an
environment.
B
Simple
is
that,
of
course,
you
know
nothing's
ever
simple
and
putting
this
stuff
together.
You
know
it
took
some
time,
and
certainly
not
just
the
the
technology
but
working
with
all
the
the
various
stakeholders
and,
throughout
the
whole
software
development
lifecycle.
You
know
that
took
is
as
much
time
as
anything.
So
here
it
is.
B
So
right
now
we're
just
looking
at
a
variety
of
pipelines,
there's
actually
a
couple
different
types
of
pipeline
here
that
I'll
get
into
environment
and
service
pipelines
and
now
we're
in
get
and
we're
looking
at
the
the
git
repositories
that
contain
the
the
configuration
and
versions
or
an
actual
environment.
That's
that's!
What's
in
those
properties,
files
and
here's
the
the
pull
request,
I
mentioned,
you
know
it's
kind
of
the
the
first
step
of
the
flow
and
it's
really
just
a
test:
pull
request
to
fire
off
the
web
hook.
B
This
first
one
called
the
deployed
entity
server
and
it
goes,
and
it
does
a
few
steps.
You
know
the
identity.
Server
is
one
of
the
the
services
in
this
application
stack
and
then
it
goes
ahead
and
verifies
that
that
the
identity
server
has
been
deployed
and
initiate
the
next
pipeline.
You
know
in
the
process
and
again
at
a
very
similar
set
of
steps,
and
it
rolls
out
and
gets
verified
once
again
and
there's
there's
some
optimizations
in
the
pipeline's,
which
is
why
this
is
all
happening
so
quickly.
B
This
is
all
real-time
at
the
moment,
and
all
of
this
stuff
has
already
been
built.
So
there's
no
actual
container
image
builds
and
the
optimizations,
just
kind
of
you
know,
skip
a
bunch
of
steps
if
they
aren't
really
necessary.
Deploying
the
UI
involves
a
linting
step,
though
there's
a
time
lapse
here,
not
too
so
as
to
not
bore
everybody
with
limping
and
then,
but
again,
a
very
similar
set
of
steps
for
the
user
interface
portion
of
this
stack.
B
B
Fifth,
okay,
so
you
know
that
kind
of
went
through
that
at
at
breakneck
speed,
let's
zoom
out
a
bit
and
kind
of
you
know
then
start
zooming
back
into
the
the
various
different
areas,
starting
with
the
stack
that
we
rolled
out
there
that
we
deployed
there
so
actually
something
that
that
wasn't
part
of
that
stack,
necessarily
that
we
saw
in
the
video
is
an
API
gateway
and
that's
actually
running
on
the
Azure
cloud.
Microsoft's
Azure
cloud
I'm.
So
we're
using
that
to
front
the
API
for
this.
B
The
API
itself
is
very
much
running
on
Prem
on
OpenShift
there's,
an
identity,
server
portion
service
which
does
authentication
again
running
on
on
Prem,
open
ship
and
then
underlying
the
whole
thing
is
this:
this
great
big
monolithic
database
and
that's
actually
part
of
that-
was
a
pre-existing
database
running
on
on
a
separate
set
of
hardware
and
that's
not
on
open
ship.
So
here's
kind
of
a
very
basic
diagram
of
what's
going
on
there.
You
know
you,
a
user
comes
in
via
their
web
browser.
B
They,
you
know,
hit
a
URL
to
load
up
the
UI
that
that
user
interface
is
downloaded
from
a
web
server
which
contains
all
the
UI
code.
It's
a
single
page
application
written
in
angular,
using
typescript
or
I,
should
say
written
in
typescript
using
angular,
and
then
it
does
some
authentication
via
the
identity
server
which
reaches
into
the
database.
To
get
to.
B
You
know
to
actually
do
the
authentication
and
then,
after
that,
it's
that
that
single
page
application
making
API
calls
through
the
azure
API
gateway
to
our
API
code
and
again,
of
course,
that's
that's
hitting
the
monolithic
database.
So
all
told
honestly,
it's
you
know
relatively
conceptually.
Certainly
a
simple
application
stack.
B
So,
let's,
let's
talk
about
that
that
flow
in
a
little
more
detail.
You
know,
of
course
you
always
have
you
or
your
users.
In
our
case,
for
for
deployments,
our
users
are
internal
right.
We
have
these
environment
owners
who
work
through,
get
to
actually
take
those
to
it.
You
know,
initiate
the
pull
requests
and
to
accept
and
merge
the
the
Powter
question.
B
I
should
say,
approve
and
and
merge
the
the
pull
requests
which
of
course,
fires
off
the
pipeline's
that
we
saw
running
in
the
video
and
then
everything
is
deployed
out
to
an
environment
which
is
actually
just
an
open
ship
project.
You
know
if
you're
kind
of
intimately
familiar
with
OpenShift,
which
I
imagine
you
are
since
you're
watching
this
video.
Ok,
so
that's
that's
a
little
deeper
into
the
flow.
B
Let's,
let's
start
touching
on
each
of
those
particular
components,
and-
and
this
is
the
the
whole
thing
and
to
end
what
we
watched
in
the
video
and
again,
it's
far
too
complicated-
to
explain
in
one
go
so
we'll
carve
it
up
and
explain
a
bit
at
a
time
starting
with
git.
So
this
is,
you
know,
I'm
just
gonna
go
ahead
and
assume
you
know
what
get
is
you
know
if
you're
you're
interested
enough
to
be?
Actually,
you
know
taking
your
time
to
watch
this
person
presentation.
B
You
probably
got
a
good
good
to
hold
on
what
git
is
it's
it's
a
source,
control
system?
Okay,
so
the
user
interacts
with
get
to.
You
know
merge
that
that
pull
request
which
kicks
off
a
pipeline,
which
you
know,
fires
the
web
hook
and
that
kicks
off
a
pipeline.
They
can
in
fact
users
can
in
fact
go
ahead
and
start
the
pipeline
manually
and
I'm.
B
You
know
they
can
if
they
have
the
right
permissions
in
OpenShift,
they
can
go
to
that
pipeline
screen
and
click
the
start
pipeline
button
and
kick
things
off,
and
you
know
all
throughout
all
of
these
pipelines.
You
know
it's
that
the
pipelines
are
regularly
interacting
with
get
pulling
in
config
or
pulling
in
source
code
or
pulling
in
different
artifacts
like
deployment
configurations
or
config
Maps
things
of
that
nature,
but
for
the
purposes
of
users,
interacting
with
it,
you
know
they're
they're,
very
much
interacting
with
the
get
user
interface
which
in
our
case
is
is
bitbucket.
B
So
you
know
there's.
It
provides
a
lot
of
great
features
that
you
know
we
probably
all
kind
of
take
for
granted
and
have
all
kind
of
faded
into
the
background
for
us,
but
are
super
useful
in
for
for
this
sort
of
work.
Actually,
you
know
because
they
they
provide
all
this
great
access,
control
and
auditability
out
of
the
box,
and
you
know
this
is
the
sort
of
thing
that
you
know.
A
lot
of
organizations
aren't
even
used
to
having
it.
B
B
You
know
you
want
to
make
sure
you've
got
your
your
permission,
set
properly
branch
permissions
that
properly
your
pull
request
and
reviewers
set
on
your
environment
report
properly
and
and
the
web
hooks
as
well,
which
actually
fire
off
and
initiate
the
pipeline
run
and
then
for
the
the
what
I
term
the
the
service
repos
tags
are
kind
of
the
the
important
bit.
So
these
are
all
the
aspects
of
yet
that
that
I
rely
on
to
bring
the
system
together
and
I'll.
B
Explain
you
know
kind
of
what
environment
repos
are
and
service
repos
are
in
just
a
bit
here,
so
the
environment
repos.
These
are
all
of
the
the
various
software
development
lifecycle
environments.
That
are
you
know
in
to
this
particular
client,
for
this
particular
application-
and
you
know,
there's
a
naming
convention
here
that
I'll
explain
in
a
bit
but
they're
your
basic
stuff,
your
your
development
environments,
your
test
environments,
there's
even
a
demo
environment
and
some
lab
stuff,
pre,
prod
prod
and
all
of
these
things
describe
the
various
environments
and
the
sandbox
ones
there.
B
Those
are
actually
for
the
the
operation,
people
ourselves
where
we
can
go
and
basically
break
things
without
breaking
everybody
else.
That's
that's
the
purpose
of
those
ones.
So
if
we
take
a
look
into
one
of
these
environments,
in
this
case,
debo
three-master,
we
just
see
just
two
two
files.
That's
it
relatively
simple.
The
the
service
dog
properties
contains
the
the
configuration
that
you
know
that
goes
into
the
applications
themselves.
B
You
know
the
these
are
c-sharp
applications
and
are
configured
with
some
some
JSON
files
and
those
basically
act
as
parameters
into
those
configuration
files,
the
the
contents
of
service
da
properties
and
then
version
dot
properties.
Those
are
the
versions
of
the
various
services
that
are
being
deployed.
So,
in
our
case,
there's
only
three
entries
in
that
file.
One
for
the
UI
one
for
the
identity,
server
and
one
for
the
API,
and
they
just
specify
a
assembler
style
version
that
that
tells
the
system
what
to
deploy
what
version
of
that
service
to
deploy.
B
B
You
want
to
give
right
access
to
those
who
can
update
the
environment,
the
people
who
are
proposing
the
pull
request.
You
know
I
want
a
new
version
of
the
API
and
test.
Oh
seven
and
they'll
propose
that
pull
request
and
in
the
end
owner.
Well,
you
know
either
approve
it
or
reject
it
and
merge
the
ploy
request
or
not,
and
then
you
know
you
can
set
up
group
access
as
well.
B
If
you
want
you
know,
maybe
you
want
everybody
to
be
able
to
read
the
service
dot
properties,
so
they
can
understand
what
you
know
what
the
services
are
pointed
to
a
database.
For
instance,
the
the
services
are
pointed
to
in
a
particular
environment
branch
permissions
I'll
just
run
through
some
of
this
stuff
pretty
quickly
because
it's
you
know
pretty
basic
stuff
for
for
managing
it.
So
you
want
to
set
up
semester
branch
permissions
around
preventing
a
bunch
of
bad
things
from
happening
and
certainly
changes
without
a
full
request
for
pull,
requests
and
and
default.
Reviewers.
B
You
know
you
configure
these
and
get
as
well.
You've
got
a
URL
which
I'll
show
you
where
you
get
that
URL
for
the
web
hook
in
an
open,
shipped
active
of
course,
and
then,
when
you
want,
when,
when
do
you
actually
want
the
web
hook
to
fire?
In
our
case,
it's
it's
simply
when
the
pull
request
is
merged.
B
When
the
admin
when
the
environment
owner
has
approved
it
and
actually
merged
it,
then
the
the
web
hook
will
fire
and
that
will
initiate
the
the
pipe
run
and
you
can
find
that
webhook
within
OpenShift
in
the
actual
pipeline
configuration.
So,
for
instance,
this
is
the
the
debo
3
master
deployment
pipeline,
and
you
just
go
into
the
configuration
and,
in
our
case,
we're
using
bitbucket.
So
we
grab
the
bit
bucket
web
hook.
But
of
course
this
this
works
with.
You
know
many
systems,
and
you
can
always
use
the
the
generic
web
book
URL
as
well.
B
If
it
you
know,
if
your
particular
get
system
isn't
necessarily
specifically
supported,
okay,
so
that
was
the
the
environment
repos,
the
repos
that
contain
all
our
environment,
configuration
and
and
the
versions
of
the
applications,
the
versions
of
the
services
that
are
running
in
the
environment.
So
now
we've
got
the
the
service
repositories,
the
service
repos.
These
contain
the
application
code
that
the
service
code-
and
in
this
case
you
know
in
this
particular
above
bit
like
a
project.
B
It's
got
two
of
them
and
paste
services,
which
is
the
the
API
and
the
identity
server,
which
is
that
that
authentication
service,
the
the
UI
is
actually
in
a
different
project.
So
it's
not
not
pictured
here,
and
these
are
just
your
basic
source
code,
repo
there's,
you
know
really
nothing
special
about
it
in
particular,
and
and
these
happen
to
be
c-sharp
applications,
you
know
and
and
the
the.net
world.
You
know
this
is
all
running
on.
B
B
B
Okay,
so
the
the
service
repo
is
kind
of
the
key
bit
in
in
the
service.
Repos
are
the
tags.
So
when
we
want
to
deploy
a
particular
version
of
a
service,
we
go
ahead
and
we
take
it
in
the
master
branch
in
bitbucket
here.
So
you
know-
and
we
typically
do
this
through
the
UI,
but
you
can
do
it
through
the
the
command
line
interface
as
well.
I
get
CLI
as
well
go
in
and
we
tag
a
version.
We
specify
it
in
that
versions.
B
The
other
end
is
deployments
and
image
container
images
right
and
the
deployments
running
based
on
those
container
images,
so
for
kind
of
day-to-day
work,
I
like
to
you
know,
focus
or
or
or
or
try
to
get
across
the
fact
that
you
know
these.
This
is
basically
your
interface
to
the
platform
in
some
sense,
so
you
know
just
as
we
had
environment
repos,
we
have
environment
pipelines
and
they've
got
this
naming
convention
and
it's
all
kind
of
about
the
database.
The
devil
3
is,
is
the
database.
B
So
that's
what
we
focus
on
and
master
is
the
the
branch
we're
working
from
in
this
particular
case.
There
are
all
those
individual,
git
repos
which
have
the
the
versions
in
the
configuration.
That's
that
versions,
dot
properties
and
then
service
dog
properties,
I
showed
you
and
the
environment
pipelines
invoke
the
the
service
pipelines
so
they're.
You
know
that
kind
of
sub
pipelines
that
actually
deploy
the
various
services
and,
after
its
invoked
those
service
pipelines.
It
goes
ahead
and
it
verifies
the
deployments
that
the
service
pipelines
made.
B
So
that's
the
in
in
this
particular
case.
It
just
happens
to
sort
to
the
top
just
based
on
its
name
and
it.
You
know
it
invokes
the
pipelines
below
it,
and
you
know
from
the
diagram,
that's
the
little
kind
of
the
leftmost
pipeline
and,
as
you
can
see,
it
invokes
the
pipelines
to
the
right
and
then
does
a
verification
step.
B
Okay,
so
the
the
service
pipelines,
those
pipelines.
You
know
a
little
further
to
the
right
that
are
invoked
by
the
environment
pipeline
again,
following
a
naming
convention
of
deploy
the
service,
this
example
the
the
user
interface
and
then
there's
one
for
the
identity,
server
and
one
for
the
API
as
well-
and
you
know
these
are
the
the
git
repos
that
that
I
showed
you
for
the
the
service
repos.
It's
got
the
source
code.
B
Now
these
pipelines
invoke
builds
and
deployments,
so
they
are
actually
responsible
for
you
know
running
the
the
builds
that
create
the
container
images,
the
immutable
container
images
or
you
know,
for
the
the
deployments
for
the
pods
to
actually
run
and
what's
what's
essentially
happening
happening
here.
When
those
deployments
happen,
you
know
it's
it's
a
little
bit
a
little
more
complicated
than
this,
but
this
is
kind
of
the
the
essential
bit
of
it
is
that
we
have
a
template
in
OpenShift
for
this
service
and
part
of
that
temp.
B
One
of
the
things
that's
parameterize
din,
that
template
is
the
application
version,
and
so,
when
we
process
the
template,
we
pass
in
the
application
version
from
that
version,
got
properties
file
and
apply
that
for
openshift.
You
know
for
the
particular
environment.
You
know
that
how
we're
using
that
we're
deploying
to
I
should
say
so.
B
We
leave
it
up
to
openshift
to
decide
whether
or
not
to
actually
do
the
deployment.
So
if
you
know
someone's
only
changing
the
version
of
say
the
API,
you
know
they're
going
from
one
two
three
12.4,
but
the
other
versions
of
the
the
user
interface
and
the
identity
servers
stay
the
same.
We
still
run
the
same
code.
We
still
apply
the
exact
same
thing
for
the
identity,
server
and
the
the
API
and
those
just
they
say
the
same.
B
You
know
because
they're
they're
already
at
their
desired
State
and
only
the
the
version
that
changed
actually
gets
changed
in
open,
shipped
and
deployed,
and
these
are
the
you
know
and
in
terms
of
the
open
ship
user
face.
These
are
the
the
pipeline's
on
the
pipeline
screen
and
they're
the
the
pipeline's
kind
of
rightmost
in
that
are
invoked
by
the
the
environment
pipeline.
B
Okay,
so
touching
on
the
the
builds
of
the
actual
container
images,
these
are
managed
by
build
configs
in
OpenShift
and
again
kind
of
a
similar
ami
convention
as
the
services
naturally
they're
immutable
images
we're
actually
using
the
source
to
image
piece
from
OpenShift.
We
didn't
actually
start
there.
B
We
started
with
docker
files
using
the
the
docker
docker
strategy
for
the
builds,
but
then
eventually
we
switched
it
up
to
two
source
to
image,
to
kind
of
bring
down
our
image
sizes
somewhat,
and
it's
been
working
working
pretty
well
really
and
here's
what
it
looks
like
in
open
ship.
We
just
got
the
three
builds
for
the
three
services.
These
are
build,
configs.
B
So
now
the
environments,
you
know
we
can
describe
these
as
a
combination
of
the
services
that
were
running
those
three
services
were
running
and
the
configuration
all
bundled
up
into
an
open
ship
project.
So
that's
what
what
we
determine
environment-
and
you
know
like
the
the
main
thing
again-
is
what
particular
database
that
a
service
is
pointed
to
you.
B
That's
kind
of
the
the
big
thing
so
there's
a
demo
three
database
and
if
the
environment
or
the
the
services
in
the
environment
are
pointed
at
that
database,
then
you
know
really
that's
the
thing
demo
3,
it's
it's
very
kind
of
database
centric
in
terms
of
what's
what's
most
important
to
to
this
application.
So
this
was
the
the
services
in
this
environment,
the
the
three
services
with
their
they're
running
pods,
here's,
the
config
Maps
one,
one
config
nap
per
service.
That's
that's
just
how
this
you
know
particular
air.
These
particular
services
work.
B
They
only
need
one
and
then,
of
course,
we
also
have
a
number
of
secrets
for
the
databases,
the
database
connection,
strings
and
a
handful
of
other
secrets
to
other
services
that
that
integrate
with
this
application
and
naturally
you're
not
sharing
any
of
that
and
then
there's
the
two.
So
you
know
in
general,
we've
got
all
these
environments.
You
know,
there's
that
that
dozen
or
so
environments
and
I
split
those
up
into
kind
of
conceptually
two
types
of
environments.
There's
your
your
build,
slash,
dev
environments
and
then
there's
everything
else.
Essentially
your
hire
environments.
B
So
so
talking
about
the
the
build
slash,
dev
environments
here
again
very
database
centric.
For
this
application,
though
we
have
the
the
database
and
then
the
the
version
of
the
environment
and
and
in
we
do,
builds
and
deploys
in
in
these
environments
and
it's
the
the
build.
But
that
kind
of
distinguishes
these.
These
particular
environments.
B
Okay,
so
master.
What
does
that
doesn't
even
kind
of
make
sense
as
a
version
and
it
might
have
been
a
bit
of
a
misnomer
by
me
early
on,
but
it's
stuck
and
and
just
not
gonna
change
it
now
at
this
point.
So,
by
master
what
I?
What
I
really
mean
here?
Is
it's
actually
the
head
commit
of
master
for
this
environment
so
what's
what's
being
deployed
to
this
devil,
3
environment?
So
that
means
that
all
the
services
are
pointed
at
this
devil.
3
database
is
the
head
commit
of
the
the
master
branch.
B
So
it's
the
the
latest
and
greatest
of
all
of
these
services,
all
the
the
most
recent
code.
It
might
all
work
together
or
it
might
no
it's
just
a
environment
to
do
really
early
integration
of
all
the
services
and
see
if
anything's,
even
working.
It's
this,
you
know
bubbling
cauldron
of
source
code,
you
know
and
whether
it
works
or
not,
you
know
you
might
you
might
reach
in
and
pull
out
some
magic
or
you
might
reach
in
and
you
might
not
even
have
a
hand
coming
out.
B
It
could
be
totally
broken,
there's
also
a
devil,
three
stable
environment,
where
that's,
where
the
the
first
place,
where
images
start
getting
built
with
actual
versions.
You
know,
based
on
those
tags,
we
saw
earlier
from
the
the
service
repos
and
that's
where,
where
things
start
actually
getting
kind
of
ironed
out
in
order
to
be
promoted
into
the
higher
environments,
and
so
that's
kind
of
what
the
build
to
what
we've
actually
been
looking
at
this
whole
time
is
a
build
/dev
environment,
with
this
kind
of
large
complicated
series
of
pipelines,
that's
just
one
kind
of
environment.
B
The
other
kind
of
environment
is
the
higher
environments,
which
is
everything
above
those
environments
in
the
software
development
lifecycle.
So
your
test,
your
demo,
your
pre
prod,
even
your
prod-
and
these
are
much
simpler,
they're
really
just
kind
of
focused
on
the
the
database,
the
and
then
they
take
that
further
they're
naming
convention
and
these
environments
only
do
deployments
and
and
really
prod,
is
just
another
hire
environment.
B
B
But,
of
course,
prod
has
much
more
restricted.
Access
and
fewer
people
have
rights
to
even
look
at
the
thing,
and
so
here's
the
higher
environment
pipeline
much
simpler
because
it
doesn't
have
to
invoke
those
service
pipelines
which
do
the
builds.
Instead,
the
higher
environments
only
do
deployments,
and
so
they
can
just
rapidly
run
through
the
deployments
of
things
that
have
already
been
built,
because
we're,
of
course,
using
the
immutable
container
images
that
we
had
built
in
the
lower
environments.
B
And
that's
it
you
know
running
through
the
our
flow
again.
We
have
a
new
version
proposed
via
pull
request.
We
have
a
web
hook
that
fires
on
merge
and
a
new
version
rolls
out.
So,
let's
see
if
if
this
video
makes
a
little
more
sense
to
us
now
so
now
we're
working
in
our
demo,
three
master
environment.
So
it's
it's
pointed
at
the
demo
three
database
well,
we'll
go
to
our
pipelines
just
to
kind
of
review
our
pipelines
again.
Here's
our
environment
pipeline,
the
deploy,
debo,
three
master
pipeline.
B
Here's
our
first
service
pipeline,
our
second
service
pipeline
for
the
UI,
our
third
service
pipeline
for
the
identity,
server
and
now
well
well
dive
into
get
here.
So
here's
our
environment
repositories
and
we're
changing
a
version
in
devil'
three
master.
For
this
little
demo,
it
was
version
got
properties
that
you
know
that
that
would
be
updated
if
you
want
to
change
the
version
of
a
service,
but
this
is
just
kind
of
testing
out
the
webhook
here.
So
this
is
the
the
pull
request.
B
Normally,
you
didn't
get
an
approval,
but
I
just
kind
of
needed
to
test
it
out,
so
I
go
ahead
and
dolf
merge
so
high
five
and
and
merge
the
pr
and
that
fires
off
the
webhook
which
initiates
this
pipeline
run
automatically
and
the
environment
pipeline
starts.
Invoking
the
the
service
pipelines,
starting
with
the
identity
server,
and
it
goes
ahead
and
checks
out
the
source
code.
B
B
Let's
say
conceivably,
you
know
we
could
parallelize
all
of
this,
but
it's
it's
small
enough
that
we
can
just
keep
it
sequential
and
it
still
runs
in
a
reasonable
amount
of
time
and
just
kind
of
keeps
things
a
little
more
sane
and
again,
the
UI
rolls
out
after
some
linting
and
the
environment
pipeline
does
its
final
verification.
Actually,
since
we've
since
I
took
this
video
we've
even
added
in
a
smoke
test
step
where
it
actually,
you
know
it
uses
a
headless
browser
to
log
in
and
test
it
out.
B
So
now
we
can
see
our
running
services
here
in
our
environment
and
that's
it
that's
our
get-ups
driven
deployment
on
openshift.
So
you
know
like,
like
we
said
at
the
outset.
This
was
the
kind
of
the
culmination
of
a
year
of
work
and
of
course,
you
know,
there's
a
lot
of
things
that
you
know
never
got
around
you
or
you
know
things.
I
would
have
done
differently
and
that's
that's
kind
of
what
these
are
so
never
really
got
around
to
having
a
good
story
for
local
development
on
an
open
ship.
B
You
know
the
the
developers
for
the
for
the
most
part,
with
maybe
the
exception
of
one
or
two
aren't
actually
running
over
shift
locally
they're,
not
using
mini
shift
or
anything
like
that
need
to
do
their
development
they're
just
kind
of
doing
the
development,
as
you
normally
would
within
an
IDE,
and
then
you
know
committing
it
to
the
bitbucket
and
then
they,
you
know,
actually
starts
getting
rolled
out
on
the
clusters
and
honestly
it.
Actually,
it
works
reasonably.
Well,
it's
the
it's
not
so
complicated
that
you
know.
We
need
that.
B
So
in
order
to
actually
have
all
of
those
environments
and
keep
them
maintainable,
we
actually
had
to
get
a
little
bit
clever
with
things
you
know
which
which
has
a
which
is
a
basically
a
trade
off.
Essentially,
you
know
we
inline
jenkins
files
in
a
lot
of
places.
You
know,
we've
got
a
library
for
some
of
the
the
factored
out
pipeline
code
and
it's
you
know
just
if
you
were
to
naively
come
to
the
system
and
look
at
it.
It
might
be
actually
kind
of.
B
It
would
take
you
some
time
to
really
understand
how
things
are
wired
together.
You've
got
a
fair
amount
of
documentation
that
goes
along
with
it
and
honestly,
this
this
presentation
fell
out
of
that
documentation,
but
it's
it's
a
little
more
complex
than
I
might
necessarily
like,
but
that
can
the
trade-off
there.
Is
we
actually
it's
more
maintainable
for
us
as
operations,
even
though
it
is
maybe
a
little
more
complex
and
there's
some
kind
of
invisible
wires
running
through
the
thing
you
know,
openshift
by
default
doesn't
deal
with
divergence.
B
B
We
can
we
can
hand
you
and
stuff
and
experiment
and
try
things
out
and
test
things
out,
but
which
is
which
is
great,
but
also,
if
we
don't
remember
to
and
do
that
stuff
it
can,
it
can
bite
us
later
and
certainly
has
and
there's
there's
also
no
automatic
rollback.
You
know
within
the
pipelines
if
something
actually
goes
wrong.
It's
a
matter
of
changing
the
versions
again
rolling
back
the
versions
by
hand
and
rerunning
the
pipeline
and
that
that
hasn't
turned
out
to
be
a
big
burden
at
all.
B
You
know
we,
the
the
occasional
pipeline
failure
that
we
get
typically
requires
some
sort
of
human
intervention.
Anyway,
that
you
know
we
need
to
look
at
what
error
note
and
why
and
understand
it,
and
you
know
remediated,
and
so
we
need
to
click
the
button
or
revert
the
versions
anyway,
so
that
that
hasn't
been
a
big
issue
for
us,
either
and
and
versioning,
like
all
the
things
like
I
can't
express
this
enough.
B
You
know
we
version
the
of
course,
the
the
container
images,
the
the
repos,
all
the
configuration
like
the
configuration
of
the
services
themselves,
the
deployment
configs.
We
we
version
the
environments
themselves
so
that
we
can,
you
know,
roll
out
the
environments
through
the
the
versions
of
the
environments
through
through
the
various
different
environments
as
well,
because,
honestly,
the
environment
is
just
another
application
dependency,
there's
all
sorts
of
tweaks.
We
have
to
make
to
the
environment
to
get
the
application
to
run.
B
You
know
when
it
has
to
access
different
resources
across
the
network
and
whatnot,
and
so
you
know,
versioning
the
environment
lets
us
kind
of
sanely
role
or
roll
out.
You
know
the
the
different
environment
versions
through
all
of
them
and
to
understand
exactly
what
changes
are
what
in
in
what
environment.
So
what
would
I
do
differently
on
this
sort
of
system?
B
B
Think
I
could
have
been
more
prescriptive
about
how
to
actually
use
the
system,
or
at
least
one
good
way
to
use
the
system
like
we
finally
wound
up
settling
on
something
really
good.
That
worked
for
for
everyone,
I
think
and
will
continue
to
work
in
the
long
run,
but
it
took
honestly
months
to
get
there
and
I
think
it
could
have
been
more
prescriptive
at
the
outset.
I
probably
would
have
done
an
openness
trip.
Project
dedicated
just
to
builds
I
had
the
kind
of
the
the
build
and
the
dead
environments
together,
and
that
was
I.
B
Don't
know
it
works.
It's
fine,
but
I
think
you
know
next
time
around
I'd
probably
have
something
dedicated
to
builds
right
now.
This
thing
is,
you
know,
kind
of
tailored
to
honestly
a
pretty
small
application
stack
just
just
the
three
services
you
know.
If
we
wanted
to
onboard
more
applications,
more
developers,
you
know
or
more
config-
or
you
know,
some
cots
software
or
some
commercial
off-the-shelf
stuff
you
know-
might
have
to
kind
of
make
a
number
of
changes
to
to
really
get
the
thing
to
scale.
B
I'm
aware
of
quite
a
bit
of
related
work
in
in
this
space
when
I
first
started
building
out
this
system,
Jenkins
X
was
was
kind
of
in
its
infancy
and
I.
Honestly,
I
wasn't
even
really
aware
of
what
it
did.
I'd
heard
of
it,
but
I
had
no
idea
what
it
was
it
just
kind
of
heard
of
it
passing
and
then
you
know
as
as
I
built
the
system,
and
it
was
kind
of
wrapping
it
up.
B
So
I
think
that
that
warrants
in
other
work
sorry
warrants
another
look,
we've
works,
kind
of
you
know,
I,
don't
know
if
they
necessarily
coin
the
term
get
ops,
but
they
certainly
popularized
it
with
a
couple
of
blog
blog
posts
early
on
and
really
that
was
only
two
or
three
years
ago.
This
this
other
company
in
container
solutions
has
got
some
great
posts
on
it
that
that
are
quite
informative
and
then
there's
this
article.
B
Actually,
this
is
kind
of
closer
to
an
academic
paper
on
get-ups
and
how
you
could
use
it
more
generally.
So
so
what
what
I
did
here
was
for
just
four
deployments
and
that's
it,
but
but
this
paper
describes
how
to
do
it:
kind
of
for
a
more
general
as
a
more
general
IT
service
and
making
it
much
more
self-service
was
which
I
thought
was
really
cool
and
kind
of
the
sorts
of
ideas
that
she
really
started.
B
Advancing
and
and
be
I
want
to
see
there
there
an
area
just
just
ripe
for
development,
which
is
which
is
great
and
then,
while
I've
written
a
blog
post
on
for
this
whole
presentation
as
well,
which
is
this
last
last
link
here,
which
you
can
kind
of
take
and
absorb
at
your
pace.
If
this
was
too
much
information
at
once.
So
with
this
I'll
stop
at
this
point
and
see
if
there
are
any
questions
so
Diane.
If
you
want
to
go
ahead
and
open
it
up
to
questions,
oh
I
can
field
anything
right
now.
All.
C
B
A
little
bit
the
under
the
hood,
but
we
we
didn't
actually
do
any
like
so
so
as
I
understand
it
and
I'm
not
like
super
deep
on
on
source
to
image,
but
but
as
I
understand
it.
If
you
wanted
to
create
a
custom
doors
to
image
like
a
vase
custom
source
to
image,
you
would
need
to
use
that
binary.
In
order
to
build
it
out,
we
were
able
to
use
the
default
source
to
image,
base
images
that
were
provided
by
Red
Hat
for
the.net,
stuff
and
and
roll
with
those.
B
C
A
D
B
A
B
Absolutely
so
so
in
in
store
short
answer
is
kind
of
yes
ish
and
yes,
ish,
one
of
the
the
things
that
you
know.
We
were
kind
of
I,
don't
know
boat.
Well,
one
of
the
principles
we
were
kind
of
operating
by
is
we
wanted
kind
of
the
most
vanilla,
openshift
possible
in
some
sense,
without
a
lot
of
customization,
and
so
boatman
ship
doesn't
come
out
of
the
box
with
helm
and
tiller,
but
they
do
have
that
templates
thing.
B
So
you
know
we
looked
at
templates
first
and
the
reason
we
wanted
to
keep
it
vanilla
is
because
honestly,
we're
a
really
small
team-
and
you
know
in
in
the
the
market
we're
in
right
here.
The
the
skills
are
aren't
pervasive
for
for
OpenShift,
you
know.
So
if
you
hire
someone
for
it,
you
know
you
want
to
be
able
to
hand
them
something.
That's
pretty
much
out
of
the
box,
even
though
we've
had
to
make
you
know
few
tweaks
here
and
there.
B
That
was
one
of
the
principles
we
were
operating
by
so
but
back
to
helm
until
her
so
yeah.
We
I
looked
at
them,
but
openshift
already
had
this.
This
templates
thing
so
templates
was
planning
based
on
that
principle
and
honestly
it
was
it
was
enough,
it
worked,
it
was
enough
and
it
was
simple
templates
is
actually
I.
One
of
the
things
I
quite
like
about
OpenShift
I
know
others
have
like
various
opinions,
but
honestly
it
just
it
worked
for
me.
It's
just
like
your
most
basic,
simple,
templating
solution,
which
is
great.
B
You
know
it's
probably
even
simpler
than
then
Jinja
or
some
of
the
other
templating
solutions
out
there
in
terms
of
operators.
Yeah
again,
a
matter
of
you
know
the
the
vanilla
thing
worked
for
us.
So
so
we
didn't
have
to
look
at
something
like
that.
I
think
if
we
were
to
get
into
deploying
stateful
services,
I
think
that's
when
operators
start
showing
a
lot
more
value,
but
all
of
these
services
were
a
hundred
percent
stateless.
You
know
we.
You
managed
to
fob
that
off
on
that
that
monolithic
to
be
underlying
the
whole
thing.
A
And
and
I
don't
see
any
other
questions
that
if
somebody
does
raise,
raise
their
hands,
but
it's
interesting
to
me
because
I
do
recall
it
I
think
you
came
out
of
Rackspace
as
well
a
while
back
Everett
and
I'm
interested
and
I
don't
know
if
other
people
are
on
the
topic
to
figure
out.
I
know
like
we
use
a
lot
of
the
same
practices
for
OpenShift
and
stuff
lots
of
initiatives
within
Red
Hat,
like
Michael,
had
chimed
in
as
well,
but
I'm
wondering
how
much
and
I
would
suspect
a
lot
of
enterprises
are.
B
B
Yep,
not
not
so
much
at
all,
this
stuff
is
was
was
very
new
to
certainly
to
the
the
client
I
was
with
and
honestly
it
was,
it
wasn't,
I
wouldn't
say
a
fight
to
get
it
in,
but
it
would
certainly
you
know
the
you
know
getting
people
to
understand.
What
I
was
trying
to
accomplish
here
was
was
non
non
trivial
and
honestly
I
was
I
was
working
through
a
lot
of
this
stuff
myself,
because
it
only
been
ideas
and
concepts
up
into
this
point
and
honestly
I
I
credit.
B
You
know
a
handful
of
the
people
at
the
client
who
were
really
supportive
and
then
who
helped
me
through
a
lot
of
this
stuff,
be
like
doing
the
the
hands-on
work
to
really
bring
this
bring
this
thing
to
life.
So
I
I
wouldn't
say
that
these
methodologies
are
pervasive.
There
is
a
fair
amount
of
openshift
used
in
the
market
around
here,
but
yeah
this,
this
particular
stuff,
not
so
much
I.
C
A
For
us-
and
you
know,
and
I
Laura
Laura
I,
think
I
recognized
you
from
doing
some
a
lot
of
automation
and
your
background.
So
yeah
I
am
definitely
talking
about
Greg,
Swift
and
he's
one
of
my
favorite
people,
because
he's
always
on
our
slack
channel
and
helping
other
people
even
now
that
he's
over
at
log
DNA
I
believe
but.
A
So
there's
really
some
great
people
coming
out
of
Rackspace
and
going
into
it
and
and
I
mean
we
do
love
them
and
we
love
the
work
you
guys
do
and
the
contributions
you've
made
from
all
over
the
Commons
universe,
and
so
it's
wonderful
so
we're
almost
at
the
end
of
the
hour.
I,
don't
see
any
other
questions
yet
so
I
want
to
thank
you
for
getting
up
at
7:00
a.m.
your
time.