►
From YouTube: Release Evidence JTBDs & Roadmap
A
A
So
when
we
look
at
the
purpose
of
release,
evidence
is
for
a
tag
that's
been
created
in
gitlab
to
be
compared
and
to
see
the
changes
that
have
been
produced
with
code
and
with
issues
and
to
create
that
chain
of
custody
for
that
production.
State.
Okay,
some
of
the
jobs
to
be
done
that
people
are
trying
to
accomplish
inside
of
git
lab
that
are
centered
around
release.
Evidence
are
focused
on.
A
How
do
I
avoid
disrupting
a
developer
when
I
need
to
create
an
artifact
of
the
version
that
we
released
three
four
months
ago?
So
if
I
wanted
to
produce
an
artifact
of
changes
like
these,
are
the
test
results,
the
mrs
that
were
bundled
into
this
release
version,
because
an
auditor
is
like,
I
need
to
show
that
you've
been
documenting
changes
over
time
and
that
those
changes
are
valid.
A
You
would,
as
a
manager,
compliance
manager
don't
want
to
go
peeing
a
developer
to
be
like
hey.
Can
you
give
me
a
query
of
all
the
changes
that
we've
made
to
our
production
state
three
months
ago
and
compare
it
for
me
for
this
state?
So
that's
the
usability
perspective
of
it
any
questions
on
like
the
purpose,
the
history
of
what
we're
doing
with
it.
B
B
Have
like
sha
has
some
of
the
like
basically
code
tree
in
the
evidence,
which
can
sounds
like
usable
for
the
thing
you
just
described
and
also
maybe
yeah.
Maybe
some
kind
of
a
commit
lock
also
could
be
usable
there,
but
yeah
also.
Actually,
if
you
can
like
add
some
examples
of,
I
know
you
had
a
few
meetings
with
clients
about
evidence
so
like
what
exactly
they
are
trying
to
do
like
some.
B
A
Yeah,
so
a
government
agency
wants
to
be
able
to
do
pre-audits
before
an
auditor
comes
in
so
they'll
take
a
sampling
of
these
json
files
and
they
will
create
a
query
around
it
to
say
that
our
version
is
compliant
for
policies
that
we've
set.
So,
for
example,
we
only
do
monthly
releases,
so
we
want
evidence
to
suggest
that
we're
only
releasing
every
month
and
we're
not
doing
any
patches
beyond
that.
There's
other
questions
that
they're
wanting
to
answer
as
well.
A
So,
for
example,
they
may
be
using
a
merge
request
in
gitlab
to
make
a
change
to
a
mirrored
repository
and
that
change
they
want
to
mark
as
like.
Okay,
this
change
was
made
through
this,
mr.
This
change
was
committed
to
a
mere
repository
in
gitlab
and
github
and
we're
showing
that
evidence
trail
through
the
release.
Evidence
artifacts,
that's
a
very
merge
request,
focused
view
on
that
particular
release
tag.
B
So
it's
kind
of
like.
If
I
guess
you
right,
you
saying
that's
basically,
the
whole
feature
about
merge
requests
included
in
the
evidence
is
born
from
this
year's
case
right.
Yes,
exactly
one
like
question
here
is
that
it
doesn't
actually
guarantees
that
we,
like
the
developer,
didn't
bypass
the
request
and
just
didn't
commit
to
master,
because
yeah.
A
And
that's
kind
of
where
we're
also
like
from
an
auditor
perspective.
They
just
want
to
know
that
you're
enforcing
policies
that
you've
set,
so
there
may
be
rules
that
each
organization
puts
in
place
from
the
mr
like
requires
two
approvals
or
you
need
to
have
an
external
non-code.
Reviewer
approve
your
merge
request.
A
That
kind
of
detail
is
something
that
we
would
want
to
contin
to
consider
expanding
inside
of
release.
Evidence
so
like
when
the
compliance
side
of
the
house
allows
you
to
instrument
compliance
policies
in
gitlab.
We'd
want
to
find
a
way
to
capture
that
information,
because
that
would
answer
the
question
that
you
just
said
like.
B
A
Yes,
so
there's
two
use
cases
where,
like
yeah,
you
can
set
up
your
approvers
to
not
be
in
your
same
project
and
that's
how
you
accomplish
separation
of
duties,
but
there's
some
more
like
extreme
cases
which
are
the
recently.
You
broke
up
two
issues
about
creating
like
a
deployer
role
that
doesn't
have
access
to
the
code.
That
is
like
a
very
popular
use
case,
I'm
hearing
in
public
sector,
where
they
want
people
who
have
no
access
to
the
code
to
be
the
ones
deploying
yeah,
and
we
want
to
suck
that
information
into
the
release.
B
A
So
when
they
look
at
like
a
distributed
center,
that's
really
hard
to
maintain,
like
you'd,
have
20
000
projects,
then
to
maintain
deployment
separation
of
duties
and
then
there's
like
the
question
of
how
do
you
manage
like
upstream
changes
of
like
forked
projects,
if
you're
doing
like
an
open
source,
distribution
and
managing
like
you'd
have
to
have
a
third
project
of
people
managing
that
forked
repository
and
managing
upstream
changes?
So
there
was
a
couple
of
like
complexities
at
scale
that
gitlab
doesn't
really
get
one's
great
for
mono
repos.
A
B
I
don't
know
I
mean
we
like.
If
we
speak
about
the
permissions,
then
like
we
don't
have
a
very
granule
permissions
and
from
other
reapers
you
probably
have
like
thousands
of
developers,
and
you
have
you
want
to
much
more
granular
permissions
and
also
like
I'm
not
sure
of
git
in
general,
is
a
good
thing
for
mandarin.
So
yeah.
A
A
B
A
Next,
we
need
to
think
about
approvers
and
including
that
information
inside
of
the
release
evidence
so
that
we
can
complete
the
workflow
of
who
who
made
this
change
and
who
approved
change
and
then
the
last
future
perspective
is
allowing
people
to
compare
inside
of
gitlab
natively.
So
what
are
the
changes
between
each
version
tag
and
the
release
evidence
and
also
set
up
workflows
or
rules
that
approvers
and
mergers
need
to
be
different
roles
based
off
of
the
compliance
policy?.
B
A
That's
what
we're
hoping
is
that
this
is
the
opportunity
for
people
to
then
furnish
and
easily
easily
extracted
record
right.
So
what
the
compliance
team
wants
to
do
is
take
those
json
files
and
aggregate
them
into
an
audit
report
that
a
customer
can
export
from
gitlab.
So
they'll
consume
these
json
files
upstream
into
the
compliance
stage.
B
Okay,
okay,
I
see
yeah
that
actually
clarifies
a
lot
in
my
head
because,
like
to
be
honest
from
my
perspective,
it
looked
like
yeah.
There
are
people
like
there
are
a
couple
of
people
who
think
that
it
might
be
useful,
but
I
like
there
was
actually
a
huge
gap
between
like
understanding
my
understanding,
how
it
will
be
used
and
actually
the
user's
needs
because
yeah
I
I
didn't,
have
that
feeling
yeah
so.
A
B
A
That
people
are
looking
to
use
it
too,
are
like
take
the
json
files
and
extract
them
into
grafana
and
model
like
visualize.
The
changes
of
you
know
test
results
and
the
percentage
of
mrs
that
had
related,
artifacts
or
pipelines
that
had
related
artifacts
and
collect
some
of
those
like
metadata
piece
as
indicators
of
like
what
are
most
common
changes
in
their
released
version
text.
A
B
A
B
B
B
A
A
B
B
A
B
A
So
one
of
the
one
of
the
validation
cycles
that
hayan-
and
I
did
we
interviewed
like
20
or
so
different
customers
on
their
release,
tag
usage
and
one
of
the
one
of
the
customers
mentioned
that
they're,
creating
release
tags
they're,
not
using
ci
or
cd
and
gitlab,
but
they're.
Creating
a
release,
tag
with
the
api
and
they're,
adding
like
a
link
to
their
source
code
in
that
release
tag
as
a
representation
of
their
current
state.
A
And
I
guess
we
didn't
dig
too
deep
into
it,
because
we
don't
see
a
lot
of
people
using
scm
and
consuming
release
tags.
But
that
was
a
really
odd
use
case
of
people
trying
to
create
representations
of
their
code
with
version
tags
rather
than
like
actual
like
actual
snapshots.
And
for
me,
like
in
the
goal
of
release,
evidence
is
to
be
a
tangible
snapshot
of
where
you're
of
the
way
your
code
is,
which
is
different
than
like
just
a
representation
of
what
we
have,
which.
B
A
B
A
B
A
A
B
A
B
B
B
A
B
B
Yeah,
and
only
showing
like
a
super
small
snapshot
for
the
other
people
and
so
like
not
even
showing
evidence
sha
there
so
like
it
will
be
like
promotional
stuff
that
hey
we
have
this,
but
to
actually
get
an
access
to
it.
You
needn't
you
need
to
be
an
auditor
or
maybe
a
maintainer
of
the
project,
or
something
like
that.
So.
A
A
So
if
we
can
allow
like
the
appendment
of
a
auditor
role
to
a
maintainer
and
then
a
standalone
auditor,
like
maybe
that's
like
a
like
it's
a
permission
add-on
rather
than
like
a
standalone
thing,
that
might
be
a
useful
way
to
apply
it
for
here,
but
the
nbc
was
yeah
release.
Evidence
will
no
longer
be
a
developer
and
maintainer
access
perspective.
It'll
just
be
an
auditor
yeah.
B
A
B
B
A
I
have
this
document
floating
around,
that's
like
the
specific
jobs
to
be
done
and
the
related
issues
for
it
I'll
send
it
over
to
you
about
release
evidence,
but,
like
the
way
I
see
it
is
we
would
harden
and
fix,
detect
it
and
then
expand
any
functionality
like
include
you
know,
security
scans
or
whatever,
like
as
we
get
people
using
it
more,
but
I
think
that
this
is
really
important,
that
we
make
it
usable
for
people
who
aren't
using
milestones.
That
seems
to
be
like
a
priority
that
we
might
want
to
tackle.
B
A
A
B
B
A
Well,
actually,
this
was
super
helpful
for
me
because,
from
your
perspective,
like
get,
history
would
be
more
usable,
and
I
think
you
were
getting
at
one
of
the
nuances
that
I'm
concerned
about
with
the
adoption
of
the
future
for
people
who
aren't
using
plan.
So
this
was
super
helpful
because
it
opened
up
like
another
opportunity
to
think
about
commits
as
a
something
that
we
can
suck
in
here,
rather
than
it
being
just
these
arbitrarily
loosely
connected
milestones
right.
A
That's
super
good,
okay,
awesome!
Thank
you
vlad!
So
much.
Let
me
know
if
you
need
anything,
I'm
probably
gonna
rename
our
pages
sync
to
be
just
a
release,
sync
for
you
and
I
like
just
make
it
a
one-on-one
bi-weekly,
and
then
we
can
just
dive
into
any
other.
Like
roadmap
questions,
just
work
you
have
in
progress
and
roadmap
stuff.
So
we'll
just.