►
From YouTube: Release - DORA4 discussion
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
I'm
going
to
jump
back
to
the
point
where
we
stopped,
we
kind
of
explained
what
the
why
we're
doing
this,
and
for
who
are
we
doing
this?
Okay
so
now
to
be
more
practical
in
terms
of
what
we're
starting,
there's.
There's
two
things
that
we're
doing
so.
A
One
approach
that
we're
kind
of
looking
at
is
that
implementing
these,
these
specific
metrics
to
show
them
to
our
end
users
and
there's
two
ways
that
we
can
do
that
one
is
through
api
and
the
other
one
is
through
ui,
and
the
second
approach
is
at
what
level
do
we
want
to
show
this?
So
we
talked
about
the
persona
at
the
team
level
and
we
talked
about
the
person
at
the
executive
level.
Now
the
more
primary
persona
is
the
executive
level.
A
So
the
executive
level
wants
to
see
these
metrics
across
the
entire
organization
and
I'm
a
team
level,
so
they're
really
interested
in
looking
at
an
instance-wide
level,
or
if
this
is
a
company
that
is
using
the
sas
version
of
git
lab,
they
want
to
see
all
their
groups
together
and
they
want
to
see
all
those
metrics
at
a
group
level.
A
Okay,
so
the
two
different
approaches
that
we
kind
of
went
in
parallel
was
figuring
out
how
we
can
show
this
on
a
group,
slash
instance,
level
and
in
parallel,
actually
getting
the
metrics
instrumented.
Okay.
So
the
way
that
we've
talked
a
little
bit
about
in
the
issues-
and
I
I
don't
recall
the
exact
issue,
but
I
think
sean
and
I
had
talked
about
it-
was
going
actually
bottom
up.
A
So
we
start
from
the
project
level,
which
is
valuable
in
itself,
because
it's
still
addressing
the
secondary
persona,
which
is
the
development
team
leader,
but
it
still
has
value
so
showing
it
on
the
project
level
and
we
kind
of
have
some
of
these
metrics
already
in
place.
So
we
we
can
reuse
them
and
we
don't
need
to
reinvent
the
wheel
and
then
aggregating
the
data
so
aggregating
it
up
to
the
group
level
and
then
aggregating
it
up
to
the
instance
level.
A
So
I
hope
that
kind
of
vladimir
answers
your
question
of
the
order
of
things.
So
in
this
specific
issue
that
I
linked
in
the
document,
can
you
still
see
my
screen.
B
A
Yeah,
okay,
so
this
is
the
first
issue
that
progressive
delivery
was
going
to
kind
of
work
on
and
that's
presenting
deployment
frequency
in
the
ci
cd
dashboard.
So
this
is
not
going
to
be
the
final
location
of
dora
4
metrics.
A
Why
can't
I
see
things
here?
I
don't
know,
but
let's
just
go
to
a
temporary
project
that
I
have
let's
say
this
one
and
then
so
the
idea
was
to
go
undersea
ice.
Sorry
under
analytics
sorry
analytics
say:
yes,
thank
you.
Whoever
is,
I
thought,
dimitri,
so
just
use
this
section
and
add
the
charts
there
in
the
meantime
and
then
we'll
just
lift
and
shift
them
once
once
they're
ready
to
to
move
to
a
new
location.
A
B
B
Okay,
okay,
because
what
I
tried
to
document
in
the
in
the
notes
is
that
there's
a
couple
of
different
pieces,
so
one
is
the
presentation
of
the
optometrics
and,
as
you
mentioned
from
the
outset,
that
could
even
just
be
an
api
to
start
with,
or
it
could
be
an
api
that
gets
consumed
by
some
front
end
and
then
there's
two
other
kind
of
I
feel
there's
two
other
components.
B
One
is
the
actual
capturing
and
instrumentation
of
of
this
data,
and
when
I
look
at
the
four
metrics,
the
first
one
looks
pretty
easy
to
work
out
where
that
comes
from,
but
the
other
three
all
look
a
bit
vague
to
me
as
to
how
we
would
actually
capture
them
and
then-
and
so
then
the
other
question
mark
is:
do
we
create
some
type
of
store
inside
of
git
lab
to
to
store
this
stuff
keeping
in
mind?
It's
essentially
kind
of
time
series
data,
so
it
could
grow
quite
big
or
or
do
we?
B
So
I
think
to
to
me
that
that's
kind
of
the
biggest
question
well,
the
two
biggest
questions
are:
you
know
where
we're
going
to
put
it,
but,
more
importantly,
how
do
we
actually
calculate
like
numbers,
two
for
free
and
fall.
A
C
C
We
should
start
with
the
same
thing
and
if
we
ever
encounter
any
performance
problem,
we
can
add
cache
or
we
can
add
persistent
storage,
but
we
can
figure
out
later
this
kind
of
things,
and
I
I
would
go
with
the
same
approach
for
all
other
metrics.
So
I
wouldn't
care
about
storing
this.
For
now
until
we
actually
hit
the
performance
problem
when
we
couldn't
calculate
this
from
the
flag.
A
Okay,
so
all
fair
questions,
and
and
let's
let's
talk
about
them
a
little
bit
so
specifically
for
deployment
frequency.
This
data
actually
is
already
being
collected.
Okay
yeah
in
the
in
the
notes
here
somewhere.
A
A
Let
me
just
search
okay,
so
this
already
exists
in
the
product.
Okay,
this
data
that
shows
number
of
issues
number
commits
number
deploys
number
of
deployment
frequency
for
the
last
30
days.
This
already
is
being
collected.
I'm
sorry
that
I
clicked
here's
something
that
I
shouldn't
have.
If
I
want
to
go
back
to
my
project
specifically
and
you'll,
see
that
this
is
under
value
stream
analytics.
A
Okay,
so
we
don't
need
to
reinvent
the
wheel
here:
okay
right,
having
said
that,
there
is
a
little
bit
of
a
problem
with
the
way
that
it's
being
collected
here,
because
it's
counting
all
of
the
deployments
and
not
only
the
deployments,
to
specifically
for
production
environment
but
we'll
handle
that
somewhere
along
the
line,
assuming
that
this
is
a
okay
we're
just
going
to
take
the
same
number.
C
A
Okay,
now
we
already
have
the
number
of
commits
okay.
So
that's
another
thing
in
I
want
to
go
back
to
the
epic
I
am
in
the
epic.
Now
I'm
gonna
stop
epic.
A
How
do
I
go
to
this
parent
here
so
under
the
door
for
epic
there's
a
bunch
of
different
issues
that
jackie
and
I
had
created
now
I
will.
I
do
want
to
go
through
each
one
of
the
different
measures
in
the
way
that
we
were
thinking
of
it
and
then
I'll.
I
hope,
that'll
answer
your
question
sean.
So
thank.
A
A
Is
how
long
something
that
I
committed
reaches
production?
So
I
was
thinking
about
this
in
two
parallel
ways.
A
A
B
A
B
C
I
think
it's
yeah,
I
mean
commits
kind
of
I
would
say
even
irrelevant
here,
because
they
like
it's
just
the
number
of
commits
in
the
repository.
It
doesn't
mean
that
we
have
that
number
of
commits
in
production
and
yeah.
It
can
be
some
kind
of
user
branch
or
whatever,
and
another
point
is
that
I'm
not
sure
how
easy
it
will
be
to
calculate
this
metric.
For
example,
we
have
an
open
time
on
mr,
but
it
can
result
in
different
things.
C
When
we
merge
them
all
right,
it
can
be
merged,
commit
it
can
be
rebase
yeah,
so
it
it
will
build
some
completely
different,
commit
on
the
master
branch,
and
then
deployment
can
happen
like
a
week
after
that,
and
basically
basically
it
should
be
like
the
first
deployment
which
had
this
commit
deployed.
C
C
A
Do
know
that,
like
a
few
milestones
ago,
maybe
twelve
five
or
six-
we
had
added
support
for
deployment
time
to
production
on
the
merge
request,
widget
itself,
so
we
may
be
able
to
use
that
data
as
well.
In
order
to
calculate
this,
this
was
something
that
I
think
york
contributed.
So
we
do
have
that
kind
of
data,
so
we
do
know
when
it
hit
production.
So
maybe
we
can
figure
out.
According
to
that.
C
B
And
so
this
is
something
we
would
calculate
on
the
flyer.
It
seems
like
right.
We
at
this
point.
We
don't
I
mean
unless
there's
performance
issues
we
we
don't
really.
C
If
we
already
have
this
couple
of
timestamps,
then
yeah
we
can
calculate
it
on
the
fly.
It
might
not
be
super
performant,
but
as
a
nvc
I
guess
it
will
work.
B
A
Yeah
so
the
way
that
we
I
was
thinking
of
the
mvc,
but
I'm
definitely
open
for
changes
if,
if
needed
was
that
you
could
select
the
last
week
month
or
or
year,
but
if
that's
a
problem,
we
can
always
have
this
data
not
real
time.
So
that's
definitely
an
option.
D
Can
we
take
a
couple
of
step
backs
here
because
we
are
talking
now
about
ui
and
the
dashboard
and
everything
between
and
one
of
the
things
that
we
validated
in
release
management
that
customers
were
not
going
to
use
dashboards
like
at
this
point
is
that
the
linux
mvc
was
to
make
everything
like
durametrics
available
in
the
api,
and
I
kind
of
just
want
to
touch
base
on
your
point
audits.
D
So
I
would
suggest,
as
we're
still
figuring
out,
how
to
yeah
fetch
these
metrics
and
how
to
make
it
work
with
the
back
end
is
to
really
focus
on
the
api
part,
because
the
ui
itself
like
exposing
this
it's
something
that
we
can
work
on
and
validate
in
parallel
with
with
the
customers
I
already
put
together.
I
actually
linked
here
three
four
issues
with
some
prototypes
that
I
already
worked
on
in
release
management
and
then
we
validated
and
the
nbc
is
really
like.
Here's
a
metric,
here's
the
static
like
percentage.
D
You
know
whatever
lean
blah
blah
lead
time
on
whatever
and
not
worry
so
much
now,
with
the
nitty-gritty
on
yeah,
sorting
or
showing,
and
even
the
graphs
I
wouldn't
go
in
there.
A
At
all,
at
the
moment,
like
that's
the
end,
the
end
goal
is
that
you
can.
We
would
start
with
instance,
level
and
you
can
pretty
much
filter
by
whatever
you
want
by
a
team
by
a
date,
yeah.
A
So
I
was,
we
were
thinking
had
created
a
mock-up,
for
this
was
to
make
a
very
minimal
ui.
Where
you
could.
You
have
like
the
three
graphs
in
front
of
you,
the
you
know
you
can't
choose.
You
have
like
a
month
a
year
whatever
and
you
can
flip
between
the
pipeline
view
or
the
door
for,
and
you
can
like
just
get
everything
in
one
page
and
not
make
it
very,
very
sophisticated
for
the
moment.
D
Yeah,
can
you
go
to
the
issue
description
and
just
kind
of
open
this?
These
issues
here
yeah
this
here
that
I
have
highlighted
in
the
yeah
these
three,
because
we
initially
well
now
it
doesn't
matter
anymore,
but
we
initially,
we
split
right.
The
two
metrics
that
release
management
will
do
and
then
the
progress
delivery
will
do,
and
I'm
already
done
with
this
is
what
schedule
13.7
already
done
with
the
proposals
for
the
mvc
and
yeah.
We
want
to
build
the
features
at
the
analytics
group
level,
not
project.
D
E
Years
as
far
as
I
understood
them
discussed
with
or
it,
the
idea
was
to
keep
it
in
ci
cd
analytics
page
under
the
project
view,
as
that
is
under
our
full
control.
I
would
suggest
in
this
case,
because
there's,
I
would
say,
proposals
for
on
the
group
level.
There's
proposals
on
the
project
level.
I
see
a
clear
progression
there
where
we
can
implement
project
level
first,
as
that
is
also
done
after
which
we
can
move
in
towards
the
direction
of
your
proposal
on
the
group
level
and
kind
of
you
know
at
a
level.
D
What
do
you
mean
full
control
because
yeah,
it's
not
like
we
own
the
the
analytics,
the
icd,
it's
it's
shared
with
the
analytics
team.
What
do
you
mean
for
control
with
it.
A
A
Yeah
cicd,
the
only
thing
that
we
show
there
is
the
pipeline
view
under
when
we
say
our
control,
it's
the
apps
group,
but
so
it's
not
analytics.
It's
actually
things
that
we
we
can
populate
there
and
actually
jackie
was
aligned
with
this.
So,
like
I'm
surprised,
I
mean
we
said
we
would
start
with
a
project
level
here
and
that
it
would
move
out
like
this
is
something
that
jackie
and
I
had
discussed
before.
A
So
I
understand
any
concern
if
we're
like
planning
two
totally
different
things-
and
I
know
that
jackie
wanted
to
kind
of
overcome
the
instance
level,
because
that's
you
know
what
people
really
want
to
buy
at
the
end
of
the
day,
but
I
think
it's
again:
okay
to
start
with
project
and
aggregate,
as
dimitri
said,
and
I
think
there
was
an
issue
where
sean
asked
that
as
well
and
jackie
also
gave
a
thumbs
up
so
we're.
That
was
the
plan
at
the
moment.
Like
start
at
the
project
level
and
aggregate
the
data.
D
Yeah
yeah,
I
got
it
so
I'm
just
in
a
way
thinking
about
like
not
managing
but
solving
the
the
problem
for
our
customers
at
the
from
an
application
standpoint,
because
right
now,
yeah
moving
building
it
at
the
the
project
levels
of
a
problem
for
the
project
right,
you're,
still
not
gonna,
give
the
directors
or
the
the
high-level
persona
an
overview
and
that's
the
problem
that
we
wanted
to
solve
when
bringing
things
to
the
analytics
group
level.
So
you
feed
everything.
Yeah.
A
Absolutely
it's
two
different
personas
totally
yeah,
which
was
how
we
started.
We
have
like
one
minute
left,
so
I'm
gonna
really
try
to
rush
this
last
sentence.
We
have
two
more
metrics
and
I
have
issues
for
them
on
the
linked
here
on
the
epic.
A
A
Okay
and
the
last
one
I
get
confused
between
the
three
and
four
solar
you
may
need
to
swap
my
definitions
and
the
last
one
was
to
count
how
long
it
took
to
for
to
do
either
a
rollback
or
a
redeploy
of
an
environment
is
the
definition
of
how
we
calculate
that.
A
B
A
Yeah
but
please
feel
free
to
schedule
another
single
meeting.
If
we
want
to
hash
out
more
details,
I'm
I'm
super
excited
about
the
store
for
that
we're.
I
think
it's
going
to
have
a
lot
of
value
both
to
the
stage
into
the
and
to
get
lab
as
a
company
and
to
our
users
so
feel
free
to
you
know,
schedule
time
on
my
calendar,
so
we
can
continue
discussing.