►
From YouTube: SIG Release Deep Dive – Jaice Singer DuMars & Caleb Miles, Google (Intermediate Skill Level)
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
SIG Release Deep Dive – Jaice Singer DuMars & Caleb Miles, Google (Intermediate Skill Level)
The Kubernetes Release Special Interest Group is focused on creating deliverable increments of value to the end-user community, as well as improving the process over time. This session will go through the release process, explain the various roles, risks, and responsibilities. It will also provide an onramp for anyone interested in volunteering for a release team position in the future.
About Jaice
I am passionate about vibrant, diverse, and inclusive open source communities, all things governance, continuous improvement, and Agile at scale. I have been a Kubernetes release manager, and co-lead various Kubernetes Special Interest Groups.
About Caleb
He is a technical program manager at Google.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
B
A
Right,
the
fantastic,
so
hopefully
there
won't
be
too
much
repetition.
We're
gonna
just
go
through
the
overview
deck
briefly,
and
then
we
got
a
really
special
surprise,
courtesy
of
Caleb
miles.
So
so
let's
go
and
get
started
here.
So
we're
gonna
just
go
over
a
few
aspects
of
the
sig
itself
and
why
it
was
originally
created.
A
B
So
just
a
quick
recap
from
the
last
session
about
values.
It's
trust
I
mean
we
are
running
people's
a
critical
infrastructure.
People
build
their
businesses,
both
their
internal
businesses
and
business
on
top
of
kubernetes
as
a
vendor.
So
we
take
that
that
faith
very
seriously
and
so
consistencies
making
sure
people
can
depend
on
that
release,
process
developing
delivering
a
high-quality
release
close
to
when
we
intended
we
are
luckily
to
generally
get
within
a
week
of
our.
B
You
know
our
chosen
deadline,
which
was
you
know,
seven
three
months
in
the
past
like
this-
was
mentioning
high
quality.
Its
you
know
test
passing,
hopefully
no
critical,
vulnerabilities
transparency.
We
do
a
lot
of
work
in
the
open
and
we're
tracking,
more
and
more
things
and
to
get
for
posterity
and
continuous
improvement.
Jase
has
done
an
amazing
job,
leading
our
release
retrospective
for
almost
two
years
now,
so
it's
been
fantastic.
A
So
if
you,
if
you
go
through
the
googles
and
find
that
I
highly
recommend
it,
we
also
try
and
decide
release
policy
so
we're
trying
to
balance
the
needs
of
developers
in
the
community
and
that's
tricky,
sometimes
because
developers
want
velocity
and
the
community
wants
stability,
so
we're
we're
always
dancing
on
that
knife
edge.
We're
also
trying
to
drive
automation
in
the
project
so
that
there's
less
human
things
and
more
machine
things.
Unfortunately,
the
release
process
does
have
a
lot
of
manual
steps
and
a
lot
of
manual
work.
A
Anybody
who
has
done
the
docs
work
definitely
has
felt
that,
and
that
is
something
we're
trying
to
improve,
and,
lastly,
we're
trying
to
set
examples
for
other
SIG's.
So
we
have
a
really
clear
role:
definition
for
for
people
who
know
with
the
release
we
try
and
always
replace
people
who
are
doing
the
same
roles
over
and
over
again,
so
that
we're
not
having
people
get
burnout
and,
lastly,
we're
trying
to
find
good
ways
to
communicate
lots
of
information
that
impacts
people's
lives.
So
that
is
a
relatively
delicate
ballet.
B
So
we
do
the
day-to-day
I
guess,
meeting
potatoes
work
of
sick
releases,
Elyse's
the
release
perspective.
How
do
we
do?
What
can
we
do
better
in
the
future
and
coordinating
a
bunch
of
work
across
the
six,
particularly
in
documentation
and
bug
triage,
but
we're
just
gonna?
You
know
fly
through
these
slides
because
many
of
you
were
here
at
the
intro
session,
so
we're
like
I'm
sit.
B
A
B
Just
highlight
that
it
used
to
be
just
the
one
release
are
back
in
the
old
days,
couldn't
even
find
the
page,
because
it's
in
the
wayback
machine,
so
you
no
longer
for
wiki,
thanks
to
Aaron
for
moving
that
away
from
the
wiki
and
into
proper
files
checked
in
to
a
source
control.
And
so
it's
labelled
operation
on
the
rolls
and
Jase
mentioned
that
we've
added
a
shadow
role
which
is
really
helping
for
secession.
So
we've
really
opened
up
the
bus
there
for
releasing.
A
B
A
I
also
say
that
a
hallmark
of
our
sig
is
that
it's
actually
fun.
Oh,
we
really
do
try
and
make
these
activities
fund.
The
release
process
can
be
a
thankless
job
sometimes,
and
there
is
a
lot
of
camaraderie.
It's
probably
I,
think
in
my
experience
in
the
community,
the
closest
knit
of
all
sexes.
We
by
the
end
of
the
release,
team,
everybody's
friends,
is
just
a
really
intensely
bonding
exercise.
A
A
He
foolishly
fell
from
my
ploy
to
say
how
much
fun
it
was
sorry
Josh,
that's
right
well,
so
first
first
thing
about
being
released
lead
is
that
it
requires
a
fair
amount
of
domain
expertise
in
the
project,
so
being
a
developer
or
being
somebody
who's,
solid
and
intestine,
for
structure
or
those
things
may
or
may
not
help
you.
What
really
helps
you
is
to
know
what
the
project
looks
like
as
a
whole.
A
A
We
also
started
checking
in
more
documents
into
github.
We
looked
at
as
a
team.
How
do
we
make
meetings
more
effective
and
in
facilitate
communication
better
so,
for
example,
in
1.10
I
started
sending
regular
release
updates
to
communities
dev,
so
people
would
always
know
what
was
happening
this
week.
What
was
coming
next
and
we're
basically
in
this
constant
fine-tuning
processor
and
what
the
project
and
program
looks
like.
So
it's
really.
A
It
is
a
job
that
requires
a
lot
of
technical
stitute
in
the
sense
that
you
need
to
know,
what's
going
on
and
be
able
to
to
validate
things
but
really
you're,
building
a
trusted
relationship
with
sikh
leaders
with
your
team,
with
the
people
on
the
rolls
and
then
you're
also
making
sure
that
there's
somebody
there
along
the
way
who's,
hopefully
going
to
be
able
to
replace
you
in
the
in
the
next
release
cycle.
Because,
as
of
yet
we
have
not
had
anybody,
be
release
Li
twice
in
a
row.
A
I
did
one
date
and
then
I
was
the
shadow
41.9
and
then
I
did
110,
so
I've
probably
been
the
closest
to
to
being
multiple
times.
But
it's
it's
certainly
not
something
that
we
want
to
encourage
because
there's
a
high
level
for
now
factor
that,
after
after
being
a
lean,
so
Josh,
you
know,
take
care
yourself.
A
No
I
would
not
recommend
it
so
yeah.
Essentially
the
release
lead
is
a
chance
for
us
to
distill
these
values
out
and
and
and
really
be
a
good
keeper
of
that
trust.
And
so
one
thing
I
would
say
a
misconception
about
the
release
lead
early
in
the
project.
The
releases
our
position
was
much
more
of
a
unilateral
decision
maker
and
obviously
you
would
be
involved
in
decision-making,
consensus
and
whatnot,
but
back
then
it
was
a
little
more.
You
had
a
lot
of
authority
as
a
person
and,
technically
speaking,
the
release.
A
Lead
still
has
a
lot
of
authority
if
I,
if
I
wanted
to
unilaterally
decide
to
hold
off
the
release,
I
could
but
the
the
thing
that
is
really
important
to
remember
about
this
position
and
any
position.
Actually
the
leadership
in
the
community
is
it.
You
were
really
never
yourself
when
you're
in
that
position.
You
are
a
representative,
and
so
there
were
times
for
example,
that
a
decision
would
come
up.
B
Life
as
a
branch
manager
for
the
release
team,
it's
actually
a
pretty
relaxing
job.
I'll
say
it's:
well
it
largely
it's
a
reading
the
release,
schedule
and
making
sure
you
do
the
things
at
the
right
time,
which
is
the
really
the
hardest
part
of
the
job
one
day,
they'll
event
some
kind
of
software
tool.
That
will
remind
you
when
important
dates
come
up.
I
hope,
it'll,
take
off
we're
lucky
to
have
Mike
with
us
who
actually
wrote
a
lot
of
the
first
generation
of
this
release.
B
Tooling,
and
since
then,
we've
got
a
larger
and
more
expanded
release.
Engineering
team
that's
been
able
to
make
the
job
much
much
more
easy
than
it
has
been
the
past
so
life.
For
me,
as
a
branch
manager
means
I
live
mostly
here
in
the
kubernetes
of
release
or
posit
ori,
which
has
got
all
of
the
tools
you
could
ever
run.
The
big
ones
are
historically
as
a
tool
called
Onaga,
which
basically
is
the
one-stop-shop
for
releasing.
It
is
a
very
well
crafted
bit
of
a
bash
here
and
actually
probably
easier
just
to
show
the.
A
B
Now
I'd
say
that
exactly
let's
see
you
just
look
out
here
so
the
primary
tool
here,
that's
the
entry
point.
We
have
a
David
to
thank
for
lovely
lovingly
tending
our
collection
of
build
and
release.
Tooling
I
do
amazing
work
and
without
them
definitely
could
not
doubt
release
so
now.
Go
is
the
historical
tool
it
has
been
wrapped
and
more
or
less
I
guess
superseded,
because
everything
getting
it
can
get
better,
which
is
the
whole
point
of
having
a
retrospective,
buy
a
new
tool
called
Google
container
builder
manager,
GCB
MGR.
B
So,
like
the
name
alludes
to
GCE,
MGR
is
based
on
Google
container
builder,
and
so
I'll
do
a
a
quick
plug
that,
if
you've
got
a
way
of,
if
you
need
Ducker
images,
this
is
a
great
way
of
doing
it.
So
this
runs
all
the
stuff
in
the
cloud
and
used
to
have
them
to
have
a
very
beefy
machine
in
order
to
cut
a
release.
I
think
my
machine
back
in
the
office
has
80
or
so
gigs
of
RAM
and
really
large
SSDs.
B
B
Great
so
and
life
is
basically
pretty
simple
in
the
beginning,
before
code
freeze
as
the
branch
manager,
you
are
mostly
responsible
for
just
producing
Alfa's
according
to
the
schedule,
so
that's
run
directly
against
master
and
we
can
actually
try
and
show
some
of
that
sausage
being
made
cutting
a
a
a
mock
build
now
for
you
all.
So,
let's
pray
to
the
live
demo
gods,
oh
I,
know
I,
know
I
got
to
do.
B
I
got
to
do
some
more
magic
over
here,
so
sorry
be
a
screen
that
will
probably
pop
up
annoyingly
anyway
and
do
some
get
pulling
so,
hopefully,
that's
also
okay,
cool
man
fast
forward.
This
is
great
such
a
good
life.
The
David
is
also
super
careful
with
that
with
the
get.
So
that's
makes
your
life
very,
very
nice
as
the
release
branch
manager,
so.
C
B
So
we're
gonna,
so
there's
so
GCB
a
manager
breaks
up
the
release
process
into
two
phases:
there's
the
stage
which
gets
all
the
bells
of
the
builds
and
then
there's
a
release
process
which
move
those
bits
into
the
right
locations.
So
that's
a
GCS
bucket,
so
Google
Cloud,
Storage
and
images
that
are
hosted
in
Google
Cloud
repositories.
C
C
B
Off
of
master
and
asked
me
for
more
credentials,
which
is
not
interesting,
so
you
will
get,
it
will
very
quickly
jump
in
and
tell
you
that
your
job
has
been
successfully
submitted
and
you'll
be
able
to
go,
see
it
for
real.
So
let
me
I'm
gonna
tail,
which
will
require
me
to
enter
some
more
credentials.
We
really
do
like
our
security,
which
you
know
it's
it's
important.
B
There's
that,
and
if
you
were
looking
quickly,
you
would
have
noticed
and
actually
I
will
not
show
you
this,
because
it's
it's
actually
a
pretty,
not
interesting
page
but
I'm
gonna
start
telling
the
logs
you
can
see
the
the
process
going
live
and
after
giving
my
credentials
for
the
last
time,
though,
that
was
another
thing
about
anot.
Oh,
you
had
to
give
your
credentials
multiple
times
during
the
release
at
critical
points.
B
It
was
also
very
interactive
in
terms
of
asking
you
to
do
stuff
and
they
make
that
a
bit
bigger
and
hopefully
GSP
will
start
sending
me
information
about
the
builds
there
we
go,
and
so
since
we're
a
containerized
world,
a
lot
of
this
stuff
is
building
and
run
running
on
with
docker
images.
So
you'll
see
a
bunch
of
polls
and
it's
all
happening
in
the
cloud
so
which
is
great
because
you
know
the
conference.
Wi-Fi
is
actually
amazing
here.
This
has
been
wonderful.
B
But
yes,
and
then
it'll
start
rolling
through
Anagha
but
running
in
the
cloud
for
you,
so
this
is
more
or
less
as
the
branch
manager.
You
just
look
and
see
that
everything
that
works
smoothly
and
as
long
as
you
get
the
dates
done
correctly,
life
is
pretty
good.
So
that's
you
know
my
job
as
a
branch
manager,
so
they're,
interacting
with
this.
B
After
code
freeze,
we
use
a
tool
called
branch
diff
to
sort
code
freeze
what
we
do
is
we
create
a
new
branch
that
and
we
fast
forward
that
branch
into
the
release
branch
that
we're
working
on
stabilizing
and
at
some
point
we
only
admit
cherry-pick
so
the
bar
for
quality
and
importance
goes
up
pretty
dramatically
at
that
point.
So
this
is
going
to
be
into
a
bunch
of
stuff
and
it's
going
to
put
bits
in
testing
repositories
and
our
staging
bucket.
B
It
is
supposed
to
protect
access
to
these
streaming
logs,
so
I
entered
my
credentials,
and
this
is
largely
to
do
the
fetching
so
I'm
accessing
the
the
logs
from
that
should
being
streamed
from
container
builder
does
require
authentication
and
I
prove
I,
get
to
provide
that.
Thankfully
it
is
Google.
So
it's
all
very
seamless,
if
you
have
noticed
I,
am
running
this
on
my
pixel
book
and
connecting
to
a
machine
that
is
not
Mike's
a
book.
So
doing
all
that
plumbing
from
my
local
machine
with
a
very
limited
operating
system
is
magic.
A
Okay,
so
the
question
is:
what
is
the
time
commitment
for
a
release
lead?
It
depends.
So
if
you
think
of
the
three-month
arc
of
the
release,
the
first
month
is
relatively
low
time
input.
You
have
a
one-hour
week,
meeting
you're
focused
on
filling
rolls
and
making
sure
that
everything
is
in
place
to
move
through
life
cycle
of
the
release,
so
maybe
four
to
six
hours
a
week
pretty
reasonable.
The
second
month
is
about
double
that,
because
you
start
having
to
pay
close
attention
to
it,
and
the
third
month
can
vary
wildly.
A
In
the
last
couple
weeks,
it
gets
pretty
intense
you're
you're
dealing
with
one-hour
meeting
every
day
of
the
week,
so
this
I
guaranteed
five
hours
of
time
at
least
an
hour
of
prep
time
so
make
it
ten
and
then
you've.
You
know
figures
just
the
two:
all
the
horse
races
happening
in
three
days
places
you
have
to
keep
an
eye
on
and
see
who's,
getting
things
done
or
not
and
where
you
have
to
intervene
as
a
lead
to
make
sure
that
things
are
on
track.
1.8.
A
For
example,
we
had
a
huge
slew
of
unfinished
Docs,
and
so
I
had
to
go
and
literally
chase
down
every
single
person
that
did
not
have
a
doc
and
want
them
every
single
day
to
make
sure
it
was
on
so
it
can
be,
it
can
be
pretty
intense.
What
I
would
say
is
it
if
somebody
wants
to
be
a
release
lead
a
requirement
of
the
job
description
is
that
you
are
in
the
release
team
in
some
capacity
as
a
fully
fledged
member,
and
not
a
shadow
for
one
full
release
cycle.
B
A
B
B
So
we've
got
a
tool
test
grade
if
you're
familiar
with
historical
CI
systems
is
similar
to
CI,
where
you've
got
tests
running
dependently
by
some
unknown
agent.
That
is
publishing
results
in
a
well
structured,
meaning,
XML
format
that
is
collected
and
displayed.
So
that's
the
architecture
here.
This
is
not
I'm
actually
running
any
builds.
That
work
is
done
by
another
tool
which
I
should
just
actually
be
stacking.
This
you
can
keep
watching
the
interesting
stuff
next
life.
B
Definitely
our
amazing
I,
mentioned
or
alluded
to
our
amazing
test
infrastructure
team
has
produced
moving
us
all
off
of
Jenkins
some
time
ago.
Well,
not
all
that
much
time
ago,
but
it's
it's
proceeded
in
the
back
of
my
mind
anyway.
So
we've
got
a
fantastic
tool
called
prowl
that
is
got
a
plugin
system
that
runs
the
top
of
kubernetes.
That
is
doing
all
of
the
running
of
the
builds
for
you
based
on
github
events.
B
A
Yes,
so
the
question
is:
what
is
the
state
of
release
cadance?
Are
we
fixed
on
these
three-month
Cadence's?
Are
we
looking
at
faster
or
slower?
There
is
a
surprising
or
not
surprising
how
you
look
at
it,
a
division
of
folks
who
want
to
do
less
and
then
there's
more
so
I
the
there
are
trade-offs
to
both.
Essentially
when
we
start
talking
about
who
our
customers
and
we
look
at
enterprise
customers,
their
tolerance
for
change,
especially
rapid
change,
is
lower.
A
A
We
are
going
to
have
to
tackle
that
in
the
near
future.
It
is
not.
It
is
not
in
a
state
right
now
where
we
have
a
definitive
opinion.
As
a
group,
it
will
probably
be
a
collaboration
between
the
sig
and
sig
architecture
and
perhaps
the
steering
committee
as
well,
because
there
will
be
material
impact
to
our
user
community
in
a
way
that
probably
very
few
other
things
could
be
in
the
way
that
this
will.
A
B
A
B
One
thing
is
getting
faster
feedback,
and
so,
if
you
went
to
the
contributor
summit,
the
first
day,
Tuesday,
billed
and
released
locally,
is
still
a
challenge.
There
are
many
different
platforms
because
we're
a
sprawling
open
source
community
to
try
and
support
so
getting
developers
faster
feedback
is
is
definitely
important.
B
It
is
hard
to
run
the
end-to-end
tests
by
yourself,
and
that
remains
true.
So
if
you
are
developer
and
having
the
expectation
that
you
must
submit
a
pull
request
in
order
to
get
your
pull
request
validated
for
you
know
for
correctness
that
that
is
a
challenge.
Given
the
complexity
of
supporting
critical
infrastructure
of
the
test
also
do
take
a
long
time,
because
we
have
to
work
well
from
just
a
single
node,
two
thousand
five
thousand
nodes.
So
there's
lots
of
testing
that
goes
on,
and
so
getting
all
that
going.
B
A
And
and
another
thing
that
we
can
do
is
just
increase
our
communication
level
and
and
raise
the
awareness,
because,
honestly,
not
many
people
are
spending
their
time
glued
to
test
grid
unless
you're
having
some
sort
of
trouble
sleeping.
No,
it
could
happen
so
yeah
we
communication
is,
is
a
key
strategy
there
for
sure
any
other
questions.
A
A
A
Good,
it
could
be
better
and
part
of
that
again
goes
back
to
process
that
we
we
have
a
little
bit
of
confusion
there
and
the
bot
is
the
de
jure.
You
know
thing
in
this
whole
process.
So
in
a
way
we
can
have
our
human
in
processes.
But
if
the
bot
disagrees,
then
you
know
the
bot
wins.
So
so
that's
certainly
one
area,
just
general
testing
infrastructure
making
down
grade
tests
easier
in
terms
of
scalability
testing
the
ability
to
do
bisex
faster
and
to
figure
out
what
codes
impacts.
Scalability
is
tricky.
A
B
Process
work
that
needs
to
happen
as
well.
We
find
ourselves
sometimes
siloed
into
particular
offices
and
really
expertise
needs
to
follow
the
Sun,
because
project
of
this
size
needs
to
be
able
to
move
all
you
know
24
hours
a
day,
I
think
Aaron
is
slinking
up,
because
I
got
some
thoughts
as
well
pop
up.
C
Yourself,
though,
oh
hi,
Karen,
Karen,
burgers
sake,
testing
steering
committee
I've
served
in
kubernetes
releases
since
b14
sig
beard
as
well
sick
hair.
So
just
on
the
just
on
the
testing
front,
real
quick
one
feature
you
may
not
be
aware
that
test
grade
has
is
the
ability
to
email
an
address
if
a
test
is
has
gone
from
green
to
failing.
So,
if
you
are
part
of
the
sig,
each
sake
should
have
its
own
dashboard
and
that
sake
can
monitor
if
it's
specific
tests
are
passing
or
failing.
C
So
two
SIG's
I
want
to
call
out
as
doing
a
really
awesome
job
would
be
six
storage
and
sig
networking
who
actually
have
like
Signet
working
testing
failures
at
Google,
Groups
comm,
so
a
google
group
that
gets
notified
at
any
time
their
tests
go
from
green
to
red.
So
the
reason
this
works
for
them
is
number
one
they're,
keeping
their
tests
green
and
number
two.
C
It
goes
to
a
group,
not
a
single
individual
when
the
test
fails,
and
so
they
can
do
something
about
this
I'd
love
for
us
to
live
in
a
world
where
we
could
do
the
same
thing
for
the
release.
Master
blocking
or
release
branch
blocking
tests.
Unfortunately,
some
of
those
just
go
from
green
to
red
and
back
and
forth
way
too
quickly,
but
it
could
be
helpful
to
have
some
kind
of
group
of
people
who
are
interested
in
helping
with
triage
to
get
notified
when
those
jobs
flip
back
and
forth.