►
From YouTube: UX Showcase 2020-05-27 —Release::Progressive Delivery
Description
Dimitrie Hoekstra - Progressive Delivery Vs. Continuous Delivery
Slides https://docs.google.com/presentation/d/1VbV-hbIDsia42wbkPinp3Dnu0-dEAvrkvOHw9nZmdxM/edit?usp=sharing
A
A
Today's
presentation
will
be
about
progressive
delivery
versus
continuously
agree
and
I'll
go
into
that
into
a
moment.
Let's
first
check
out
a
little
bit
as
to
where
release
ends
within
the
devops
life
cycle.
As
you
can
see,
after
that,
your
code
has
been
created
and
it
is
verified
and
continues
integration.
A
We
arrive
at
package
afterwards,
that's
released
at
least
kind
of
takes
care
of
that
part
of
the
development
life
cycle
where
it
is
delivered
towards
your
production
and
release
will
do
a
bunch
of
things
in
order
to
improve
that
process
and
to
mitigate
risk.
So
we'll
go
into
that
yeah
in
a
little
bit
to
showcase
the
people
working
within
the
state
troop.
I
have
included
this
section,
which
is
from
the
categories
page.
A
I
invite
you
all
to
to
reach
out
to
people
as
needed
the
product
managers
or
it,
but
there's
a
bunch
of
other
people
that
we're
working
with
in
order
to
create
this
lovely
part
of
the
product.
I
want
to
highlight
four
of
the
categories
that
are
inside
of
the
state
group,
which
is
continuous
delivery,
incremental
rollout
review,
apps
and
feature
flags
and
I'll
go
into
that
a
little
bit
more
detail
in
a
little
bit.
A
So
as
I
have
shifted
and
moved
over
from
like
from
ci
towards
press
delivery,
it
kind
of
made
clear
that
you
know
cicd
has
gone
a
long
way
since,
since
the
start
I've
been
with
gitlab
for
quite
some
time
and
when
I
started
ci
just
entered
the
product
and
it
has
grown
immensely
and
needed
to
re-familiarize
myself
with
its
direction
goals.
As
I
move
over
to
progressive
delivery.
A
So
going
back
to
that
previous
previous
section
of
the
category
space
of
the
progress
delivery
group,
we
can
see
that
one
of
the
categories
is
called
continuous
delivery.
A
While
the
title
of
the
stage
group
is
called
progress,
delivery-
and
I
think,
there's
a
little
bit
of
things
to
explain
there,
so
how
does
this
relate
towards
each
other
right?
So
progressive
delivery
can
be
seen
as
the
upgraded
version
of
continuous
delivery
where
we
previously
went
for
cicd
after
it
was
verified.
We
deliver
it
continuously
to
the
pr
to
the
production.
Server.
A
Progressive
delivery
takes
care
of
that
in
in
terms
of
allowing
for
feature
flags
which
allow
for
immediate,
shut
off
and
shut
on
off
newly
introduced
changes
and
in
that
way,
mitigating
risk,
but
also
it
intends
for
incremental
roll
outs,
and
this
is
a
combination
of
advanced
deployments
and
observability.
A
So,
as
we
have
more
granularity
towards
deployments
deployment
strategies,
we
also
want
to
harvest
that
data
as
to
what
is
going
on
inside
of
that
production
environment.
A
And
lastly,
I
think
this
is
the
most
important
one,
but
I'll
go
into
detail
that
a
little
bit
into
the
next
slide
is
the
ownership
as
to
who
is
going
to
be
able
to
control
what
is
on
and
off
and
what
is
going
into
production,
who
sees
what
etc
so
tldr
allow.
For
pushing
deployments
to
production
with
zero
risk,
I
think
that
is
the
the
most
important
part
there,
and
this
leads
us
into.
Where
do
we
want
to
go?
What
is
the
business
vision?
Where
are
we
now?
A
Where
do
we
want
to
go
so
we
want
to
make
feature
flags
the
default
for
everyone,
and
this
allows
us
in,
as
I
said
before,
to
immediately
instantly
shut
off
and
shoot
on
certain
features.
A
So
if
certain
changes
makes
make
something
unwanted
and
creates
a
blocker
inside
of
the
production
environment,
we
can
easily
shut
that
off
with
rollout
processes,
which
I
would
defer
to
a
later
slide
to.
We
can
further
at
further
granularity
there,
observably
post
the
point,
processing
or
post
deployment
monitoring
is
one
of
the
themes
I'll
go
into
in
which
we're
working
on
in
this
milestone.
A
But
the
most
important
thing
about
this
slide
is
the
change
of
ownership,
so
in
when
you
have
progressive
delivery
set
up
for
your
organization
in
initially
it
will
mostly
be
the
developer
that
will
be
pushing
things
from
production
from
development
to
production.
A
However,
it
is
desired
for
that
to
be
changed
ultimately
to,
for
example,
the
product
manager
who
knows
best
what
they
what
they
want
at
the
beginning.
So
before
they
roll
out
a
certain
change,
they
have
probably
have
a
hypothesis
as
to
how
the
target
audience
is
going
to
react
or
how
the
services
are
going
to
react
if
you're,
for
example,
a
platform
engineer
or
release
manager,
and
based
on
that,
you
might
want
to
roll
back,
and
the
idea
here
is
to
give
those
personas
a
way
to
for
an
implemented
persona
and
a
user
persona.
A
So
how
we're
going
to
roll
towards
production
who's
going
to
make
the
changes
towards
which
features
are
going
to
be
active
on
it
so
going
on
to
the
next
one.
What
is
in
progress
currently
for
progressive
delivery?
We
have
our
q2
goal
issue
and
that's
going
to
focus
on
deploying
to
aws
and
extending
support
for
advanced
deployments,
which
is
part
of
that
incremental
rollout.
A
We
see
that
under
advanced
deployments,
there's
kind
of
like
four
themes
going
on
there's
more
than
that,
but
I
don't
want
to
quickly
highlight
that
so
blue
green
deployments,
it's
an
advanced
strategy
to
allow
for
almost
zero
downtime
between
two
identical
environments
and
shifting
their
traffic
to
from
one
to
the
next
as
we
see
fit,
and
we
have
canary
deployments
instead
of
rerouting
all
the
traffic
towards
the
new
environment,
we
can
show,
let's,
you
know,
get
a
little
bit
of
a
sneak
peek
as
to
how
how
that
happens
or
what
happens
when
we
reroute
a
subpart
of
our
traffic
towards
that
and
traffic
vectoring
kind
of
enables
us
to
reroute
a
specific
part
of
her
traffic
towards
that
which
allows
for
further
granularity.
A
A
We
have
two
similar
solutions,
but
we
want
to
know
which
one
is
best:
let's
set
up
two
similar
environments
and
then
see
based
on
post-deployment
monitoring,
which
one
is
going
to
be
the
the
superior
one,
and
that
leads
us
into
three
themes
for
q2,
which
we're
currently
kind
of
in
progress
with
which
is
aws
deployments,
a
b
testing
and
post
deployment
monitoring
which
I'll
quickly
dive
into
in
the
following
slides,
so
aws
deployments.
A
This
is
generated
because
there's
a
lot
of
buzz
around
aws
cloud
deployments.
We
found
out
that
this
is
currently
very
difficult
to
do.
People
need
to
be
very
technical
in
order
to
come
accomplish
this
and
we
want
to
help
out
from
a
gitlab
perspective
so
to
to
see
what
we
have
found
out
from
the
problem.
Problem
validation
is
that
people
want
to
be.
You
know
wanted
to
be
easier
to
configure
aws.
A
However,
they
don't
want
to
interact
with
the
aws
interface,
if,
if
possible,
so
with
that,
we've
implanted
previously
to
this,
that
we
offer
aws
specific
variables
in
our
variable
settings
section
and
to
improve
upon
this.
Based
on
some
insight
here
that
says,
hey
templates
were
seen
as
helpful
and
we
want
to.
A
We
want
to
further
guide
people
into
deploying
to
the
aws
from
that
interface
we're
offering
additional
in-product
guidance
so
going
into
the
next
one.
We
see
here
that
we're
adding
in
a
section
like
a
call-out
section
in
the
add
variable
modal,
that
if
a
type
aws
type
variable
is
set,
where
allow
the
user
extra
information
to
give
them
easier
access
to
our
documentation
and
also
pre-made
templates,
which
was
one
of
the
insights
coming
out
of
them.
A
So
moving
on
to
post-deployment
monitoring
very
important
for
us
to
be
able
to
react
to
things
inside
of
that
production
environment
after
the
rollout,
there
might
be
something
wrong.
We
want
to
make
one
a
roll
back
and
from
business
goal
we've
set
out
in
terms
of
the
problem,
validation.
There's
a
few
interviews
still
needed
to
be
done,
but
mostly
we're
getting
some
early
insights
already
figured
out.
We
wanted
to
identify
metrics,
usually
define
a
successful
or
unsuccessful
rollout,
which
metrics
should
be
provided.
A
A
So
looking
into
what
has
gone
on
there,
we
have
some
early
findings.
It
seems
that
both
automatic
and
manual
rollback
methods
are
required,
but
some
metrics
will
there.
We
converge,
like
users
converge
to
one
of
the
two
methods
for
some
of
them,
so
there's
there's
some
patterns
that
are
starting
to
sprout
out
there,
as
in
terms
of
showing
alerts,
we're
gonna
show
alerts
in
13.1
in
the
environments
index
page
the
last
inside
you
see
here.
Users
want
to
see
threshold
notifications
on
the
pipeline
itself.
A
If
such
a
threshold
has
been
exceeded
so
moving
on
to
a
b
testing,
this
is
starting
up.
Recruiting
is
to
start
in
week
22,
which
is
two
this
week,
and
if
we
look
at
the
job
to
be
done,
which
is
kind
of
interesting.
A
I
invite
everyone
to
reach
out
into
the
to
the
deck
into
the
document.
There's
source
material
everywhere.
It's
always
nice
if
you
want
to
have
a
little
bit
of
a
deeper
dive.
Lastly,
for
this
slide,
I
want
to
highlight
a
little
bit
of
the
processes
we
have
in
place
for
progressive
delivery.
In
terms
of
you
accept,
which
has
recently
been
added
as
the
ux
department
performance
indicators,
I
have
been
involved
in
making
sure
that
we're
we're
using
this
tool
to
maintain
the
ux
that
can
possibly
decrease
it.
A
I
don't
know
if
everyone
is
making
use
of
them,
but
they're
a
really
nice
tool
to
make
sure
that
we
maintain
the
amount
and
the
triaging
of
bugs,
but
also
now
ux,
that
and
ui
polish
for
ux
depth
and
ui
polish
I've
included
heat
maps
and
dedicated
sections
at
least
for
progressive
delivery
and
contains
integration
and
kind
of
like
making
that
a
little
bit
of
an
experiment
to
see
if
that
helps
us
helping
to
better
aid
pm
into
scheduling
these
kind
of
issues.
A
Aside
from
that
scheduling
goal,
we
have
an
active
goal
to
schedule
at
least
one
ux.
That,
and
one
do
I
polish,
if
possible,
each
milestone
in
that
way
decreasing
and
dwindling
that
amount.
Lastly,
inspired
by
release
management.
We've
shifted
over
towards
the
neat
ux
review,
epic,
to
aid
us
in
planning,
and
I
think
this
it's
kind
of
interesting
how
this
functions
aside
from
the
planning
issues
and
the
engineering
need
weight
issues
which
is
now
being
used
across
multiple
stage
groups.
A
A
There's
a
little
call
out
here:
ux
waiting
can
be
approved
in
gitlab.
I
would
love
to
know
how
others
are
doing
their
ux
waiting.
So
there's
a
little
selector
with
a
pull.
Please
click
through
on
the
slides
and
it
will
end
up
in
the
ux
channel.
You
can
also
find
it
directly
in
the
ux
channel.