►
From YouTube: Compliance in Release Stage Deep Dive with Matt & Jackie
Description
Welcome to a deep dive into a compliance mindset for the release group.
B
So
we're
here
to
talk
a
little
bit
about
compliance
that
get
lab
in
between
release
and
the
compliance
stage.
So
Matt
would
love
to
hear
a
little
bit
more
about
how
compliance
is
going
today
and
where
you'd
want
to
take
it
in
the
next
couple
of
years,
so
that
I
know
where
I
can
hook
in
as
a
partner
in
our
product,
world
yeah.
A
A
There
we
go
so
the
way
that
I
currently
think
about
it
is
this
idea
that
organizations
are
operating
in
industries
that
are
regulated
in
some
way
that
could
be
regulated
from
a
legal
perspective.
Things
like
sarbanes-oxley
that
could
be
regulated
from
a
I
guess,
an
industry
best
practices
perspective
like
sock
to
GE
PR
is
another
legal
or
regulatory
one,
and
so
these
would
class
foot
would
fall
under
what
I
would
consider
compliance
frameworks.
A
A
For
sure
this
is
not
exhaustive
and
I
think
part
of
the
hierarchy.
The
the
hierarchy
theme
here
is
that
frameworks
are
all
basically
the
same
kind
of
in
their
fundamental
premise
and
that
we're
concerned
with
security
with
data
privacy
with
access
control
with
separation
of
duties.
These
are
all
just
common
themes
and
so
from
the
compliance
frameworks,
perspective
I'm
an
advocate
of
using
the
work,
our
internal
security
compliance
team
has
done
under
the
get
lock.
A
Control
framework,
they've
essentially
mapped
this
control
family
framework
to
existing
frameworks
like
sock
to
socks
and
I,
so
I
think
are
the
current
ones.
So
if
we
can
go
about
evolving
that
to
add
glba
gdpr
HIPAA
NIST
Cobie,
all
these
different
frameworks
that
already
exist
I
think
it
makes
it
a
much
more
seamless
process,
not
just
for
us
to
maintain
it,
but
it
also
gives
us
this
thought
leadership
perspective.
A
It
allows
us
to
associate
our
name
of
gitlab
with
compliance,
secure,
stress-free
management
of
compliance
programs,
so
frameworks
is
that
overarching
concept
within
that
I
see
three
main
categories:
compliance
controls,
which
is
okay,
I,
know
the
requirements
of
the
framework,
but
a
lot,
but
they
vary
as
far
as
how
prescriptive
they
are.
Some
are
very
prescriptive,
like
PCI,
DSS
or
sarbanes-oxley.
A
B
First,
one
is
very
relevant
to
something
that
I'm
starting
to
scratch
the
surface
on
in
release
governance.
So
a
couple
of
in
serve
customers
are
very
interested
in
the
manual
interventions
that
one
has
to
take
in
order
to
get
code
to
production
and
when
I
start
to
like
dig
in
to
the
reasons
why
they're
not
always
surfacing
that
I
need
this
to
be
compliant.
Sometimes
it's
I
want
to
have
a
chain
of
custody.
I
want
to
understand
what
my
organization
is
doing.
A
So
yeah
I
think
on
that
note.
So
two
things
one
I
think
that
compliance
right
is
ultimately
under
the
umbrella
of
governance,
risk
and
compliance,
and
so
it's
all
about
mitigating
risk
in
this
particular
context.
How
we're
talking
about
legal
and
regulatory
frameworks?
It's
about
reducing
risk
and
liability
of
data
breaches
and
the
associated
fines
that
come
with
it
to
the
second
point
about
buyer
versus
user
persona.
What
I've
noticed
in
my
conversations
and
I
think
speaks
to
your
point,
is
the
users
of
gitlab?
A
Some
of
them
have
dubbed
themselves
the
gate
lab
custodians,
but
the
the
date
of
the
users
of
gitlab
are
tasked
with
the
tactical
piece
of
internal
audit
or
compliance
team.
Says:
hey
I
need
to
see
evidence
that
you're
adhering
to
policy
because
I
have
this
other
objective
over
here
and
so
the
data
the
users
are
not
necessarily
compliance
or
audit
themselves.
In
fact,
some
of
them
have
said.
I
I
wish
that
my
audit
and
compliance
or
security
team
can
just
come
in
in
a
read-only
way
and
just
do
what
they
need
to
do.
A
Set
policy
and
force
policy
collect
evidence,
but
not
see
the
code
base
not
take
any
write
or
execute
action,
and
that
kind
of
thing
so
there's
there's
also
an
issue
have
created
to
work
with
us:
UX
research
to
define
the
compliance
persona,
because
I
think
that's
missing
and
I.
Think
as
we
work
through.
That
process
will
also
put
better
clarity
around
the
buyer
versus
user
user
relationship.
In
this
context,
okay.
A
And
so
the
second
main
catagories
audit
events,
basically
every
single
enterprise
customer
I've
spoken
to
that,
has
compliance
on
the
mind
whether
that's
legal,
regulatory
or
just
internal
good
practice,
I.
Think
like
what
you're
alluding
to
it's
always
been
about.
We
need
visibility
that
manifests
as
audit
events.
So
if
there
are
gaps
in
the
activity,
meaning
if
they
go
in
to
answer
questions
which
is
factually
the
cases
they've
conveyed,
if
they
go
in
to
look
for
answers
and
they
can't
find
them
about
who
took
what
action.
A
When
for
what
purpose
that
kind
of
information,
then
those
are
gaps.
Those
are
auditable
events
that
an
external
auditor
will
come
in
and
say,
for
example,
show
me
the
last
six
months
of
merger
quests
for
project
a
and
B.
If
I,
sorry,
dogs,
if
I
pull
that
information-
and
they
see
ok,
wool,
I'm
missing
a
B
and
C
type
of
data
in
in
this
audit
log,
then
they'll
then
have
a
gap
and
they'll
have
a
gap
identified
right.
They
then
have
to
remediate
that
gap.
A
Well,
if
that
data
is
only
available
within
get
lab,
that
falls
to
us,
and
so
we
then
become
an
impediment
to
their
audit
ability
in
their
compliance
with
that
independent
third
party.
So
audit
events
are
critical
for
general
visibility,
but
also
audit
ability
so
that
we're
not
the
roadblock
and
then
the
last
one
is
just
the
reporting
aspect.
A
So
it's
great
if
we
have
this
level
of
granularity
and
the
audit
events,
but
if
customers
are
still
having
to
do
a
lot
of
the
heavy
lifting
that's
time
and
money
that
they're
spending
for
something
that's
not
necessarily
value-adding,
it
is
in
that
it
makes
the
audit
process
easier.
So
they
may
be
willing
to
invest
that
time
and
effort,
but
if
we
can
make
that
a
one-click
option
to
say
you
know
for
the
last
six
months,
pull
a
report
of
all
merge
requests
activity
and
then
we
provide
in
that
report.
A
The
detail
that
we
find
through
research
and
validation
is
most
satisfactory
for
auditors.
Then
we've
made
their
job
a
lot
simpler,
we've
improved
their
quality
of
life,
we've
reduced
the
friction
of
audits
in
general,
and
so
that's
my
general
thinking
at
a
high
level
and
how
it's
sort
of
framed
it
visually.
So.
B
That's
super.
This
whole
thing
is
super
helpful.
By
the
way,
thank
you
and
I'm
taking
now
ideas
on
how
to
inject
some
of
your
language
or
thoughts
into
the
released
post
items
that
I
have
that
are
related
very
strongly
to
compliance.
For
example,
I
have
captured
release
events
as
a
part
of
our
audit
logs,
and
a
big
part
of
that
story
is
going
to
be
both
your
audit
event
strengthening,
but
also
reducing
the
friction
of
people
successfully
completing
an
audit
and
how
I
phrased
it
was
now
that
get
lab
can
do
these
things
for
you.
B
A
I
think
that's
a
I
think
it's
a
really
good,
thoughtful
messaging
of
that
whole
premise,
because
I
think
it's
ultimately
about
part
of
the
friction
and
auditing
or
compliance
in
general.
Is
that
it's
seen
as
this.
This
task
that's
a
burden
right,
because,
if
I'm
a
sysadmin,
if
I'm
an
engineer
or
something
I,
don't
want
to
do
things
that
are
outside
the
scope
of
my
responsibilities.
A
I
want
to
be
able
to
do
my
job,
but
I
want
to
do
well,
and
so,
if
we're
able
to
build
in
functionality
that
says
okay,
do
your
job
we'll
handle
the
burden
of
that
thing,
that
you're,
internal
compliance
or
auditing
team
is
asking
for
yeah
I.
Think
that's
I,
think
it's
perfect,
I,
think
compliance
or
GRC
right
governance,
risk
and
compliance
is
such
a
broad
concept.
A
I
think
it'll
likely
touch
every
stage
it
get
lab
out
of
necessity,
but
on
the
same,
like
I'm,
the
difference,
the
different
side
of
the
same
coin
is
like
we're
not
able
to
include
in
our
scope
some
of
the
things
like
organizational
operations
and
many
parts
of
disaster
recovery
and
configuration
management.
Things
like
that
right.
Some
of
those
organizational
things
fall
outside,
and
so
that's
kind
of
a
nice
thing,
because
it
allows
us
to
focus
on
a
very
narrow
set
of
control.
A
What
is
the
customer
going
to
be
going
through
workflow
wise
and
what
evidence
artifacts
might
they
need
to
generate
from
this
feature
that
we
can
then
coordinate
with
Matt
over
in
manage
compliance
to
say?
Okay,
how
do
we
then
link
up
on
this
to
where
you
know
either
it
becomes
part
of
that
feature
if
it
makes
sense
or
it's
a
separate
issue
that
gets
created,
that
I
can
then
tackle
or
whatever
that
looks
like,
but
it's
ultimately
in
mind
and
that
that's
really
tough
thing
to
a
really
tough
challenging
thing.
Yeah.
B
A
big
part
of
that
is
addressing
the
compliance
needs
and
every
single
thing
you
do,
and
that
part
is
missing
in
our
templates,
for
both
like
feature
proposal
or
how
you
even
look
at
that
I
wonder
if
there's
nothing
prescriptive
that
we
can
give
to
our
product
managers
to
help
them.
One
come
to
you
with
a
proposal.
Rather
than
being
like
hey,
look
at
my
proposal
and
tell
me
what
you
need
to
do
you
to
make
this
compliant
as
I.
Think
that's
where
this
could
get
really
messy
for
you
from
a
compliance
perspective.
A
Yeah,
it's
it's
a
multi
fold
concern
right
because
I
become
a
bottleneck
in
theory
is
because
it's
not
scalable
for
me
to
have
input
on
the
dozens
or
hundreds
of
issues.
I
think
it
burdens
the
product,
development
and
release
process
to
where
we
start
sacrificing
velocity
for
the
sake
of
compliance
considerations.
A
B
A
Think
that
in
a
perfect
world,
every
feature
we
release
would
account
for
these.
You
know
audit
events,
the
evidence
artifacts
that
have
to
be
generated,
etc,
because,
ultimately
it
has
to
be
this
unified
experience.
I
think
you'll
find
that
you
know
if
you,
if
you
look
at
auditors,
like
external
auditors
and
auditing
firms
as
an
example,
their
whole
world
is
just
having
this
very
critical
thinking
mindset
as
it
pertains
to
a
company's
structure
and
operations.
So
an
auditor
walks
in
your
door
and
they're
immediately
thinking
about
I
didn't
go
through
any
sign-in
process.
A
I,
don't
see
any
surveillance
cameras
I
was
able
to
walk
in
escorted,
but
there
is
no
security
code,
so
I'm
curious
to
know
what
their
technology
policies
look
like
and
so
having
that
same
level
of
critical
thinking,
I
think,
but
to
the
benefit
of
our
customers
of
okay.
I
want
to
build
out
this
really
cool
feature
under
plan.
B
What
I,
what
I
want
to
be
able
to
do
is
almost
have
your
stage,
be
the
best
practices
that
creates
a
bunch
of
best
practices
that
we
can
like
services
on
us
that
we
can
implement
inside
of
something
like
release,
management
or
progressive
delivery.
So,
for
example,
audit
events.
You
know
almost
every
issue
that
I'm
creating
now
I
look
at
it
and
be
like.
B
Are
we
doing
something
that
needs
to
be
scribed
back
into
an
auto
log
and
then
I
put
that
as
a
part
of
the
acceptance
criteria,
but
for
things
they're
a
little
bit
bigger
than
that
that
are
related
to
compliance
controls?
I'm,
not
savvy
enough
to
know
with
this
benefit
or
touch
a
compliance
control
system
that
gitlab
might
be
related
to
in
some
regulated
industry,
but
I
know
that
if
I
invest
in
that
area,
that'll
help
the
adoption
and
that'll
increase
my
smell
in
release.
If
we
can
meet
those
regulated,
customers
needs
so
I.
B
A
A
Maybe
it's
just
inherently
the
circumstance
that
PM's
release
features.
They
do
their
best
to
give
what
attention
they
can
or
consideration
they
can
to
the
compliance
implications,
but
then
maybe
it's
just
how
things
have
to
be,
at
least
for
now
that
I
have
a
workflow
to
go
and
look
at
the
features
that
are
being
released.
Listening
to
the
customers
telling
me
hey
this,
you
know
five
of
the
features
you
released.
A
I
can't
use
them
because
there's
no
audit
events
or
I
can't
use
them,
because
it's
lacking
some
sort
of
permission,
granularity,
control
or
I
can't
use
them
because
you're,
you
know,
whatever
your
team
and
group
structure
doesn't
work
for
me,
and
maybe
it
just
has
to
be
necessarily
reactive,
which
I,
don't
think
is
necessarily
bad
in
and
of
itself.
I.
Think
at
that
point,
though,
we
then
have
to
make
sure
that
we're
moving
quickly
if
we're
reactive
but
but
I,
think
that
might
be,
in
my
opinion,
right
now.
A
That
might
be
the
best
path
forward
versus
trying
to
front-load
our
internal
process
with
it,
because
it
would
be
I
think
a
huge
cost
to
try
and
introduce
it
to
the
process
when
there
is
both
an
educational
aspect
of
it
or
to
it.
Combined
with
you
know
the
additional
time
required
to
figure
out
how
that
manifests
in
terms
of
features
or
supplemental
features.
A
B
That's
helpful,
I
think
for
for
release
management.
Specifically,
we
have
a
little
bit
more
overlap,
specifically
around
things
like
deploying
to
production
environments
and
those
audit
trails
that
need
to
be
half
that
need
to
be
ingrained
in
our
inherent
process,
but
also,
as
we
start
to
learn
more
about
the
vision
and
application
of
things
like
release.
Governance,
there's
something
to
be
said
around
using
something
like
run
books
to
do
a
manual
approval
action
and
to
prevent
a
deployment.
B
But
there's
also
something
like
making
sure
that
that
run
book
action
that
we
stopped
a
deployment
because
of
rendom
of
tasks
wasn't
complete,
is
transcribed
into
an
audit
log,
but
also
that
they
get.
That
can
see
that
that
wasn't
just
a
normal
actor
that
that
was
a
machine
performing
that
act
from
from
an
outside
point
of
view.
A
I
think
that
sounds
like
a
great
iterative
step
in
her
journey
towards
figuring
out
how
this
could
work.
I
think
part
of
the
challenge,
even
in
just
knowing
when
it
might
be
helpful
to
loop
me
in,
and
collaborate
on
things
is
listening
for
those
key
words
phrases
or
concerns
right.
So
when
your
earlier
points
about
how
the
the
premise
was
not
or
the
root
pain
point
was
not
necessarily
an
explicit
well
I
need
this
for
a
compliance
purpose
or
audit
reason.
A
It
was
why
just
like
governance
and
I
need
to
know
what's
happening
like
those
are
key
terms
that
I'd
be
willing
to
bet
that
they
have
something
internal
external,
some
program,
that's
guiding
that
that
style
that
approach
right.
So
it's
it's
great
if
I'm
wrong,
and
they
just
want
to
know
what's
happening
because
they
they,
like
that
visibility
to
have
that
control
and
and
operate
in
their
best
practice.
That's
usually
not
the
case
right,
because
it's
extra
work,
and
so
people
are
being
driven
by
some
requirement
and
it's
usually
tied
into
some
framework
or.
B
It
could
be
that
there's
this
inherent
culture
shift,
that's
disrupting
old-school
thought
about
needing
to
have
that
waterfall
action
to
deploy
to
production
versus
companies
who
are
really
leveraging
a
CI
CD
pipeline
and
who
trust
in
their
automation,
who
build
out
robust
test.
Suites
I
mean
I.
Think
I
was
reading
an
article
the
other
day
that
suggested
everyone
gets
through
CI,
but
the
minute
that
they
can't
CD.
They
stop
their
process
because
adopting
this,
let
it
release
automatically
to
production
without
human
intervention
is
something
that's
scary
and
fearful.
B
So
there's
also
this
in
the
market
work
at
labs
competing
we're
going
against
all
these
other
tools
that
people
are
more
comfortable
being
involved
in
seeing
the
actions
or
being
able
to
intervene
more
thoughtfully,
even
if
it
isn't
governed
by
an
audit
action
but
I
think
nine
times
out
of
ten.
It
is.
A
And
I'd
love
to
understand
that
too
right,
as
is,
do
we
have
a
misperception
about
how
much
of
this
is
being
driven
by
compliance
programs,
either
legal
regulatory
frameworks
or
internal
versus
not-
and
you
know,
I
thought
I
had
from
when
your
comments
earlier
to
was
something
that
we've
heard
a
lot.
Is
our
enterprise?
A
Customers
want
to
be
able
to
hook
in
their
external
services
to
get
lab,
so
they
have
a
bunch
of
action
or
activity,
that's
happening
outside
of
our
environment,
but
they
still
want
to
see
that
in
one
place,
and
so
you
know,
one
path
we
can
explore.
If
we
aren't
already
to
some
degree,
is
in
the
context
of
compliance,
how
do
we
enable
them
to
send
us
the
data
they
want
us
to
aggregate
for
them
and
then
make
sure
that
that's
correlated
appropriately
with
various
activities
right?
A
So,
if
I
create
a
merge
request,
I
want
to
see
that
external
services
a
B
and
C
all
executed
properly.
They
have.
You
know
the
company
knows
what
those
systems
are.
Checking
for
I
see
some
visual
indicator
within
gitlab
and
then,
when
I
approve
and
merge
that
merge
request.
I
then
have
an
artifact,
that's
generated
that
says:
yes,
here's
all
the
stuff
in
gitlab,
but
also
here's
the
unique
hashes
associated
with
these
external
processes.
A
So
things
like
that,
where
maybe
it's
something
where
our
position
could
be
we're
going
to
give
you
the
flexibility
to
customize
this
environment.
The
way
you
need
to
to
be
compliant
and
to
have
that
comfort
and
reassurance,
because
your
needs
are
highly
nuanced,
as
an
organization
operating
in
this
regulated
industry
even
versus
your
neighbor
company
who's
in
the
same
industry
and
then
our
focus
is
then
on,
like
the
reporting
and
the
analysis
and
the
informative
posture
of
hey
you've
connected
all
these
services,
we
noticed
that
things
are
off
in
some
way.
A
B
You
know
how
do
we
effectively
support
that
scale,
but
then,
when
we're
looking
at
the
compliance
side
of
it,
we
need
to
make
sure
that
our
permissions
are
right
or
that
we're
not.
You
know,
showing
secrets
in
a
certain
way
or
that
we're
able
to
prevent
nefarious
actors
from
you
accessing
audit
events
that
were
read-only
and
it
gets.
B
A
B
So
open
issues
being
one
of
them,
but
also
the
whole
hash
structure
that
we
currently
have,
which
doesn't
have
any
merge
requests
associated
with
it,
but
also
including
all
of
the
issues
within
any
given
release
meant
that
you
are
exposing
confidential
issues
to
people
in
that
project.
That
may
not
have
access
to
confidential
issues.
B
A
So
so
not
the
purpose
of
this
call,
but
just
some
feedback,
which
is
maybe
helpful,
so
I
think
what
you
could
do
is
you
could
sit
because
hey.
Let
me
back
up
a
little
bit
so
I
think
that
the
report
in
and
of
itself
is
super
valuable
right.
I
I
think
we
should
provide
for
every
release.
Here's
the
list
of
murder
quests.
Ideally,
the
merger
quest
would
require
at
least
one
link
to
issue
if
it
doesn't
already
I,
just
I,
don't
think
it
does.
But
a
that
issue
is
the
justification
right.
A
The
business
case
for
the
change
to
be
made.
So
you
have
the
merger
quest
which
has
the
linked
issue.
It
should
ideally
also
link
the
pipelines
and
jobs
associated
with
that
merger
quest.
Show
the
pass/fail
so
like
I
should
have
all
of
this
data,
but
as
far
as
the
the
issues
that
are
confidential
I
mean,
is
there
a
way
that
you
could
hash?
The
issue
itself
like,
if
confidential,
take
a
hash
of
this
because
in
theory
that
identifier
for
the
issue
won't
change
on
the
back
end
anyway.
B
Interesting,
we
baited
that
completely
and
actually
said
that
you
have
to
have
the
auditor
roll
in
order
to
see
release
evidence,
so
we
just
elevated
who
gets
to
see
release
evidence
that
way.
The
IDS
of
confidential
issues
can
still
be
contained
within
the
release
hash,
but
the
linked
the
issues
are
no
longer
contained
in
the
JSON
file.
So
we
avoid
the
risk
leaking
the
content
of
a
confidential
issue,
so
janitrol
can
now
click
the
link
of
the
ID
to
the
issue.
B
That's
confidential
or
not
in
that
JSON
file,
and
the
next
part,
though,
is
adding
in
the
merge
requests,
which
are
more
meaningful
about
the
actions
that
were
committed
in
production.
There's.
Another
nuance
that
I
need
to
understand
a
little
bit
more
is
the
ability
to
link
to
a
deployment,
as
this
isn't
something
that
we
necessarily
support
inside
of
get
lab
today.
We're
able
to
indicate
that
this
is
a
release
which
is
a
package,
a
collection
of
issues,
but
it
doesn't
necessarily
tie
back
to
an
environment
we're
in
production.
So.
A
B
A
A
For
sure,
no
thank
you
for
that.
So
I'd
be
curious.
I
understand
to
write
like
we
have
the
auditor
role,
but
is
that
that
sounds
like
it's
catered
towards
auditing
or
compliance
teams
internal
to
a
customer's
organization
right
for
the
most
part,
as
you
understand
it,
so
is
there
concern
with
including
that
confidential
those
confidential
issues
in
an
exportable
artifact.
That's
then
handed
off
to
a
third-party
auditor
I.
A
B
It
was
exported,
it
would
be
just
a
snapshot
in
time
so
from
our
users,
requirements
of
being
able
to
show
at
that
moment
in
time
that
would
release
was
created
with
all
of
these
related
issues.
What
was
contained
in
that
release,
not
that
is
to
do
with
what
they
see
fit.
I
agree,
though,
that
it
does
expose
risk
of
leak
of
information.
If
that
third
party
person
now
has
their
credentials
to
click
into
that
link
and
then
see
that
confidential
issue
as
a
read-only
and.
A
And
every
organization
will
be
different
in
their
tolerance
for
that
auditors.
Third
party.
Auditors
are
generally
sort
of
these.
You
know
liaisons
that
are
kind
of
given
carte
blanche,
aux
access
to
stuff
and
I
I'm,
not
I'm
sure.
This
is
not
a
in
this
very
broad
stroke,
but
if
you
have
a
third
party
auditor
come
in
and
they
say
I'd
like
to
see,
you
know
to
my
example
earlier
I'd
like
to
see
the
last
six
months
of
merge
requests.
A
B
No
I
think
that
that's
very
relevant
because
right
now
in
12.8
I
have
this
issue
to
create
another
snapshot
in
time.
So
we
have
the
first
snapshot,
which
is
that
release
creation,
and
that
just
shows
when
you've
said
I
want
to
create
this
release.
This
is
the
status
of
the
issues
and
that
release
and
all
the
stuff
that's
in
it,
which
might
mean
that
we
want
to
contain
open
issues
if
that's
at
the
release
creation.
B
But
then,
when
the
release
is
completed
or
deploy
and
production,
that
would
be
the
second
snapshot,
and
that
would
be
the
status
of
all
the
closed
issues
confidential
or
not.
At
that
time
that
we've
declared
and
deployed,
and
by
we've
the
customer
has
declared
it
us,
but
I
would
agree
that
there
might
be
something
worth
investigating
on.
A
Yeah
and
I
think
so.
My
assumption,
right
now
and
and
based
on
the
calls
I've
had
cuz
enterprises
or
just
customers
in
general,
want
the
ability
to
export
this.
These
evidence
artifacts
that
they
have
it
historically,
so
that
they
can
go
in
and
provide
it
as
needed,
either
internally
or
externally.
For
audits.
A
The
nice
thing
about
what
it
sounds
like
you're
working
on
as
I
understand
it
currently
is
I've.
Had
several
enterprise
customers
say:
I
want
to
download
artifacts
that
show
me
the
merger
quest,
The,
Associated
issues
and
the
associated
pipelines,
so
that
in
and
of
itself
is
a
it
would
be
a
big
win
or
is
a
big
win,
because
I'm
not
sure
what
exists
currently,
but
for
some
of
our
compliance
minded
customers
who
are
focused
on
that
and.
B
A
B
B
B
So
I
think
we've
about
two
minutes
left
some
action
items
that
I'll
take
forward
are
sort
of
the
future
story:
boarding,
release
governance,
concepts
that
I
want
to
just
kind
of
run
through
with
you
and
to
make
sure
that
they're
salient
from
a
compliance
vision
or
if
I'm
missing
some
key
components
more
specifically
around
the
granularity
of
permissioning,
because
that
seems
to
be
a
big
big
concern
in
general
for
a
lot
of
our
enterprise
users.
So
I
would
like
to
hear
that
perspective
other
than
that.
B
A
A
A
A
So
they've
they've
apparently
built
out
this
really
cool,
merge,
request,
widget
that
allows
them
to
hook
in
their
external
services
they
use
to
deploy
to
two
or
four
gitlab,
and
so
I
want
to
one
of
the
scheduled
time
with
him
to
talk
about
okay.
How
do
I
then
take
that
and
make
it
available
for
customers,
that's
exactly
what
they
want,
but
it's
within
the
merge
request
widget.
So
it
sounds
like
something
that
you'd
probably
be
keen
on
interesting.