►
From YouTube: DLV002 - 2019-03-13 - Delivery team Training - Release tooling and process overview in March 2019
Description
John Skarbek gives an overview of processes and tooling for creating a GitLab release
Slides: https://docs.google.com/presentation/d/1kwi3IMBqkDzlA9mLqt9c5AftzAh8YpddsAOhI6c_cJA/edit#slide=id.g29a70c6c35_0_68
A
A
I'm
John
skarbek
I'll
work
on
the
delivery
team
and
I'm
gonna
give
a
short
overview
as
to
what
a
monthly
release
looks
like
for
a
release
manager.
Please
keep
in
mind
that
this
presentation
is
not
going
to
encompass
everything.
Release
manager
does
because
there's
quite
a
few
today
we're
going
to
target
a
couple
of
specific
things,
also
keep
in
mind
that
processes
change
very
quickly
in
our
environment.
What
I
say
today
and
what's
inside
the
slide
deck
may
not
be
up-to-date
if
you're
looking
at
this
in
the
future.
So
just
keep
that
in
mind.
A
So
today
we're
going
to
do
an
overview
of
the
timeline
of
the
release
procedure,
specifically
I'm,
going
to
use
the
example
of
releasing
11.8,
which
is
a
monthly
release
or
a
minor
release
that
we
do
for
gitlab
and,
secondly,
we're
going
to
cover
a
wide
array
of
the
tooling
that
we
use
so
I've
got
a
lot
of
diagrams.
These
are
for
the
presentation
purposes,
I've
split
up
the
diagrams
and
the
smaller
chunks
that
way
it's
easier
to
present
I've
got
a
dot
a
link
to
the
actual
diagrams.
A
At
the
end
of
this
presentation
for
looking
at
in
the
future,
so
let's
get
started
first
up
is
our
timeline,
so
there's
a
few
things
that
we
do
in
related
to
our
branches,
that
we
need
to
ensure
that
we
keep
a
stable
pace
on.
So
one
of
the
projects
we
have
is
called
a
merge
train,
so
we
had
two
code
bases
for.
A
A
B
A
Take
two
so
there's
a
few
things
that
we
accomplished
as
part
of
our
process,
of
ensuring
that
we
have
stable
branches
along
the
way
as
we
do
a
release
so
step.
One
is:
we've
got
two
code
bases
get
live
ce4
the
Community
Edition
get
lab
EE
Enterprise
Edition.
You
want
to
make
sure
that
any
changes
that
go
into
seee
actually
make
it
into
the
Enterprise
Edition.
So
we
have
a
merge
train
on
a
cadence
of
every
20
minutes.
It
will
run
and
take
any
changes
and
merge
those
into
the
EE
branch.
A
The
second
thing
is
something
that
a
release
manager
does
currently
in
a
manual
process.
It
will
take
a
a
release.
Manager
will
take
a
snapshot
at
a
current
point
in
time
and
mainly
make
changes
of
the
master
branch
into
a
stable
branch
that
has
been
created
when
the
process
of
doing
a
monthly
really
starts.
A
A
From
a
development
perspective
from
as
close
as
possible
to
the
previous
month,
release
the
22nd
we
will
anyone
will
be
working.
Excuse
me
rather
from
minus
infinity
in
time
an
engineer
will
be
working
on
the
feature:
development
for
11.8
in
this
example,
and
that
will
continue
all
the
way
up
until
the
7th,
which
is
our
feature
freeze
date
between
the
feature
freeze
date
of
the
7th
and
the
22nd
of
our
release.
A
Anything
that
makes
it
into
that
11
8
release
is
going
to
be
specific
to
anything
that
has
been
considered
releasable
in
any
bug,
fixes
or
security
regressions
that
we
need
to
fix
during
that
period
of
time.
If
any
feature
work
was
developed
but
didn't
make
it
into
that
release,
it
will
get
delayed
into
11
9,
or
we
have
a
exception
request
that
we
have
engineers
fill
out
in
case.
We
need
to
bring
something
in
at
the
last
second.
A
From
a
release
managers
standpoint
there's
a
few
things
that
we
do
throughout
the
month.
The
first
thing
that
we
do,
however,
is
create
an
issue
that
helps
us
track
where
we
are
as
far
as
status
for
that
issue
or
for
that
release.
So
in
this
case,
we'll
create
an
issue
called
eliminate.
This
will
stay
open.
We
open
this
as
close
as
possible
to
this
22nd
of
the
previous
month,
and
it
will
stay
open
all
the
way
through
until
that
release
has
made
it
out
the
door.
A
This
issue
is
a
large
set
of
tasks
that
we
run
through,
that
we
check
as
we
roll
through
the
process
just
to
help
us
to
keep
track
of
where
we
are
in
the
progress.
One
of
the
first
items
that
we
accomplish
during
a
release
is
start
the
release
candidate.
This
happens
shortly
before
the
7th
we
try
to
target
that
week
before
the
7th.
This
allows
us
to
take
the
large
amount
of
changes
that
happen
and
get
it
to
a
testable
state,
so
we'll
create
the
release
issue,
which
again
is
just
another
issue.
A
That's
full
of
check
boxes
that
we
need
to
run
through
later.
On
when
we
get
to
the
appropriate
step,
we'll
tag
that
issue
or
tag
that
release,
which
will
kick
off
a
build
in
one
of
our
projects
that
build
if
successful,
will
kick
off
a
deploy
to
our
staging
environment
automatically.
Assuming
that
deploy
was
successful,
we
will
then
create
a
qae
task.
This
is
an
issue
again
in
which
we
tagged
all
of
our
engineers
and
all
of
the
change,
and
we
make
a
comment
about
all
the
changes
that
made
it
into
this
release
candidate.
A
A
A
Candidates
are
created
pretty
much
only
if
we
need
them.
We
want
to
create
as
many
as
we
feasibly
can
as
a
way
to
test
the
minimum
amount
of
changes
possible.
As
we
progress
through
the
month,
the
company
has
a
goal
to
publish
on
the
22nd
of
every
month,
so
we
want
to
make
sure
that
everything
has
been
fully
vetted
out
and
tested,
as
a
month
has
progressed.
A
In
my
example,
we've
made
it
up
to
RC
11
in
my
pretty
diagram,
I.
Think,
realistically,
when
we
released
11
aa
date,
we
made
it
to
RC
8.
Before
we
publish
publish
the
official
11
8
version
hypothetically,
there
will
be
no
change,
no
code
changes
between
the
last
RC
that
was
created
and
what
gets
published
to
the
public,
the
only
difference
being
what
version
we
have
inside
of
that
package.
So,
instead
of
11
at
8.0,
RC
11,
it
would
simply
be
11,
not
a
dot
0.
B
B
You
know
infinity
to
the
7th
and
then
there's
a
future
freeze
and
then
11
9
feature
development
continues
actually
11
9
feature.
Development
starts
on
the
date
of
the
feature
freeze
of
11
8,
which
means
that
the
right
side
need
to
align
with.
You
know
the
reddish
column
there.
So
just
an
icon
to
clear
up
here.
A
Okay,
I'll
move
on
to
the
tooling
again.
This
is,
for
the
purposes
of
the
presentation,
I've
taken
a
larger
diagram
and
carved
out
chunks
of
it.
So
again,
I'll
have
the
link
at
the
end
for
everyone,
so
the
first
row
I
want
to
mention
is
chat
ups.
This
is
a
company-wide
tool.
Everyone
uses
it.
It's
a
this,
a
simple
bot
that
sits
inside
of
slack
that
everyone
could
talk
to
us
necessary.
A
It
listens
to
a
lot
of
commands,
but
here
in
this
diagram
have
highlighted
a
couple
of
the
important
ones
that
the
release
managers
will
utilize
arms.
Will
arms
will
primarily
use
chat,
ABS
as
a
gateway
into
our
release
tools,
project,
which
is
where
the
majority
of
our
tooling
actually
happens.
So
we
have
a
large
set
of
right
tasks
inside
a
release.
Tools
takes
in
a
couple
of
variables
and
performs
a
bunch
of
actions
for
us
a
lot
of
this.
We
we
kick
off
all
of
these
issues,
mainly
for
the
time
being.
A
A
Release
tasks:
this
is
simply
a
location
where
we
have
all
of
the
issues
that
I
mentioned
beforehand
to
push
them
in
a
place
where
people
have
visibility
into
where
we
are.
As
far
as
status
goes
for
the
release
during
the
month
so
release
eleven.
Eight
zero
is
going
to
be
just
the
large
task
list
that
release
managers
follow
for
the
entire
release
process
of
that
eliminate
0rc
one
well,
there's
a
typo.
This
is
going
to
be
specific
to
that
very
release
candidate
and
then
eleven
eight
zero
arcing
1qa
tasks.
A
This
is
that,
for
the
very
first
ones
can
be
that
large
list
of
tasks
that
tags
all
of
our
engineers
that
we
want
people
to
check
off
and
make
sure
things
are
working
in
the
staging
environment
before
you
can
continue
on
a
biscuit
lab
is
one
of
our
larger
projects.
This
one
has
an
amazing-looking
CI
pipeline.
A
The
responsibility
for
on
biscuit
lab
is
to
build
things.
It
will
reach
out
to
the
necessary
projects
to
bring
in
all
the
versions
that
we
desire,
so
it
will
reach
out
to
all
over
the
get
lab
some
components
as
well
as
projects
that
we
include,
such
as
Postgres
or
prometheus,
and
bring
in
the
specified
versions
that
we
need
so
as
inputs
to
omnibus
gitlab
are
going
to
be
like
branches
or
tags
that
we
use
and
those
kickoff
the
necessary
builds.
A
The
outputs
from
advocate
lab
are
primarily
going
to
be
our
build
artifacts,
so
the
RPM
packages,
the
Damien
package,
is
in
the
docker
images.
There's
a
few
aspects
to
omnibus
gate
lab
one
we
have
our
nightly
builds
for
both
nightly
c
e
and
e.
For
both
of
these
we
build
all
of
our
packages.
We
just
don't
publish
all
of
them
nightly.
A
Ee
will
publish
only
the
Ubuntu
1604
Davian
package
that
way
it
can
be
later
installed,
via
our
dev
and
ops
instance,
on
a
nightly
cadence
I
believe
they
have
cron
jobs
for
those
whenever
we
are
ready
to
perform
a
release
of
some
sort,
we'll
tag
our
bill.
So
in
my
example,
here
we're
tagging
eleven
eight,
zero,
plus
c
e
or
e.
Those
will
kick
off
the
necessary
builds
which
starts
to
build
our
packages.
A
Ok
deployer:
this
is
a
project
that
it's
pretty
self-explanatory.
Gait
lab
omnibus
will
trigger
a
deploying
to
our
staging
environment.
Automatically
anytime
get
lab
EE
is
built.
We
utilize
chat,
ops
to
trigger
deploys
to
the
Canarian
production
environments.
Using
deployer
deploy
is
a
set
of
ansible
playbooks
and
it
uses
c
CI,
that's
held
on
our
instance
for
running
all
the
operations,
and
the
last
thing
I
want
to
talk
about
is
a
little
bit
of
how
we
segregate
our
security
work
a
tad
bit.
A
So
we
have
our
two
repositories
for
get
labs
EE
and
get
lab
EE,
but
they
live
in
two
different
locations.
So
we
have.
These
repos
are
both
in
our
get
lab
comm
for
the
public,
and
we
also
have
a
set
of
repos
on
our
dev
instance.
The
process
and
the
way
people
work
is
pretty
much
the
same.
It's
just
if
it's
a
security,
specific
issue,
for
example,
when
we
released
1181,
for
example,
all
that
work
happens
on
our
dev
instance.
A
A
C
A
So
this
is,
if
you're
seeing
my
screen
still,
this
is
the
full
chart,
as
is
there
are
a
couple
of
typos
and
a
couple
of
errors
that
are
not
entirely
correct,
but
you
know
chat.
Opps
is
our
gateway
to
release
tools
and
release
tools,
does
quite
a
few
things.
So
if
we
wanted
to
follow
one
of
these
as
an
example
like,
let's
take
our
monthly
issue
that
gets
started
so
we
issue
the
chat,
ops,
command,
release,
issue,
eliminate
0.
A
This
will
kick
off
a
rake
task
called
monthly
issue,
taking
the
appropriate
variables
in
and
that
reg
test
does
a
few
things
so
one
it
creates
a
branch
and
all
the
necessary
projects.
So
we'll
get
a
eliminate
stable
branch.
11
8,
stable
EE
branch
is
necessary
and
the
same
thing
for
on
mesquite
lab
and
then
one
of
the
other
things
we'll
do
is
create
a
release.
Inside
of
the
release
tasks
project,
it
will
create
our
monthly
issue
that
has
a
large
set
of
checklists
for
us
to
go
through.
C
Jerry,
so,
first
of
all,
thank
you
for
this,
because
this
clears
a
lot
of
the
cloudiness
in
my
head
of
all
the
stuff
that
goes
on.
My
question
is
more
meta
than
any
specific
stuff.
Is
there
or
are
you
working
on
the
moral
equivalent
of
this
presentation
for
what
things
would
look
like
in
a
few
months.
C
I
mean
by
the
reason
why
I'm
asking
is,
you
know
there
is
in
order
to
make
these
changes.
There
is
obviously
all
the
work
that
that's
happening
in
delivery
that
that
you
are
doing,
but
then
there
is
also
all
this
communication
that
it's
I'm
trying
to
over
communicate.
These
changes
because
they're
there
they
will
affect
a
large
part
of
a
regular
population,
and
so
I
just
want
to
make
sure,
on
the
one
hand,
that
we
can
show
the
effects
of
this
work
and
how
some
of
this
is
gonna
get
simplified.
B
Makes
sense,
Jerry
I
think
we
definitely
have
plans
to
present
this.
We
only
want
to
try
to
remove
some
of
the
manual
items
that
we
are
doing
now
and
remove
some
of
the
boxes
that
you
see
on
the
screen
right
now,
because
that's
taking
significant
chunk
of
our
time
so
remove
the
manual
stuff
before
we
can.
You
know,
go
proudly
to
youtube
and
show
like
look
how
great
of
our
pipelines
look
and
then
get
trashed.
Well,.
B
C
The
things
that
I'm
saying
are
more
on
my
wheelhouse
than
anyone
elses,
but
it's
good
to
be
able
to
show
this
progress.
I
think
this
is
this
is
fodder
for
or
obviously,
presentations
at
conferences,
for
instance,
and
certainly
is
stuff
that
I
want
to
be
able
to
share
at
Eric's
level.
You
know
to
give
you
an
example:
I
I
know
that
there
are
some
more
members
are
highly
interested
in
how
we
move
and
one
we
wants
to
see
ICD
so
just
being
able
to
ever
communicate
this.
It's
good,
because
these
will.
B
B
Totally
makes
sense
and
I
guess
I
can
poke
it
put
it
on
my
task
list
to
do
a
snapshot
before
so
we
didn't
do
it.
When
we
started
with
the
team,
we
had
too
many
other
issues
to
take
care
of,
but
I
actually
do
a
similar
presentation
with
a
similar
graph
to
just
show
one
step
back
before
we
introduce
shadows
before
we
introduced
all
of
these
automation.