►
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
I
don't
know
it's
kind
of
a
side
questions
like.
Is
there
any
tool
we're
trying
to
replace
with
this.
B
Yeah,
okay,
yeah,
I
don't
know
I
have
some
like
super
detailed
questions
like
go.
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
Yeah,
so
here's
one
of
the
challenges
finra,
for
example,
they
have
over
10
000
projects.
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
A
step
back
for
release
evidence
right
now:
we've
we're
adding
stuff
to
it
to
make
it
a
richer
data
asset
and,
from
my
perspective,
our
next
pers.
Our
next,
like
big
step,
is
to
start
to
think
about
the
merge
requests
and
the
approvers
and
getting
that
detail
into
the
release.
A
Evidence
and
those
are
the
two
main
feature
sets
that
will
bring
it
to
a
more
viable
state,
because
then
people
can
actually
see
that
chain
of
custody
that
like
this
is
the
change
that
was
made
to
this
release
tag,
and
this
is
who
approved
that
change,
and
then
who
made
that
change,
and
what
we'll
do
with
that
asset
potentially
in
the
future,
is
set
like
rules
saying
hey,
this
release
tag
actually
has
the
same
approver
and
merger,
or
same
approver
and
deployer
and
like
three-year
vision,
you
know
super
far
out.
B
A
I
haven't
seen
a
lot
that
I
have
the
same
problem:
okay,
so
to
kind
of,
like
put
it
in
very
simple
terms,
now
like
from
a
roadmap
view
now,
we
need
to
include
merge,
request
and
usability
to
get
release
evidence
to
a
viable
state
for
comparing
chain
of
custody.
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
Yeah
so
like
just
to
recap
how
it
looks
in
my
head
right
now,
so
basically,
what
we're
doing
with
evidence
is
kind
of
a
tool
for
like
in
easy,
like
pre-audit
like
when
you
do
like
internal
audit
stuff,
and
it's
basically
just
an
index
of
everything
which
you
can
later
use
to.
B
Basically
click
into
stuff
and
see
that
everything
is
good.
And
if
something
wasn't
good,
then
it
it
will
be
like
red
flagged
by
the
gitlab
and
yeah.
You
see
you
can
like
make
an
excuse
before
the
real
audience.
B
Okay,
so-
and
will
this
be
like
actually
used
by
the
real
audit
which
will
happen
after
this.
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
Yeah,
but
like
the
one
thing
I
don't
get
here,
is
that
basically
release
evidence
is
collected
like
weekly
or
monthly
depends
on
how
you
make
a
release
so
and
grafana
is
more
like
a
everyday
tool.
So
maybe
they
like
they
are
either
looking
for
like
like.
A
B
Yeah
that
makes
sense
that
makes
sense.
Yeah
also
like
just
wanted
to
highlight
that
currently
we
don't
actually
collect
related
emergency
quests.
To
the
like,
I
mean
we
have
some
features
right
for
showing
magic
questions
or
into
release
evidence,
but
it's
not
actually
tied
to
code
changes.
B
It
basically
just
takes
some
milestones
right
and
then
takes
all
the
related
nurse
requests
and
half
of
them
may
be
already
released
in
the
previous
release.
Half
of
them
may
have
nothing
to
do
with
this
release.
Actually
so
yeah.
Maybe
we
need
to.
B
A
I
like
that
idea.
I
wonder
if
this
will
be
like
helped
with
like
auto
change.
Log
features
too,
when
we
generate
an
auto
change
log,
because
that's.
A
B
Yeah,
basically,
if
we
can
like
implement
how
to
change
log,
then
we
can
just
use
the
same
stuff
in
the
maybe
just
complete
all
this
change
log
directly
to
the
release.
Evidence
save
it.
There.
B
B
Like
these
nudge
requests,
very
fuzzily
tied
to
the
actual
code,
which
was
released
so.
A
Yeah,
I
agree
when
I
mentioned
earlier
that
it's
unusable
for
people
who
are
not
leveraging
milestones.
That's
exactly
what
I
meant
like.
If
they
don't
use
milestones,
then
you're
not
going
to
get
any
merge
requests.
Much
like
you
won't
have
that
history
that
you're
looking
for.
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
Like
a
little
time
overall,
which
I
know
we
have
like
two
minutes
left,
okay,
I
only
take
more
of
your
pto
than
necessary.
Was
this
a
helpful
conversation
was
the
future.
B
Yeah
that
was
definitely
helpful.
I
wonder
how
helpful
it
was
for
you
and
we
probably
should
jump
to
the
road
map
or
something.
A
A
B
A
I
think
I
have
I
have
like
yeah.
We
can
bump
up
until
9
30..
So
looking
at
your
release,
evidence
roadmap
epics.
Let
me
see
if
I
can
find.
B
B
B
A
This
is
the
issue
that
we
called
kind
of
an
epic
and
then
it's
not
a
scientific
or
anything.
But
this
is
like
our
technical
debt
and,
like
usability
of
evidence,
that's
been
identified
right,
like
unable
to
download
evan's
collection.
B
Yeah,
exactly
by
the
way
one
question
about
this,
like
I
saw
this
hardening
issue,
I
didn't
dig
into
it.
B
But
the
question
is:
did
we
consider
just
I
don't
know
showing
to
the
like,
showing
the
full
evidence
only
to
auditors
and
disregarding
all
the
permission
model
inside
so
like?
If
you
have.
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
Page
super
clean
sean
and
I
talked
about
restricting
it
to
auditors,
just
like
you
said
when
I
was
talking
to
the
compliance
organization
now,
there's
some
concerns
around
if
in
order
to
remediate
the
like
in
the
future,
the
three-year
vision
plan
in
order
to
remediate
some
of
the
things
that
aren't
working,
they
may
need
to
have
like
a
maintainer
levels.
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
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
Yeah,
I
guess
like
generation
of
the
generating
of
the
changelog
automatic.
They
will
be
a
great
addition
to
the
evidence
yeah
if
you
can
make
it.
A
Yeah
I
like
that
idea
I'll,
create
that
issue.
Then
I'm
going
to
add
a
note
here,
so
I
can
remind.
A
B
B
No,
no
thanks
actually
yeah.
Thank
you
so
much
for.
I
guess
this
mission
was
more
valuable
to
me
than
it
for
you.
I
don't
know
just
because
I
don't
know,
I
didn't
understand
how
this
will
be
used
and
how
this
should
work.
So.
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.
B
B
Yeah,
that
would
be
great
yeah
have
a
great
day,
then
perfect.