►
From YouTube: Compliance Pipeline Templates Proposal
Description
Matt Gonzales (PM, Manage:Compliance) and Jeremy Watson (Group Manager, Manage) discuss the latest proposal for enabling compliance-minded organizations to implement compliance pipeline templates that won't completely disrupt the developer experience or create catastrophic situations.
A
That
developers
aren't
entirely
trapped
by
and
the
second
issue
and
walk
you
through
talks
about
the
improvements
we
could
make,
rather
than
deprecation
of
required
pipeline
configuration
that
could
solve
for
the
friction
around.
You
know
developers
not
having
any
insight
into
what's
going
on
with
this
pipeline
config.
A
They
have
no
insight
into
or
control
over,
provide
them
a
way
to
override
or
escape
that
process
in
the
event
of
an
emergency
and
making
sure
that
we're
striking
that
balance
between
a
great
developer
experience
and
ensuring
that
compliance
minded
organizations
have
what
they
need
to
comply
with
their
regulations
or
in
general
policies.
So
let
me
start
with
expect.
B
Do
you
mind
telling
me
a
little
bit
more
about
some
of
the
research
that
you've
done?
You
said
you've
done
a
bunch
of
research.
I
know
that
you've
talked
to
a
ton
of
different
customers.
Can
you
kind
of
just
describe
maybe
a
high
level
you
can
the
typical
profile
of
the
customer?
That's
been
asking
for
this
and
kind
of
the
messaging
that
you've
heard.
If
you
can
summarize
it
as
best,
you
can
sure.
A
So
the
typical
profile
is
a
large
enterprise
who
operates
at
least
a
few
thousand
number
of
projects.
They
are
typically
in
the
premium
or
ultimate
pricing
tier
and
they
have
generally
a
very
risk-averse
profile
in
terms
of
their
appetite
for
risk.
They
are
of
the
mindset
that
some
of
them
are
of
the
mindset
that
they
would
rather
block
everything
to
production,
then
allow
even
a
single
bad
change,
but
there
are
others
who
say:
no,
it's
okay.
A
We
want
to
empower
developers
to
be
able
to
deploy
to
certain
environments
with
minimal
blockages
or
gates
or
interaction
from
us
as
the
compliance
team,
but
there
still
do
need
to
be
programmatic
checks
that
could
block
production.
If
it's
an
egregious
non-compliant
change.
Some
of
the
main
highlights
have
been.
You
know
an
explicit
mention
of
quote
unquote,
we're
typically
more
concerned
with
making
an
auditor
happy
than
we
are
with
the
developers,
though
we'll
try
to
make
developers
happy
where
we
can
another
one.
A
Another
interesting
insight
was
it's
more
expensive,
far
more
expensive
and
time-consuming
for
us
to
retro
actively
undo
a
non-compliant
changed,
and
it
is
for
us
to
be
a
little
bit
less
efficient
up
front
and
stop
those
non-compliant
changes
from
being
able
to
propagate
in
the
first
place.
So
hopefully
that
answers
your
question.
Yeah.
A
So
let
me
go
ahead
and
jump
into
this
first
proposal,
so
this
rich
proposal
essentially
relies
on
parent-child
pipelines
to
be
able
to
enforce
a
in
well
any,
but
it
is
enforcement
right
to
be
able
to
define
a
compliance,
pipe
link
template
basically,
as
a
baseline
of
you
know,
stages
or
jobs
that
need
to
run
for
every
project
in
a
regulated
group
or
a
regulated
project.
And
so
what
this
does
is
we
would
say,
at
the
group
level,
similar
to
the
current
required
pipeline
configuration.
A
We
we
have
a
project
where
we
can
point
to-
and
we
say
this
project
contains
a
template
that
we
define
as
here's
the
baseline
requirement
it
might
have
scanning
scans
or
testing,
or
something
that
the
organization
has
said.
Here's
what
has
to
run
for
each
project.
That's
going
to
push
to
a
sensitive,
regulated
production
environment,
so
using
parent/child
pipelines
that
group-level
definition
becomes
the
parent.
The
the
developer
then
creates
a
project
which
becomes
the
child
pipeline
in
that
equation
and
when
they
set
up
the
project
they
can
use
the
custom.
A
Ci
config
pass
to
point
to
this
this
external
project.
With
this
compliance
pipeline
definition
once
that
relationship
is
established,
then
when
the
project
runs,
they
have
this
unified
pipeline
between
the
parent
and
child,
so
group
and
project
level,
and
then,
as
this
pipeline
is
run,
we
we
start
realizing
that
there
are
opportunities
for
improvement,
and
so
some
of
the
some
of
those
opportunities
are
defined
down
here.
Where
we
talk
about
right
now,
one
of
the
missing
key
elements
is
artifacts
between
parent
and
child
pipelines.
A
So
that's
one
of
the
gaps
we'd
have
to
address
improving
the
dag,
visualization
or
Doug
view
for
Parent
Child
pipelines,
which
I
know
there's
a
lot
of
great
work
being
done
around
that
already.
But
this
is
this
particular
improvement
would
provide
developers
with
more
insight
so
that
they
don't
just
see.
Oh
I
have
an
upstream
failure.
What
do
I
do
what's
going
on?
A
So
these
are
the
the
gaps
that
we've
identified
in
this
particular
proposal,
but
this
at
least
gets
us
to
a
point
where
customers
have
said.
Yes,
this
solution
is
what
we
need
now
that
solves
for
the
customer
side
right.
That's
the
customer
saying
yes,
there's
buy-in!
We
like
this.
We
want
this
solution
that
doesn't
solve,
for
what
I
would
call
the
gitlab
side
where
we
want
to
make
sure
the
developer.
Experience
is
great.
We're
not
causing
a
lot
of
friction.
A
B
I
mean
that
was
going
to
touch
on
the
question
that
I
have,
which
is
that
the
and
now
I
looks
like
I'm
able
to
look.
The
only
thing
is
I
can't
I
don't
have
any
control
over
the
child
of
the
parent
pipeline.
I
guess
it
would
be
in
this
case
where
it
is
nice
that
I
didn't,
because
we're
using
parent-child
pipelines
I
as
a
developer.
B
Who's
working
in
this
in
this
project,
I
can
manage
my
CI
mo
file
in
whatever
way
that
I
want,
but
we're
able
to
always
enforce
that
the
parent
pipeline
is
being
run,
but
my
question
naturally
became
like
what
happens.
If
you
know
there's
a
seventh
one
and
I
need
to
be
able
to
push
an
emergency
change,
and
the
parent
pipeline
is
now
failing
for
some
weird
reason,
because
there's
like
an
enforcement
or
compliance
job.
B
A
No,
it's
a
great
question
and
I
know
that's
kind
of
the
route
at
why
we
didn't
want
to
pursue
required,
pipeline
configuration
and
so
I'm
glad
you
asked
Jeremy,
because
I
think
I
have
the
solution.
So
the
the
second
proposed
essentially
says
here
are
some
things
that
we
can
do
to
improve
the
experience
and
the
functionality
of
required
pipeline
configuration
rather
than
deprecated,
because
what
we
know
is
that
when
we
announced
the
deprecation
and
customers
reacted
and
you
you
could
classify
that
as
like.
A
Well,
you
know-
maybe
they
just
don't
know
what
the
alternatives
are,
or
maybe
we
can
solve
this
in
a
better
way
and
I
think
this
is
solving
it
in
a
better
way,
which
is
simply
iterating
on
it
to
make
it
a
better
experience.
So,
essentially,
what
I
would
like
to
achieve
is
first,
we
should
remove
the
deprecation
status
of
this
feature.
That's
my
humble
opinion,
and
then
we
should
instead
rename
it
to
compliance
pipeline
template
or
something
similar,
because
that's
what
it
is
right
it
is.
A
It
is
a
template
with
specific
compliance
requirements
that
has
been
defined
at
the
organizational
or
maybe
department
level,
and
it's
just
it's
gonna
happen
either
way
with
or
without
our
help.
So
by
making
it
native
but
smooth
and
developer
friendly,
I
think
that's
a
win.
Instead,
then
I
think
it's.
You
know,
there's
a
little
bit
of
uncertainty
on
the
specifics
of
exactly
how
we
implement
something
like
a
list
of
approvers
but
similar
to
merge,
request
approvers.
There
probably
needs
to
be
a
list
of
like
organizational
or
security
approvers.
A
Some
of
the
work
that
we're
doing
for
two-person
approvals,
which
is
mentioned
down
here,
would
require
I
think
at
least
so
far
in
our
research.
Some
list
of
people
who
are
authorized
to
approve
changes
to
sensitive
settings
or
as
I'll
covered
in
a
minute,
maybe
approve
the
bypass
of
this
compliance
pipeline
template
so
exploring
that
particular
feature
of
how
do
we
create
this
list
of
users?
Who
can
then
be
these
authorized
personnel
to
make
these
decisions
or
like
DB
second
set
of
eyes
for
certain
actions
in
the
application?
A
So
we
could
add
so
kind
of
following
that
logic
we
could
add
a
button
to
maybe
specific
jobs
in
the
pipeline.
Maybe
the
merger
quest
itself
and
that
could
manifest
to
say
you
know:
hey
I,
need
to
request,
request
an
override
or
request
an
exception
or
something,
and
that
could
generate
notification
to
this
list
of
users
and
says
hey
like
there's
some
problem
with
this
pipeline.
A
Well,
but
now
I
have
a
button
that
I
say:
I
need
to
get
past
this
that
sends
emails,
maybe
in
at
night,
and
maybe
we
leverage
an
approval
queue
in
the
compliance
dashboard,
maybe
all
of
those
things
and
that
allows
this
authorized
list
of
people,
maybe
just
admins
or
group
owners
to
say
you
know.
It's
okay
for
this
to
be
exempted
from
our
typical
workflow,
because
production
is
down
and
we
need
this
change
to
go
out.
A
So
this
basically
gives
developers
the
we
empower
developers
to
take
control
of
that
action
or
at
least
some
semblance
of
control,
because
before
they
have
no
recourse,
maybe
you
know
manually
engaging
with
somebody
outside
of
the
application,
but
within
the
application
we
could
append
information
that
makes
that
decision
much
faster,
much
easier
for
the
authorized
person
right.
Well,
what
is
the
merge
request?
Id?
What
is
the
target
and
source
branch?
What's
the
target
environment?
A
How
many
approvers
is
it
maybe
have
already
you
know
we
can
append
data
that
we
already
have
and
help
make
that
decision
much
faster
rather
than
finding
Jeremy
briefing
Jeremy,
bringing
you
up
to
speed
and
then
like
making
that
decision
together.
There's
an
existing
feature
already
for
allowing
users
to
override
the
job
result
and
continue
the
pipeline
and
I.
A
Think
if
we
take
that
and
iterate
on
it
to
be
a
bit
more
compliance
organization
friendly,
then
I
think
we
essentially
have
that
mechanism,
or
at
least
proposed
and
ready
to
say
iterate
on
I
mentioned
earlier,
that
the
use
of
two-person
approvals
could
come
into
play
here,
because
we're
already
establishing
a
paradigm
where
a
any
user
could
say.
Hey
this
sensitive
project.
Setting
I
want
to
I
want
to
change
that,
but
my
organization
once
that,
the
way
that
set
the
way
that
it
is
so
I'm
gonna
request
a
change.
A
That
thing
goes
to
an
authorized
approver.
They
review
that
and
they
say.
Yes,
this
is
okay
to
change,
and
then
they
can't
they're
at
least
aware
of
what's
happening,
and
then
they
can
change
it
back
once
the
the
task
is
completed
and
so
I
think
we
can
take
that
paradigm
and
apply
it
to
this.
For
merger
quest
and/or
the
jobs
themselves,
I
think
this
process
would
also
allow
us
to
them
surface
intelligent
data
within
the
merge
request.
So
we
could
show
you
that
were
any
of
these
jobs
overridden
or
exempted
were
there
any
failures?
A
Who
was
the
authorized
approver
outside
of
the
merge
request
approvals?
Who
interacted
with
this?
Was
there
documentation
created?
Let's
say
like
a
programmatic
issue,
we
created
to
document
this
override,
who
requested
it,
who
approved
it.
Job
targeted
all
that
and
I
think
this
complements
the
proposal
we
just
covered
and
so
I
think
these
two
things
together
satisfy
both
compliance
minded
organizations.
You
say:
hey,
we
want
this
control.
A
We
want
to
be
able
to
make
sure
that
these
regulated
projects
operate
in
a
certain
way
according
to
company
policy,
but
then
it
also
enables
developers
to
say:
hey
like
there
are
gonna
be
times
when
this
makes
no
sense,
because
we
are
gonna
be
under
a
time
constraint,
an
emergency
or
maybe
just
doesn't
make
sense
for
a
certain
project
and
I
think
building
in
these
mechanisms
to
allow
for
an
override
and
empowering
developers
both
maintains
you
know,
their
experience
gives
them.
Power
gives
them.
A
Visibility
gives
them
access
to
make
those
to
help
make
those
decisions
or
inform
those
decisions,
but
then
I
think
that
it
creates
this
more
holistic
solution
that
allows
you
know,
developers
and
organizations
to
work
together
to
figure
out
what
works
for
them.
So
so
that's
where
we're
at
today,
we've
had
plenty
of
validation,
at
least
on
the
first
proposal,
so
I
think
we're
good
to
go
there.
A
From
that
perspective,
we
validated
this
particular
issue
with
only
one
customer
so
far
and
the
feedback
was
positive,
so
we
have
more
validation
to
do
on
this
particular
proposal,
but
every
you
know,
generally
speaking,
the
conversations
I've
had
point
to
this
is
a
sufficient
and
positive
way
to
solve
for
this
override
aspect
of
compliance
pipelines.
Yeah.
B
B
I
wonder
if
the
MVC
is
just
being
able
to
like
you
said
at
one
point:
just
simply:
an
individual
is
able
to
go
ahead
and
get
like
a
merge
request,
merged
and
the
reason
that
I
I
think
that
maybe
we
start
this
as
a
very
broad
override
and
then
like
folk.
Get
it
focused
over
time
is
a
a
it
optimizes
for
the
developer,
developer,
experience
or
ferocity
and
be
like
thinking
about
it
at
the
job
level.
B
You
know
that
could
harm
I'm
trying
to
think
through
that
experience
and
what
it's
like
if
I
see
a
pipe
other
complex
pipeline.
It's
like
oh
well,
this
failed!
Well,
you
know,
I
have
the
permission
to
override
that
job,
and
then
the
pipeline
continues.
Oh
I
failed
again.
I
need
to
get
go
back
to
the
notification.
Go
back
to
that
pipeline.
You
know.
Go
ahead
and
proceed
I'd
failed
again.
B
B
A
No,
that's
that's
a
good,
that's
great
feedback
and
a
great
question
so
I
think
two-person
approvals
is
important
in
the
long
term,
but
I'm
supportive
of
the
the
more
iterative
short-term
proposal,
because
some
some
of
those
sort
of
side
conversations
I've
had
for
it
with
brainstorming
around
this
has
been
you
know.
Maybe
we
follow
I
think
it
was
the.
Is
it
the
secure,
secure
team
who
did
the
vulnerability,
check,
approval
rule,
and
so
maybe
we
can
do
a
combination
of
a
compliance
check.
A
B
Totally
totally
agree
that
make
sense
to
me,
so
let
me
summarize
kind
of
what
I
heard.
So
you
know
you
know
gitlab
the
application
kind
of
defaults
and
tries
to
optimize
with
the
developer
experience,
but
we
have
like
the
set
of
of
risk
minded
enterprises
that
you
know,
especially
those
that
are
regulated
by
some
compliance
framework
that
want
to
err
on
the
side
of
making
an
auditors
happy,
and
this
is
like
a
large
financial
company
here.
It
could
be
so
like
we
have
this,
this
spectrum
kind
of
like
on
this
side.
B
There
were
every
single
merge
request.
Every
just
go
commit
really,
so
you
know
what
do
we
do?
Well,
you
know
we.
It
sounds
like
what
you
want
to.
What
you're
trying
to
do
is
build
the
ability
for
enterprises
to
figure
out
where
they
lie
on
that
spectrum
and
then
have
an
escape
hatch
for
the
experience
that
we
can
always
default
to
trying
to
make
the
developer
experience
good
and
the
default
experience
that
it
sounds
like
you're
you're
advocating
for
is
the
left
hand
side,
which
is
like
all
these.
B
You
know
I
think
that
you're
thinking
the
right
way,
we
need
to
consider
and
always
try
to
protect
developer
experience,
make
sure
that
people,
though
we
can
maintain
a
high
level
of
velocity,
and
with
that
in
mind,
what
I
would
encourage
you
to
do
is
when
we
think
about
success
criteria
as
we
shift
this
kind
of
these
steps.
Iteratively,
it's
like.
B
Let's
make
sure
that
we're
measuring
things,
like
average
kind
of
make
it
through
put
for
an
instance,
that's
using
this
pre
and
post
the
average
time
to
merge
like
if
those
things
are
going
up
to
a
significant,
a
significant
degree.
We
may
want
to
rethink
things
if,
like
all
the
sudden,
you
know
an
instance
of
shipping
like
half
the
volume
merge
request
is
taking
twice
as
long
to
like
get
stuff
in
production.
B
You
know,
then
we
might
want
to
loosen
these
restrictions
and
rethink
kind
of
how
we're
handling
this,
but
I
think
that
you
know
if
we
have
our
eye
on
some
of
those
success.
Metrics
I
think
that
the
the
philosophy
and
the
roadmap
certainly
makes
sense.
There's
definitely
some
unanswered
questions
that
we
can
kind
of
work
on
the
answering
together,
but
I
think
I
appreciate
all
the
work
in
researching
that
you've
done.
Yeah.
A
Thanks
so
much
Jeremy
I
agree
with
all
of
that.
You
know,
and
we
are
working
on
some
other
things
in
the
compliance
group
like
API,
enabled
approval
rules
that
could
allow
customers
to
to
customize
when
some
of
these
checks
occur
and
take
some
of
it
out
of
the
pipeline,
and
so
I
think
we'll
be
able
to
provide
enough
flexibility
that
they
can.
You
know,
balance
things
in
a
way
that
makes
sense
for
them.
But
that's
just
to
your
point
of
hey
build
the
workflow.
B
Know,
there's
a
question
I,
don't
with
a
question
that
Sid
posed
in
like
a
conversation,
a
while
back,
which
was
you
know
what
white
white?
Why
can't
we
just
focus
on
making
or
like
the
auditor,
because,
like
this
customer,
is
ultimately
trying
to
create
a
set
of
evidence
that
pleases,
like
their
auditor
and
they're
kind
of
at
they're
kind
of
doing
whatever
their
auditors
asking
for?
B
Why
can't
we
approach
the
auditor
and
kind
of
improve,
like
our
you
know,
the
the
evidence
that
we're
creating
versus
doing
what
the
customer
is
kind
of
asking
for
here
because,
ultimately,
like
these
asks
from
the
customer,
are
based
off
of
their
audit
and
compliance
requires?
Yes,
so
why
can't
we
kind
of
approach
it
from
betting,
yeah.
A
A
So
let's
look
at
the
scope
of
your
systems,
resources
and
environment,
so
I'm
going
to
be
looking
at
and
then
show
me
the
the
company
policies
that
I
need
to
then
audit
against,
and
so
an
auditor
is
gonna
say
is
gonna,
read,
let's
say
an
sdlc
policy,
maybe
for
one
company,
that's
ten
steps
and
another
company.
That's
eighty
seven
steps!
A
Well,
the
eighty
seven
step
sdlc
company
is
gonna,
have
a
much
more
thorough
audit,
because
the
auditor
is
gonna,
say:
okay,
prove
to
me
that
you're
doing
all
of
these
things
you
say
you're
doing,
and
so
when
it
comes
to
generating
evidence,
you
know
we
are
working
towards
multiple
I.
Think
three
or
four
different
types
of
em
VCS.
Four
different
audit
reports
that
we'll
build
out
and
those
will
generally
serve
as
great
foundational
evidence
artifacts
that
companies
can
serve
up
to
their
auditors.
A
What
that
doesn't
solve
for,
though,
is
that
nuance
of
we
can't
make
a
report,
that's
specific
for
every
company
and
we
can't
make
a
process
or
a
feature
that
inherently
supports
every
company,
and
so
we
inherently
need
to
provide
flexibility
so
that,
if
company
a
says,
I
only
need
ten
steps
in
my
process.
So
I
can
easily
do
that
with
gitlab.