►
From YouTube: Hackathon: Intro to GitLab Release Stage
Description
Slidedeck: http://bit.ly/3hNkRUM
A
A
A
I'm
gonna
share
my
screen
so
so
far
we
are
welcome
again
to
the
gitlab
hackathon.
We
are
in
the
beginning
of
the
hackathon.
Let's
say
in
the
first
quarter
of
the
hackathon
we
had
our
kickoff
call
earlier
this
morning
and
then
we
had
an
office
hours
call
running
office
hour
call-
and
this
is
the
third
session
that
we
have
so
far.
We
have
29
merge
requests
submitted,
which
is
great
just
some
some
reminders.
If
it's
the
first
time
you're
contributing
to
gitlab,
you
can
check
out
the
contribute
page.
A
You
can
check
out
the
suggested
issues
for
this
hackathon
and
this
link
there
generally.
Your
source
of
truth
is
the
hackathon
page,
where
you
can
find
all
the
necessary
information,
the
prices
as
well
and
the
schedule
for
all
of
the
sessions
and
with
no
also
in
some
sessions.
You
can
find
related
issues
with
some
issues
and
some
more
information
about
the
specific
projects
so
feel
free
to
check
them
out
by
clicking
on
the
date.
A
You
can
find
your
local
time
as
well
of
each
session,
also
another
reminder
that
it's
really
important
for
everyone
to
respect
the
community
code
of
contact.
We
here
at
gitlab
we
thrive
to
have
to
build
and
have
foster
a
healthy,
inclusive
and
safe
environment.
So
in
case
that
you
notice
some
negative
behaviors,
some
behaviors
that
don't.
A
They're
not
they're
inappropriate,
please
reach
out
to
contact
gitlab.com.
We
keep
and
always
keep
an
eye
on
our
merch
requests
or
communication,
and
also
on
our
kitter
and
speaking
of
guitar.
There
is
the
guitar
channel
setup
for
community
and
gitlab
members
to
ask
questions
to
communicate
collaborate
and
coordinate.
If
you
have
any
specific
questions,
feel
free
to
ping
me
as
well
and
with
or
with
no
further
ado,
I
will
pass
it
over
to
orit
thanks
again
for
being
with
with
us.
Let
me
stop
my
screen
and
I'll
leave
it
to
you.
B
Thank
you,
so
I
hope
that
you
can
see
my
screen
no
great.
So
what
I
wanted
to
do
today
is
first
of
all
introduce
myself.
My
name
is
erica
lewinsky
and
I'm
the
senior
product
manager
of
the
release
stage.
The
release
stage
is
combined
release
management
and
progressive
delivery.
Last
year
we
were
two
groups,
now
we're
a
consolidated
group
and
just
kind
of
walk
through
what
we
have
on
this
stage
and
some
of
the
leading
features
that
we
have
that
we're
working
on
today.
B
So
the
release
stage
is
part
of
the
ops
stage.
If
we
know
our
very
friendly
devops
slide,
the
release
stage
is
right
after
verifying
package,
but
it
also
goes
back.
We
know
that
the
devops
loop
is
an
infinite
loop,
so
after
verify
after
continuous
integration,
we
go
into
release
which
includes
continuous
delivery
and
from
there
we
can
also
go
into
package
configure
monitor,
which
are
part
of
the.
All
of
these
are
the
part
of
the
ops
stage.
B
Who
did
what
and
when,
and
so
it's
easy
to
trace
and
also
giving
users
the
ability
to
control
and
monitor
deployments,
and
you
know
really
make
actionable
insights
and
actions
done
from
those
monitoring
now
capabilities
and
so
specifically
to
release.
These
are
the
categories
that
we
own,
continuous
delivery.
B
B
So,
if
you're
already
using
continuous
integration
with
gitlab,
this
is
the
next
logical
step
just
adding
on
another
job.
That
does
the
deployment
for
you.
We
have
review
apps
for
those
of
you
that
are
not
familiar
with
review
apps,
it's
a
feature
that
allows
you
to
preview
your
changes
based
on
your
feature,
branch,
your
merge
request
and
it
spins
up
a
production
like
environment
that
lets.
B
You
view
what
your,
what
your
changes
will
look
like
in
a
production
like
environment
without
actually
deploying
to
production
and
lets
you
collaborate
with
your
team,
send
this
url
to
people
on
your
team
outside
your
team,
even
to
customers
and
get
feedback
before
it
actually
reaches
production.
So
it's
a
really
great
way
to
collaborate
and
get
feedback.
B
We
have
advanced
deployments,
which
is
a
very
nice
way
to
get
incremental
changes
into
production.
So
advanced
deployments
could
be
blue
green
deployments.
It
can
be
canary
deployments,
incremental,
rollout
and
similar
deployment
methods
that
let
you
deploy
very
small
changes
to
production,
get
feedback
and
then
make
a
conscious
decision,
whether
you're
going
to
continue
rolling
out
your
changes
based
on
the
feedback
that
you're
getting
or
if
you
need
to
scale
down
or
roll
back.
B
The
next
category
that
we
have
is
future
flags
feature.
Flags
is
a
really
nice
way
to
control
features
and
segment
them
to
specific
to
a
specific
audience.
So
not
all
your
users
are
going
to
get
the
specific
feature,
and
what
this
lets
you
do
is
very
similar
to
advanced
deployments,
is
kind
of
develop
a
feature
roll
it
out
to
production,
to
a
very
limited
number
of
users
start
getting
feedback
see.
If
the
feedback
is
good,
then
you
can
increase
exposure
to
additional
users,
and
if
it
wasn't
good,
you
can
just
turn
off
the
flag.
B
Users
will
not
be
able
to
see
it
and
no
harm
done.
Release
orchestration,
it's
a
pretty
large
category.
It
includes
everything
that
someone
needs
in
order
to
create
releases,
whether
it's
the
entire
workflow.
It
could
be
deciding
on
deployment
freezes
deciding
on
release
notes
which,
which
issues
or
epics
or
emerge
requests
are
going
to
be
related
to
specific
releases,
which
binary
artefact.
B
B
So
we
have
lots
of
documentation
around
different
functionality
that
we
really
already
have
in
the
release
stage,
so,
for
example,
auto
deploy,
which
is
one
of
the
stages
in
auto
devops
that
lets
you
automatically
deploy
whether
you're
using
kubernetes
or
deploying
non-kubernetes
to
aws
deploy
freezes,
which
I
shortly
mentioned,
which
allows
you
to
set
specific
dates
and
times
where
deployment
is
not
allowed.
So
the
deployment
will
only
happen
after
so.
A
really
good
example
of
that
is
like
the
holidays,
that
we
just
had
lots
of
companies
don't
want
to
do
deployments
during.
B
B
B
And
if
you
see
that
everything
is
okay,
once
you
started
deploying
to
canary,
you
can
increase
the
exposure
of
more
users
to
more
pods
and
if
something
goes
wrong,
it's
really
easy
to
scale
down
and
go
back
to
your
previous
production
environment.
So
again,
feedback
here
is
key
environment
dashboard.
This
is
something
really
nice
that
we
worked
on
this
year,
which
kind
of
gives
you
an
overview
of
different
environments
that
you
have
throughout
your
projects
and
the
status
that
they're
in
is
something
waiting
for
a
manual
approval.
Is
there
alert
on
something?
B
B
B
So
this
is
kind
of
leaning
on
what
we
discussed
about
on
canary
and
environments.
You
can
see
the
different
environments,
create
and
remove
environments
that
can
this
can
be
production,
staging
development
environments,
but
it
can
also
be
review
app
environments
which
are
short
short-lived
and
also
the
ability
to
see
all
the
different
deployments
that
you
have
in
specific
environment,
and
you
can
even
go
back
and
select
a
specific
deployment
that
you
want
to
roll
back
to
and
just
redeploy
that
and
go
back
to
a
previous
deployment
environment
specific
variables.
B
B
In
the
system,
even
for
example,
your
aws
secrets
or
other
types
of
variables,
that
will
let
you
skip
different
stages
in
the
pipeline
or
others
there's
so
much
over
there
just
read
about
it.
There's
a
lot
to
talk
about
there
run
books.
So
this
is
a
really
interesting
concept
of
release
orchestration,
where
you
have
this
checklist,
that
you
have
to
do
for
every
release
and
so
run
books
lets
you
automate
that
and
create
this
automated
step
of
make
sure
that
you
turned
off
all
your
feature.
Flags
before
releasing
to
production
got
all
your
manual
approvals.
B
So
now
I
want
to
talk
about
a
little
bit
about
specific
things
that
we're
working
on
right
now
and
also
kind
of
ask
for
community
contributions
around
these
areas.
So
the
first
thing
that
I
want
to
talk
about
is
something
that
we
worked
on
for
the
last
few
months,
which
is
streamlining
aws
deployments
and
when
you
think
about
it,
cloud
deployments
is
very
similar.
It
doesn't
really
matter,
you
know
what
your
company
does
or
what
tech
stack
you're
using
they're,
pretty
much.
The
steps
are
very
similar.
B
So
what
we
wanted
to
do
was
make
it
really
easy
and
flexible
to
deploy
to
the
cloud
and
we
we
selected
to
start
with
aws
and
the
way
that
we
did.
This
was
we
kind
of
thought
about
it
as
a
microservice
architecture.
So
what
we
did
was
we
constructed
atomic
docker
images
that
do
very,
very
specific
things,
for
example,
just
connect
to
the
aws
cli,
which
will
allow
you
to
run
any
aws
cli
command
directly
from
your
gitlab
ci
ymo
file.
B
So
that's
an
example
of
one
of
the
docker
images
that
we
provided
and
you
can
use
these
images
and
call
them
from
an
include
directly
from
your
gitlab
ci
yml
file.
These
are
all
stored
in
the
cloud
dash
deploy
project
in
gitlab
to
be
used
from
there
and
if
you
don't
want
to
just
use
docker
images,
we
also
provided
predefined,
full
gitlab
cimo
templates
that
do
the
entire
ci
cd
templates
pipeline,
but
end
up
with
deploying
to
aws.
B
I
put
here
two
different
examples:
one
is
gcp
and
one
is
azure
to
kind
of
help
us
out
with
that
build
docker
images
that
do
connect
to
the
cli
specifically,
so
we
can
use
or
full
templates
and
on
the
right
hand,
side.
You
can
see
what
this
looks
like
in
terms
of
the
aws
variables
we
kind
of
set
predefined
variables
for
aws,
and
then
we
even
help
the
users
find
the
different
templates
that
we
mentioned.
B
B
Effort
that
we
started
working
on
is
called
door
four
door.
Four
are
is
a
common
name
for
specific
metrics
that
you
want
to
use
in
order
to
measure
your
devops
roi.
So
this
is
an
industry
standard
and
there's
really
four
main
metrics
that
we
want
to
collect.
One
of
them
is
deployment
frequency,
which
tells
you
how
often
code
gets
pushed
to
production
lead
time
for
changes
how
long
it
takes
for
a
code
to
be
committed
and
reach
production
with
the
gitlab
definition.
B
We
kind
of
defined
this
as
how
long
it
takes
for
a
merge
request
to
be
merged
time
to
restore
service.
How
long
does
it
take
to
restore
a
service
when
there's
a
service
incident,
so
I
don't
know
if
everyone's
aware,
but
we
also
have
incident
response
issues
supported
in
gitlab,
as
well
as
part
of
the
monitor
stage
and
change.
Failure
rate
is
what
percentage
of
changes
production
results
in
degraded
service.
So
we
can
define
this
as
required
us
to
roll
back
to
previous
release,
as
we
mentioned
in
the
deployments.
B
So
those
are
the
four
different
metrics
and
the
way
that
we
started
working
on
this
was
we
introduced
an
api
that
lets
you
get
the
data
in
the
first
place
and
now
we're
adding
this
to
the
ui
itself.
So,
on
the
right
hand,
side
you
can
see
here
we
have
value
stream
analytics
and
you
can
see
here
the
lead
time.
We
already
have
a
cycle
time
also.
B
The
next
feature
that
we
worked
on-
and
I'm
really
really
excited
about
this,
because
we
just
delivered
in
13.7
the
ability
to
do
auto
rollback
as
part
of
this
epic,
which
is
really
really
powerful,
and
what
this
does
is,
and
we
talk
a
lot
a
lot
about
feedback
and
and
why
it's
important.
So
what
we
wanted
to
do
here
in
opposed
to
planning
monitoring,
is
increased
visibility
of
deployment.
So
what
you
can
see
here
is
the
environment
page
and
what
we
did
was
add
alerts
into
the
environment
page.
B
So
you
can
see
at
any
given
time
if
there's
any
alert
that
needs
attention
on
your
environment
and
and
if
there
is
a
critical
alert
that
requires
attention,
you
can
do
something
about
it.
You
can
either
do
a
rollback,
so
you
can
see
here,
for
example,
I
don't
know
if
you
can
see,
because
it's
pretty
small
but
the
commit
shot
here-
and
here
is
the
same.
B
So
someone
saw
there
was
an
an
error
and
then
they
decided
to
roll
back
to
this
previous
release,
because
this
one
was
giving
problems
and
have
this
critical
alert.
And
so,
if
you
want
to
make
use
of
of
auto
rollback,
for
example,
you
need
to
enable
it
in
the
setting
and
if
there's
a
critical
alert,
it
will
auto
roll
back.
But
there's
so
many
more
features
that
we
have
around
this
functionality
like
manual,
rollbacks
logging
and
so
on.
B
So
a
lot
of
effort
going
towards
this
as
well
advanced
deployments
so
in
the
introduction
to
what
we
do
in
the
release
stage.
I
kind
of
mentioned
advanced
deployments
that
we
support
and
we
currently
support
blue
green
deployments
incremental
rollout
and
canary
at
the
moment.
All
of
these
are
supported
for
kubernetes
and
what
it
looks
like
in
gitlab
is:
if
you
can
see
here
the
environment
page.
This
one
looks
a
little
bit
different
than
our
previous
page,
because
this
one
shows
the
pods.
So
if
you
have
kubernetes,
you
can
actually
see
the
different
rollouts.
B
B
Feature
flags,
so
we
kind
of
talked
a
little
bit
about
what
future
flags
does
our
feature.
Flag
solution
is
built
on
top
of
open
source
unleash
and
again
what
this
allows
you
to
do
is
really
control
your
features,
control
the
audience.
That's
going
to
get
a
new
feature,
even
allow
you
to
work
on
a
feature
before
it's
actually
ready
and
kind
of
hide
it
from
the
user
interface
for
users
that
shouldn't
be
allowed
to
be
exposed
to
it.
Maybe
you
only
want
to
show
it
to
internal
team
members.
B
Maybe
you
have
better
users
that
you
want
to
allow
to
experiment
with
the
feature
and
give
you
feedback
and
that's
already
supported
today.
We
support
different
type
of
strategies
around
feature
flag
usage.
So,
for
example,
we
support
percentage
of
users,
specific
user,
ids
user
lists
and
flexible
rollout
also,
and
what
was
really
exciting,
exciting
about
feature
flags
is
that
in
13.5
we
move
this
capability
to
core.
So
now
everyone
can
enjoy
the
use
of
feature
flags,
and
so
we're
really
excited.
B
We
already
got
two
community
contributions
around
feature
flags
once
it
went
core
with
the
ability
to
connect
web
hooks
that
tell
you,
when
a
feature
is
toggled
on
or
off,
and
we're
also
adding
a
lot
of
ability,
around
contextual
information
and
connecting
feature
flags
to
other
stages,
for
example
connecting
issues
or
merge
requests,
or
even
the
code
to
feature
flags,
and
so
there's
really
really
nice
visibility
of.
What's
going
on
in
your
system
really
cli,
this
is
pretty
neat.
B
So
this
is
really
exciting
effort,
as
well.
Gitlab
pages
is
one
of
our
oldest
and
most
loved
features.
So
again,
this
supports
different
static
websites
that
you
can
connect
to
jekyll
hugo
other
different
static
websites
and
kind
of
spin
up
a
really
fast
static
website
to
be
hosted
in
gitlab
there's.
Quite
a
few
issues
around
that
that
can
are
just
waiting
to
be
picked
up.
B
The
team
actually
has
been
really
really
busy
with
a
huge
infrastructure
change
to
store
pages
in
object
storage
instead
of
the
current
file
system,
nfs
that
it
is
working
in
today,
so
there
hasn't
been
a
lot
of
time
to
work
on
different
small
improvements.
So
if
anything
that
the
community
can
do
here
to
help
our
other
wider
community
members
would
be
greatly
appreciated.
B
B
I
don't
know
if
we,
I
think
we
shared
this
slide
also
on
the
on
the
website,
but
so
there's
a
link
here.
But
if
you
don't
want
to
use
the
link,
you
can
also
filter
by
yourself.
So
we
can
use
the
devops
release.
Label
will
filter
by
the
release
stage
and
we
have
a
convention
for
accepting
merge
requests
for
anything.
A
A
B
Questions
well
in
any
case,
if
anyone
does
have
any
questions
later
on
and
doesn't
want
to
voice
over
right
now.
Please
ping
me
on
any
of
the
issues
I'm
available
or
email
me
at
ogolowinski
gitlab.com,
and
I
will
try
to
answer
everything
as
quickly
as
possible
and
yeah.
I'm
really
excited
about
this.
A
B
What
can
use
what
can
use
what
to
track
operating
systems
release
if
your
product
is
an
operating
system
and
you're
using
gitlab
to
release
it?
Absolutely
if
you're
looking
for
third-party
operating
systems
that
you're
looking
for
updates
there
if
they're
using
gitlab,
absolutely
another
workaround
that
I
think
we
could
do
is
if
you
have
some
kind
of
listener
or
crawler
that
kind
of
looks
through
updates
of
websites
of
an
operating
system
that
you're
specifically
interested
in,
and
you
can
make
some
automation
that
updates,
for
example,
gitlab
pages.
For
that
absolutely.