►
From YouTube: Progressive Deliver Q4 goals
A
So
I
feel
like
we
have
still
like
two
weeks
if
something
needs
to
be
changed,
and
if
you
have
any
reservations
about
anything
that
we're
going
to
discuss-
and
just
you
know
feel
free
to
stop
me
at
any
point.
Ask
questions
give
me
feedback.
Tell
me
this
is
crazy.
We
can't
do
it
or
you
know
what
about
some
other
issue.
Please
feel
free
to
contribute
and
then
take
part
of
this
of
this
planning,
because
this
is
what
we're
going
to
work
on
in
the
next
three
months.
A
Okay.
So,
as
always,
I
kind
of
separated
this
epic
into
the
different
categories
that
we
have
and
I
tried
to
connect
it
to
an
epic,
but
sometimes
I
kind
of
missed
that
so
I'm
just
going
to
walk
through
it
and
talk
about
the
overall
plan
and
how
this
specific
issue
connects
to
it.
So
the
first
issue
here
is
show
deployment,
status
and
environment
an
environment
page,
and
this
is
actually
part
of
the
136
planning
and
the
idea
here
don't
worry
about
the
mock-up.
A
So
a
really
nice
functionality
is
to
add
the
deployment
onto
the
environment
page
itself,
so
you
can
get
a
big
better
picture
of
what's
going
on
and
I
think
in
discussions.
I
still
need
to
update
this
to
be
the
spanner
instead
of
the
pipeline
view.
But
the
idea
is
to
kind
of
mimic
the
deployment
page
today,
which
you
have
different
statuses
for
a
deployment.
It
can
be
canceled,
it
can
be
failed.
A
A
And
this
is
kind
of
connected
to
our
post
deployment,
monitoring,
epic,
that
we
started
last
quarter.
So
everything
related
to
how
I
see
something
is
going
wrong
with
my
deployment
post-deployment
and
then
I
can
take
action
on
it,
so
I
can
either
redeploy
roll
back
or
decide
to
do
a
hotfix
anyway.
I
just
get
all
this
data
and
I
know
that
something's
wrong
and
I
need
to
do
something
about
it.
A
A
A
A
Lead
time
for
changes
is
how
long
it
takes
for
our
code
commit
to
actually
reach
production
time
to
restore
services
when
there's
kind
of
when
there's
a
service
impairment
or
or
outage,
or
something
how
long
it
takes
to
to
bring
the
service
vaccine
all
and
change
failure
rate
is
once
I
detected
a
big
degradation
in
production.
How
long
does
it
take
it
to
fix
it
so
fix
it
might
be
rollback
or
it
might
be
hot
topics,
and
so
and
so
on?
A
B
A
A
A
Another
thing
that
I'm
super
excited
about
dora
for
is
that
we're
doing
this
is
a
huge
collaboration
between
different
stages
in
gitlab,
so
it
started
with
the
manage
team
and
I'm
going
to
show
you
what
we
already
have
in
place
and
what
we're
going
to
build
off
of
and
and
we're
also
working
very
closely
together
with
the
release
management
team.
On
this,
like
we're
splitting
up
the
metrics
to
be
instrumented
and
also
the
monitor
team
is
involved.
C
A
When
you're
talking
about
an
enterprise
customer
that
wants
to
view
performance
is
usually
over
the
entire
organization
and
not
only
on
a
project
level,
so
that's
one
of
the
mvcs
is
to
get
that
instrumented
that
that
way,
so
I'm
going
to
drill
down
to
the
first
metric,
which
is
deployment
frequency,
and
this
is
a
mockup
of
what
already
exists
today.
I
took
this
out
of
the
product
and
the
managed
team
created
analytics
called
value
stream
analytics.
I
think
they
appear
here
and
in
the
value
stream
analytics.
A
This
is
what
you
see,
so
you
can
see
for
different
stages,
how
many
issues
were
created,
how
many
commits
deploys
and
deployment
frequency
now?
This
is
great
because
we
have
a
beginning
of
the
deployment
frequency,
but
we
have
two
problems
that
we
need
to
fix
with
this
issue.
One.
The
deployment
frequency
here
counts
any
deployment
to
any
environments,
and
we
need
to
focus
on
specifically
on
production,
and
the
second
issue
is
that
this
is
a
numerical
value
and
it
kind
of
it's
hard
to
attract
improvement
over
time
when
it's
numerical
value.
A
A
This
is
a
view
from
a
competitor
from
atlassian
what
it
looks
like,
but
basically
we
want
to
make
a
chart
view
that
shows
deployment
frequency
for
production
for
daily
periods
in
the
past
week
month
and
year
and
for
at
least
for
this
iteration,
it's
not
going
to
be
configurable,
maybe
one
day
we'll
let
the
users
select
the
dates
that
they
want,
but
for
this
iteration
that's
what
we
need.
We
need
to
make
this
in
a
chart
view
and
make
sure
that
it's
related
to
production.
D
A
A
A
A
Okay,
so
I
guess
we
can
also
show
this
before
we
do
a
chart
view.
I
guess
it
really
depends
on
the
weights
that
you
that
the
u.s
engineering
team
come
up
with.
If
this
is
lower
in
weight
or
charts
is
the
same.
I
mean
it's,
it's
definitely
a
valid
discussion,
but
I
guess
we
need.
We
need
to
see
values
over
time.
So,
whichever
way
is
easier
to
implement,
I
guess
is
the
first
iteration.
A
A
I
personally
think
mrs,
are
more
interesting
than
commits,
but
we
could
probably
do
them
both.
So
we
can
definitely
discuss
in
this
issue
itself,
I'm
not
sure
which
one
is
easier
to
to
show,
but
I
think
we
have
the
data
for
both
of
them.
I'm
assuming
that
we
know
how
many
merge
requests
for
each
productions.
A
A
A
So
we're
not
talking
about
group
level
yet
we're
starting
with
project
level,
so
you'll
get
all
the
mrs
are
related
to
specific
project
for
the
net
last
day
month
year,
and
you
can
figure
the
time
at
the
moment
for
this
iteration
and
another
thing
that
we
didn't
discuss
and
I'm
glad
we
have
all
of
you
here,
because
the
design
is
not
exactly
complete,
but
we
can
talk
about
that
as
well.
We
currently
don't
really
know
we're.
Gonna
have
a
specific
page
for
dora
4,
but
it's
not
existing
yet.
So
what?
A
In
the
meantime,
what
I
want
us
to
do
is
to
add
these
metrics
into
our
page
of
where
was
it
analytics
the
icd
and
then,
if
needed
in
the
future,
we'll
just
move
it
over,
but
I
don't
want
to
touch
anything.
That's
not
that
we
don't
own,
since
this
is
a
temporary
location,
so
we're
just
gonna
put
it
in
under
the
cicd
section
that
currently
has
the
number
of
pipelines.
I
think.
D
A
A
I
would
say
early
on
this
year
and
the
problem
with
the
resource
group
is
similar
to
the
problem
that
we
have
for
the
door
for
which
is
it's
a
project
level
lock
and
sometimes
the
deployment
I'm
just
going
to
remind
people
what
a
resource
group
is
really
quickly.
So,
when
we're
talking
about
the
resource
group,
this
means
that
I
probably
have
a
physical
device
that
I'm
deploying
to
and
there's
a
problem
to
deploy
to
the
to
that
device
simultaneously
from
different
from
different,
mrs
and
pipelines
that
are
coming
across.
E
A
A
So
next
etienne,
our
famous
iteration
for
the
path
to
deploying
to
aws
etienne,
worked
on
a
template
to
deploy
tc2
on
13.5,
and
our
next
step
is
connecting
it
to
auto
devops
like
we
did
similar
to
deploying
to
ecs
so
again,
really
exciting
to
open
up
the
auto
devops
deployments
additional
targets.
That
means
I
don't
know
if
amy
is
on
the
line,
but
when
you
clean
up
the
deployment
targets
on
periscope,
don't
remove
the
new
ones.
A
F
A
Not
my
kid,
so
we
had
advanced
deployments
and
in
13.5
we
started
or
have
not
yet
started
working
on
deployment
traffic
weight
via
api.
So
the
idea
here
is
to
allow
easier
scaling
of
environments.
Currently
it's
still
kubernetes,
but
it's
supposed
to
make
it
easier
for
you
to
scale
your
environment.
So
we
started
the
idea
started
with
the
fact
that
we
don't
really
support
blue
green
deployments
out
of
the
box.
A
A
A
What
we,
what
I
tried
to
do
with
an
instrumentation
that
we
started
last
quarter,
was
kind
of
find
the
main
activity
that
we
have
for
each
category
and
see
how
many
users
are
actually
using
it.
So
for
future
flags
we
did
feature
flag,
toggles
and
then
for
a
cd.
We
did
we're
doing
everything
that
has
automatic
deployments,
meaning
no
manual
deployments
and
we
did
deployment
to
aws.
A
D
D
Maybe
not
about
events
deployments,
but
maybe
on
the
other
one
sort
of
rewind
the
table
a
little
bit
to
aws
things.
I
know
we
had
talked
about
like
deploying
to
s3
as
kind
of
like
another
future
step.
Is
that
gonna
be
for
another
quarter
or
where
do
you
see
that
as
like
in
that
list
of
aws
deployment
rolled
out
things.
A
D
A
A
B
A
C
Want
to
ask
one
question:
I
saw
that
a
few
I
think
few
days,
a
few
weeks
ago,
sid
talked
about
like
deployed
to
production
in
five
minutes,
sync,
and
then
he
specifically
mentioned
terraform
and
aws
and
like
a
his
direction,
could
affect
our
direction.
To
you,
like
is
any
upcoming
issue
that
relates
to
his
proposal.
A
A
So
what
we
want
to
do
in
the
future
is
kind
of
decompose
that
let
you
do
whatever
you
want,
you
could
do
kubernetes
with
terraform.
You
can
do
kubernetes
with
helm.
You
can
do
terraform
aws,
you
can
do
a
mixture
of
things,
but
in
order
to
do
that,
we
need
to
decompose
the
auto
devops
template
as
it
is
today.
B
So,
just
to
add
a
few
details
about
that
shinya,
I
just
posted
in
a
chat
an
mr
that
was
merged
and
it
shows
I
there
is
a
graph
that
shows
that
decomposability
that
eric
was
mentioning.
So
instead
of
having
a
review
slash
provision,
production
stage,
we
also
have
like
a
provision,
so
you
can
use
like
in
this.
In
this
case
here
I
used
cloudformation,
but
terraform
could
be
used
instead
of
cloudformation
in
order
to
provision
a
stack,
and
that
is
done
independently
of
any
deployment
tasks
or
jobs.
A
So
that's
kind
of
what
we're
thinking
about
and
I'm
not
sure
exactly
yet
which
team
is
going
to
help
work
on
that.
But
the
idea
is
that
you
can
basically
be
independent
of
anything
and
you
can
pull
in
whatever
you
want,
so
maximum
flexibility,
and
that
way
you
get
exactly
what
sid
was
talking
about,
which
is
terrifying.
You
guys.
C
A
Okay,
so
moving
forward
in
review
apps,
so
we've
been
talking
about
this
for
for
quite
a
while.
I
think
this
is
one
of
the
first
issues
that
I've
been
working
on
since
we've
been
here
slowly
we're
adding
a
bunch
of
more
functionality
around
this,
but
there's
there's
a
problem
when
we
have
many
many
review
app
environments
that
actually
don't
have
any
deployments
to
them
and
we
want
to
get
rid
of
them.
A
So
looking
for
the
the
parents,
here's
the
parent
that
this
was
broken
off
from
so
today
the
doc's
team
personally
had
like
a
thousands
of
review
apps
with
none,
no
deployments
that
are
just
sitting
there
and
need
to
be
deleted
and
there's
no
way
to
do
that.
So
the
first
thing
that
we
introduced
a
while
back
was
auto.
Stop.
I
think
that
was
in
12.8.
A
We
introduced
the
auto,
stop
keyword,
and
that
meant
that
when
you
have
a
deployment
to
some
environment,
it
will
auto
stop
in
whatever
time
you
define,
but
that
still
didn't
solve
the
problem
for
environments
that
had
no
deployment.
So
shenya
opened
this
issue
a
few
months
ago,
to
kind
of,
I
wouldn't
say,
complete,
but
more
complete
the
solution
by
adding
this,
this
keyword
of
stop-in
also
to
the
to
the
creation
of
the
environment.
So
when
an
environment
is
created,
there's
a
timer
that
will
set
that
set
that
checks
when
it
needs
to
be
torn.
F
A
A
Cool
and
this
one
I'm
actually
going
to
open
this
up
for
discussion,
because
I'm
in
the
dilemma
whether
to
leave
it
or
not.
So
when
I
added
this
issue,
it
seemed
to
be
prudent
that
we
create
this
new
protected
strategy
concept,
and
we
talked
this
quite
about
this
quite
a
lot
in
our
future
flag,
weekly
meetings
and
the
idea
is
that
sometimes
you
want
to
create
strategies,
but
you
want
to
make
sure
that
it
does
not
affect
production.
It's
on
every
other
environment,
but
not
production,
and
things
like
that.
E
A
E
A
This
is
super
crucial
and
the
thing
is
that
they
have
like
specific
people
that
are
allowed
to
deploy
to
production,
and
they
have
developers
and
developers
should
be
able
to.
You
know
view
their
future
flights
on
any
environment,
but
they
don't
want
them
to
touch
the
production
so
having
that
split
would
kind
of
solve
that
problem.
E
D
D
You
know
and
spend
more
time
providing
a
very
stable
service
for
customers.
Great
question
on
this
one
specifically
about
protected
feature
about
the
feature
flags
being
having
some
limited.
What's
the
word
like
availability
for
a
user
to
configure
is
there
is
that
on
environments
or
is
it
on
users,
or
is
it
like
the
intersection
of
the
of
those
two
things.
A
D
E
F
F
F
E
F
Yeah
interesting
was
the
was
the
rough
there.
Was
this
rough
idea
about
using
something
similar
to
code
owners
right
so
feature
flags
owners,
maybe
parsing
a
yaml
with
a
name
and
that
environment
it's
easier
than
building
a
full
ui
for
this
right
as
a
first
as
a
first
as
a
first
iteration,
and
it's
for
I
don't
know
to
frame
like
in
it's
for
professionals.
Okay,
you
need
to
tweak
the
yaml,
but
I
guess
this
is
our
our
persona
so
to
say
this
in
this
case
right,
so
somebody
that
will
configure
all
this.
E
D
F
This
helps,
I
think
this
helps
with
I
don't
know
to
say
in
english,
but
like
it's,
it's
a
built-in
logs
log
system.
Also
right,
so
you
know
who
changed
the
you
know
changed
the
yaml,
not
not
not
as
a
blame
as
a
blame
device,
just
okay,
somebody
merged
that
change,
and
there
there
must
be
a
reason
for
that.
So
you
can
reach
out
to
the
person,
I'm
not
sure
with
ui.
F
If
git
labs
already
works
like
this,
if
we
make
the
ui
and
then
we
change
the
permissions
by
a
ui,
we
also
need
to
log
who
did
that
and
so
on
and
so
forth
for
it.
So
it's
I
don't
know
right.
It's
a
fair
concern
that
everybody
can
commit.
It's
true
that
everybody
can
commit
to
the
yaml,
but
still
it
has
to
pass
a
nurture
quest
gate,
at
least
usually.
D
A
A
Hanging
there
and
not
exactly
the
feature
flag
plan
at
the
moment
is
not
exactly
sure
due
to
all
our
conversations
from
the
past
few
weeks,
so
I
feel
like
we
need
to
do
one
substantial
feature,
flag
thing
in
this
milestone,
so
it
may
be.
This
protected
feature
flag,
one
which
I
think
will
go
a
really
long
way
or
it
may
be
all
the
scalability
issues
that
we're
talking
about,
because
sooner
or
later,
we're
gonna
need
to
deal
with
that
as
well.
A
So
in
the
beginning
of
the
year
our
leadership
decided
to
open
source
the
majority
of
our
features,
which
included,
feature
flags
which
we
have
just
completed
canary
and
the
boy
boards,
and
I
asked
for
help
with
canary
and
deploy
boards
from
other
teams
and
I'm
still
crossing
my
fingers
for
the
ploy
boards,
but
canary
kind
of
came
back
to
that.
So
I'm
not
going
to
commit
to
it.
But
if
we
have
time
I
would
love
for
us
to
do
this,
as
we
have
made
a
commitment
to
customers
that
we
will
do
this.
A
A
Nothing
in
the
beginning,
when
I
saw
the
amount
of
speakers
that
that
they
wrote,
I
had
asked
specifically
scott
and
he
said
like
it's,
not
a
commitment,
but
it's
like
we
should
try
to
do
our
best
to
gets
done.
So
if
it
splits,
if
it
spills.
This
will
be
something
we'll
do
in
january,
but
if
we
could
do
it
sooner
than.