►
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
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
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
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
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
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
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
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.