►
Description
In this webcast, GitLab Sr. Solutions Architect, Darwin Sanoy goes over how GitLab Premium enables new protections for mission-critical code complete with auditable change history to ensure compliance with internal processes.
Register for the part 2 of this series: https://about.gitlab.com/webcast/gitl...
Read more about our product vision: http://bit.ly/2IyXDOX
Learn about FOSS & GitLab: http://bit.ly/2KegFjx
Get in touch with Sales: http://bit.ly/2IygR7z
A
Okay,
hello
and
welcome
everyone
thanks
for
joining
us
today,
we
are
really
excited
to
have
you
on
in
this
webcast
we're
going
to
be
covering
a
really
interesting
topic.
We're
gonna
cover
rich
change,
controls
for
building
workflows.
You
can
trust.
My
name
is
Joel
I
lead
a
Solutions
Architect
team
here
at
gitlab
and
I'm
joining
you
from
Chicago
today,
where
it's
finally
stopped
snowing,
we'd
love
to
hear
where
you're
turning
tuning
in
from
so
feel
free
to
use
the
chat
function
to
say,
hi
tell
us
where
you're
from
before
we
get
started
just
a
couple.
A
Real
quick
housekeeping
items
first
feel
free
to
ask
questions
throughout
the
presentation.
You
can
use
the
Q&A
function
at
the
bottom
of
your
screen.
For
that
also
we
have
dedicated
time
for
questions
at
the
end
of
the
webcast.
You
can
go
ahead
and
send
your
questions
any
time
as
you
think
of
them,
and
we'll
be
sure
to
get
to
those
at
the
end.
If
you're
experiencing
any
technical
difficulties,
you
can
also
use
the
chat
function
to
get
in
touch
with
me
for
help
on
the
moderator.
Our
presenter
today
is
Darwin
san
toy.
A
A
git
lab
senior
Solutions
Architect
from
Pennsylvania
will
also
launch
a
poll
or
two
throughout
the
podcast
or
the
webcast
here.
So
we
can
learn
more
about
you
and
that
way.
Darwin
can
also
tailor
his
presentation
accordingly.
So
with
that
I'm
going
to
just
launch
our
first
poll
to
ask
you,
as
a
user
of
gitlab,
what
version
of
git
lab
you
might
be
using
you.
A
A
B
Who's,
they
really
excited
to
deliver
this
content
to
you
today
as
a
senior
Solutions
Architect
at
gate
lab.
It
is
my
job,
but
also
my
pleasure,
to
help
customers
understand
how
to
adapt
the
many
different
widgets
in
the
gitlab
toolbox
to
facilitate
their
DevOps
transformations
and
their
DevOps
workflows.
B
So
git
git
Lab
has
a
lot
of
rich
controls
that
you
can
apply,
but
it
kind
of
tends
to
end
up
being
like
a
box
of
Legos.
That's
all
mixed
up
and
I
used
to
play
with
Legos
as
a
kid
that
big
box
of
Legos-
and
sometimes
you
don't
know
all
of
what's
available
to
you.
So
we're
gonna,
take
you
through
and
try
to
give
you
some
information
on
exactly
what's
available
to
you
and
then
sometimes
you
don't
know
what
you
can
make
what's
with
what's
available
to
you.
B
So
we're
also
going
to
show
you
some
patterns,
what
you
might
make
with
those
controls,
and
some
of
these
controls
are
used
in
a
little
bit
different
way,
because
gitlab
is
a
git
ops,
oriented
system
when
it
comes
to
supporting
deployment.
So
with
that,
let's
jump
right
in
we're.
Gonna
go
through
a
bit
of
an
agenda
here
and
see
some
of
the
things
that
we're
gonna
cover.
B
So,
first
of
all,
we'll
talk
about
custom
user
groups
and
custom
user
groups
are
something
that
we
can
create
inside
of
git
lab
you're,
familiar
with
seeing
users
mixed
in
to
groups
with
repositories,
but
it
is
possible
to
create
specific
groups
that
are
dedicated
just
to
managing
users
and
create
them
in
a
kind
of
structure.
That's
very
similar
to
operating
system
groups,
which
you
may
have
had
experience
with.
B
So
we'll
take
a
look
at
what
you
can
do
there
that's
important,
because
custom
user
groups
can
then
be
used
in
many
of
our
gating
controls
and
our
gating
controls
cover
both
code
collaborations
so
making
sure
your
code
is
good
as
well
as
deployment
control,
so
making
sure
that
things
are
being
deployed
to
the
right
environments
in
a
proper
way.
So
we
have
to
use
those
gating
controls
for
both
of
those
types
of
activities
when
we're
doing
the
full
DevOps
life
cycle
inside
of
the
tool.
B
Well,
then,
talk
about
repos
and
merge
requests
as
workflow
building
blocks.
So
you
may
not
be
aware
that
there's
several
features
that
go
over
top
of
multiple
repositories
which
allow
us
to
then
use
repositories
as
sort
of
a
workflow
building
block.
So
we
don't
have
to
keep
all
of
our
workflow
in
a
single
repository,
even
though
we
may
be
using
a
code
base
to
target
many
environments,
we'll
also
talk
a
little
bit
about
any
de
facto
development
patterns.
B
So
if
you're
doing
micro,
services
or
other
patterns,
you
may
wonder
if
these
are
possible
and
what
some
of
the
options
are
within
gitlab
and
so
we'll
show
you
a
few
patterns
that
are
possible
once
we
give
you
the
component
tree,
we'll
show
you
some
pre
assemblages
of
it
kind
of
like
that
picture
in
the
back
of
the
Legos
box.
It
shows
you
hey.
This
is
what
it
should
look
like
when
you're
done
and
then
finally
we'll
talk
about
just
basically
reviewing
a
table
of
controls
by
their
get
lab
edition.
B
So
at
what
get
lab
Edition,
do
they
become
available
and
then
also
there's
scope.
So
what
do
they
affect?
An
entire
repo,
multiple
repos,
just
a
merge
request,
a
single
file
in
a
repository
so
give
you
that
scope,
information
and
then
will
also
indicate
where
a
custom
group
support
is
available
within
those
controls.
B
Let's
talk
just
a
little
bit
about
custom
user
groups
because
they're
a
fundamental
part
of
what
we'll
be
talking
about
so
the
history
of
group
structures
in
get
collaborative
solutions
is
really
that
we
only
had
one
resource
type
repositories,
so
it
really
evolved
that
we
hey.
We
have
some
groups
of
repositories
and
we
want
to
group
them
together
and
then
we
want
to
assign
users
to
build
and
manage
the
repositories
within
that
group
or
manage
within
the
individual
repository,
and
so
that's
kind
of
why
the
git,
collabora
solutions
all
have
this
kind
of
effect.
B
Where,
if
you
come
from
the
operating
system,
world
you're
like
well,
hey
where's,
the
user
groups,
why
are
they
all
mixed
in
with
the
resources?
That's
because
there
was
really
only
one
resource
type
to
manage.
So
over
time,
gitlab
has
developed
the
capability
to
have
the
resource
groups
separated
from
user
management
groups.
Custom
user
groups
can
be
used
in
many
different
places
for
gating
controls,
and
so
we
move
to
the
next
slide.
B
We
can
also
create
a
dedicated
groups
hierarchy
just
for
users,
so
we
separate
our
groups
of
users
from
our
repositories
and
then
assign
them
in
users
and
if
you've
been
doing
operating
system
groups.
You
know
this
is
a
best
practice
right
off
the
bat,
don't
assign
users
to
individual
resources
now.
Instead,
we
want
to
always
assign
them
to
groups
to
what
degree
you
adhere
to
that
kind
of
operating
system,
orientation
or
directory
group
orientation
will
be
up
to
you,
but
will
at
least
give
you
the
enablement
to
be
able
to
do
that.
B
So
within
a
group,
if
you
check
in
a
group
that
you
have
a
maintainer
or
higher
permissions
and
you
look
into
its
settings,
there'll
be
a
subsection
for
permissions,
and
these
two
little
permissions
are
kind
of
looking
and
oculis
like
they
don't
do
much,
but
they're
actually
quite
powerful.
So
the
first
one
allowed
to
create
groups.
B
Also,
you
can
delegate
group
membership
management.
So,
if
you're
like
hey,
we
got
50
teams
here,
I'm,
not
interested
in
being
constantly
having
tickets
come
in
to
add
this
user
to
that
group.
If
you
make
a
user
a
maintainer
of
one
of
these
groups,
then
they
can
add
and
remove
users
from
that
group.
So
you
can
essentially
delegate
that
membership
management.
In
addition,
it's
important
to
keep
in
mind
that
the
source
group
role
has
no
bearing
on
new
assignments.
B
B
So
if
you
make
someone
a
member
of
a
group-
and
it
has,
three
sub
groups
are
automatically
a
member
of
those
sub
groups,
and
so
one
of
the
things
you
want
to
keep
in
mind
is
to
not
put
people
in
those
intermediary
groups.
It's
actually
best
if
you
create
your
structures.
So
there's
no
need
to
ever
put
someone
in
some
sort
of
intermediary
or
higher
up
group
that
all
memberships
go
in
the
lowest
level
groups.
So
if
you
were
to
create
a
structure
yourself,
that's
dedicated
to
users
only
then
it
might
look
something
like
this.
B
If
you've
been
around
operating
system
groups
for
a
while,
you
can
see
here,
I've
tried
to
help
people
understand
with
no
users
in
this
group.
That's
just
the
description
of
the
group
and
it's
making
making
a
declaration
both
that
no
users
should
be
added
if
you're
an
admin,
and
it's
also
making
a
declaration.
B
If
you
go
to
select
this
group
somewhere
that
there's
no
users
in
it,
so
don't
use
it,
but
that
might
be
hard
for
people
to
remember,
because
the
descriptions
not
always
displaying
whenever
we
go
to
select
the
group
so
well,
this
structure
is
tempting
and
it
might
be
necessary.
If
you
do
so.
You
have
to
be
sure
that
everyone
understands
you
only
ever
assign
users
to
the
bottom
level
groups
and
then
you'll
also
need
a
kind
of
a
group.
Click
in
the
case
of
s
are
easier.
You
can
see.
B
We
have
an
all
sres
group,
so
that's
the
one
that
actually
contains
all
the
s
Ari's,
not
the
group
above
it
and
then
any
breakouts.
We
have
of
the
individual
sres
for
different
purposes.
We
would
create
sub
groups
underneath
that
group,
probably
a
better
structure
if
you
can
handle
it.
So
if
you
don't
have
7,000
groups
and
it
becomes
really
hard
to
manage-
is
to
have
a
flat
structure,
and
here
we
can
see
that
the
naming
convention
kind
of
indicates
a
hierarchy.
B
B
This
challenge
take
a
look
at
the
screen
at
both
of
them
and
they
have
a
Prada
provers
group
in
various
different
areas,
and
what
this
is
emphasizing
is
that
when
we
deploy
to
an
environment
we
want
to
maybe
have
special
users
that
are
production
approvers
and
only
they
can
do
production
approvals.
Now,
if
you
have
the
premium
or
up
level
product,
then
you
can
do
multiple
people
from
different
group
sets.
B
So
you
can
say:
I
want
one
production
approver
from
sres
one
production
approvers
from
security
and
to
production
approvers
from
application
a
in
the
starter
product.
You
can
only
specify
one
set
of
groups
and
users
and
roles
and
then
a
total
number
of
approvers
for
that,
so
you
just
have
one
approval
rule,
so
in
that
case,
you'd
probably
want
to
have
something
like
app
a
production,
approvers
and
then
add
someone
from
security.
Add
someone
from
in
from
sres
and
a
few
developers
or
the
entire
development
team.
B
That's
a
little
bit
more
manual
and
you
can't
have
the
delegated
permissions,
but
at
least
you
can
still
accomplish
somewhat
like
that.
But
of
course,
if
you
say,
I
want
four
approvers
and
there's
20
people
in
there.
If
someone
could
leave
out
someone
from
security,
so
premium
gives
you
a
lot
more
flexibility
in
controlling
a
bunch
of
rules
for
different
user
groups
and
how
many
approvals
you
need
from
each.
So
that's
the
concept
of
custom
user
groups,
it's
fairly
strong
in
gitlab.
All
you
have
to
do
is
say:
hey
we're
going
to
create
a
structure.
B
It
only
contains
users
then
turn
on
these
two
settings
and
all
of
those
groups
and
start
controlling
how
users
are
added
to
those
groups
and
then
use
those
groups.
Whenever
you're
assigning
permissions
to
your
repository
groups,
we're
gonna
shift
gears
now
and
talk
a
little
bit
about
the
gating
controls
that
we
have
now
because
git
lab
is
a
git
ops,
oriented
product
and
supports
the
full
DevOps
lifecycle.
It
has
these
gating
controls
both
for
code
review,
which
is
something
that
you're
familiar
with
all
code
systems.
B
A
source
control
management
systems
have
this
kind
of
concept
of
let's
collaborate
and
make
better
code
changes
and
mission,
sure
that
everybody's
approved
it
and
everything,
but
then
also
environment,
change
control
becomes
a
concern
for
deployment.
So
when
we
do
a
deployment,
we
also
can
use
these
same
gating
controls
to
control
deployments.
So
we'll
start
with
the
initial
and
well-known
model
of
using
it
for
code
integration.
B
So
we
have
our
one
code-
integration
branch
here,
which
is
where
we'd
hope
that
all
developers
merge
their
feature
branches
before
they
go
any
further
and
the
first
control
set
that
we
have
is
a
push
rule.
A
push
rule
and
pre-commit
hooks
actually
and
push
rules
are
like
a
firewall
for
our
repository,
so
they
basically
say
I.
Don't
ever
ever
want
to
see
this
in
my
repository
and
don't
want
anyone
to
be
allowed
to
commit
it
if
they
have
it
they're.
A
great
example
secrets
so
committing
some
AWS
keys
into
the
repository
is
a
problem.
B
Now
we
could
look
for
them
in
CI
and
say
hey
if
you
find
any
keys
flag,
it
fail
the
build.
The
problem
is,
we
may
not
have
a
build
set
up
on
that
branch
or
we
do
find
it.
We
decide
we're
gonna
fix
it,
but
now
and
get
in
order
to
completely
cleanse
that
secret
forever.
We
have
to
go
in
and
force
rewrite
history,
which
is
a
usually
a
no-no
for
most
organizations,
git
flow.
So
it's
a
very
bad
thing
for
those
credentials
to
even
hit
the
repository
one
time.
B
B
Misidentifications
of
who
made
the
code
signed
commits,
says
that
we're
gonna
sign
the
commits
with
code
signing
so
that
we
know
that
that
commits
as
you
committed
it
has
not
been
played
with.
Since
it's
been
sitting
in
your
local
repo
and
before
I
got
pushed
into
our
master
copy
on
the
on
the
server,
so
sign
commits
and
verified.
B
Committers
together
gives
you
a
very
high
level
of
traceability,
of
a
code
change
right
back
to
an
individual,
and
this
can
be
important
for
some
organizations
if
they
deal
with
a
lot
of
contractors
and
they
really
want
to
know
what's
been
going
on
in
terms
of
commits
or
if
you
work
for
any
highly
secure
organization
or
government
organization,
where
it's
really
important
to
know
where
the
code
came
from
right
down
to
the
fingers
that
tapped
it
out.
So
this
is
a
great
set
of
features.
If
you
have
any
of
those
kind
of
needs.
B
Another
control,
which
is
a
pre-commit
hook,
is
locked
files
and
directories.
You
can
think
of
this
as
a
person
putting
a
semaphore
on
a
file
across
the
entire
repo
they're,
basically
saying
I'm
going
to
be
playing
with
this
file.
I,
don't
want
anyone
else
to
be
able
to
commit
to
any
branch
anywhere
in
the
repo
if
it
contains
this
file,
because
only
one
of
us
is
supposed
to
play
with
it
at
a
time,
and
so
locked
files
and
directories
is
a
feature
that
allows
you
to
do
exactly
that.
B
So
now
we
start
getting
some
feature
builds
and,
of
course,
different
developers
are
working
on
different
features.
They
commit
their
features
up
to
get
gitlab,
and
then
we
have
the
capability
to
start
working
with
them
with
the
CI
CD
components
of
the
system.
One
of
the
cool
things
with
git
lab
is
for
free.
You
get
Enterprise,
capable
production,
ready,
full-on
CI,
and
that
capability
is
very,
very
strong.
You
can
craft
all
kinds
of
different
workflows
that
you
might
need.
B
So
this
kind
of
pause
is
really
happening
at
the
workflow
level.
So
there's
no
container
waiting
around
just
get
lab
itself
knows
hey.
This
pipeline
is
on
pause
until
someone
continues
it.
So
that's
really
a
decent
gating
control,
but
there's
no
assignment
of
users
about
it.
Basically,
people
who
are
a
repo
maintainer
or
if
you
open
up
developer,
can
press
that
play
button,
but
it's
not
assignable.
So
we
know
who
pressed
the
play
button
necessarily
and
require
certain
people
to
review
it
before
they
press
the
play
button
want
to
get
labs.
B
B
One
of
the
things
that
we'll
just
mention
briefly
is
a
security,
compliance
scanning
and
dashboard
that
you
get
with
the
ultimate
package.
This
allows
you
to
start
seeing
some
problems
at
the
repo
level
and
later
on,
we'll
talk
about
at
higher
levels
as
well
to
understand
what
kind
of
security
challenges
your
code
bases
are
undergoing,
and
so
today
we're
talking
mostly
about
premium
and
moving
from
starter
to
premium.
But
that's
one
feature
we
wanted
to.
B
Then
tag
protections
are
also
available.
So
a
lot
of
people
use
tags
to
indicate
very
important
things
about
code,
like
an
official
version
number
official
release
number.
So
we
can
also
add
tag
protections
with
custom
groups
with
the
starter
version
and
that
will
help
us
protect
tags
from
being
updated
for
the
specific
users.
So
users
can't
move
a
version
tag
unless
you're
in
that
group
premium
adds
multiple
approval
rules.
So
I
just
mentioned
that
briefly
before.
B
If
you
want,
one
form
is
oh
one
from
sre
and
three
from
the
development
team
and
someone
else
to
speak
into
this
particular
review.
Well,
then,
you
can
specify
them
separately
in
those
rules
and
all
the
rules
have
to
be
met
before
the
merge
will
be
allowed
to
proceed
now.
A
lot
of
our
controls
happen
in
merges
and
there's
more
of
them
that
we'll
talk
about
in
the
tables
that
indicate
the
different
features
that
we
have
at
the
merge
approval
level.
B
But
those
are
some
of
the
highlights
and
the
premium
highlight
then,
when
we
go
into
after
we
done
our
code
review
and
we
go
to
push
code,
only
certain
people
are
allowed
to
merge
the
code,
and
this
is
called
branch
protections,
so
when
only
certain
people
are
allowed
to
merge
it,
we
can
also
specify
custom
groups
in
here.
So
we
can
say
one
custom
group,
only
people
in
say,
production,
approvers
or
final
code
review
are
allowed
to
merge
to
this
branch.
Then
we
can
have
even
more
control,
and
that
is
a
starter
feature.
B
B
If
this
merge
is
going
to
succeed
or
have
a
problem,
one
of
those
premium
features
that
we'll
touch
on
later
is
that
when
you
do
this
merge,
you
definitely
can
fail
a
build,
but
maybe
we
want
to
not
allow
the
merge
unless
that
builds
gonna
succeed.
So
how
do
we
do
a
predictive
build?
So
we
have
something
called
builds
for
merges
that
does
a
separate
build
as
if
the
code
was
merged
before
merging
it.
B
So
just
write
on
your
CI
age
and
it's
gonna
merge
the
code
and
run
the
build
and
be
able
to
tell
you
whether
that's
gonna,
succeed
or
fail
without
actually
merging
the
code,
which
is
a
really
awesome
feature,
so
you
can
then
say,
builds
have
to
succeed
and
by
the
way
my
merge
commit
build,
failed,
so
I
without
even
merging
it.
I
know
that
it's
going
to
fail.
So
that's
really
powerful
for
merge,
merge
approvals.
B
Then,
if
we
are,
if
this
particular
repo
also
supports
deployments-
oh
I'm,
sorry
I'm
gonna
skip
over
this
over
here,
we
also
have
protected
environment
gating
with
premium.
So
when
you
deploy
to
an
environment,
you
can
say
only
these
individuals
can
actually
do
that
final
stage
of
deploying
to
a
given
environment,
it's
similar
to
branch
protections,
but
it's
oriented
around
the
target
environment
that
you're
pointed
at,
and
so
this
is
another
way
to
start
control.
Who
is
exactly
allowed
to
push
to
certain
Department
environments?
Now,
usually
on
an
immigration
branch
or
especially
feature
branches?
B
You
don't
care
like
feature
branches.
You
want
every
developers
building
code
to
be
able
to
push
out
to
that
environment
because
it's
isolated
and
you
want
to
see
if
it's
working,
but
as
we
get
further
and
closer
towards
production.
You
usually
want
this
more
and
more
constrained.
So
that's
a
premium
feature
as
well.
B
Now,
with
git
ops,
we're
going
to
start
using
branches
now
for
deployment
so
and
you've
know
that
you
use
branches
for
code
development,
but
even
once
code
is
done
developing
we
can
start
to
use
branches
and
merging
to
deploy
it
to
production
environments,
and
so
in
this
case
we
can
have
an
individual
gates
that
have
to
do
with
those
branches
at
the
branch
protection
level.
So
our
merge
approvals,
the
big
great
gate
applies
to
every
branch,
and
then
our
branch
protections
can
apply
to
individual
branches.
B
If
you
need
something
where
you
need
merge
approvals
that
are
different
by
branch
well,
then
we
could
separate
it
into
different
repositories
and
start
to
get
that
particular
granularity.
So
some
of
the
things
we
have
at
the
branch
protections
level,
four
for
free-
you
have
branch
protections
by
a
roll,
so
you
can
say
only
developers
can
merge
to
this,
or
only
maintainer
can
merge
to
this
branch.
Then
in
starter
we
have
users
and
custom
groups
can
be
specified
and
finally,
in
premium
code
owners
can
be
specified
now.
B
Code
owners
is
something
that's
developed
within
the
git
community
around
having
more
control
over
specific
files.
So
sometimes
some
files
are
so
important
or
so
specific
that
we
want
only
certain
users
to
be
allowed
to
approve
those
changes
to
those
files
or
groups
of
users,
and
so
code
owners
can
be
set
up
as
a
branch
protection
that,
if
you
know,
amongst
all
the
merge
approvals
that
you
gave
no
code
owner,
was
specified
or
no
code
owner
approved
it
for
XYZ
file,
which
has
a
code
owner
identified,
then
we're
gonna
block
you.
B
B
So
this
a
lot
of
information,
a
lot
of
gating
controls,
so
this
is
kind
of
like
your
pile
of
Legos
and
what
all
the
different
pieces
and
parts
might
do,
but
because
we
unpacked
it
slowly,
I'm
hoping
that
you
kind
of
get
a
concept
of
where
some
of
these
things
can
be
used.
We're
now
gonna
use
these
ideas
and
try
to
block
them
together
to
help
you
understand.
B
Some
other
features
of
the
system,
so
if
we
have
an
entire
repository
workflow
and
we
want
to
start
linking
repositories
together
and
also
linking
different,
merge
requests
together,
we
can
start
to
get
some
new
functionality.
One
of
the
things
we
add
in
premium
is
an
ops
dashboard.
So
all
these
operating
environments,
you
can
check
out
what
versions
deployed
there.
How
healthy
are
they?
What
was
the
last
deployment?
And
so
you
can
create
that
ops
dashboard
over
all
the
operating
environments.
In
a
repository,
we
also
have
something
called:
merge
trains
and
merge.
B
Trains
are
when
multiple
merge
requests
need
to
succeed
as
a
group
in
order
for
us
to
continue,
but
we
have
no
order
dependencies,
so
we
say:
hey
these
three
merge
requests
need
to
complete
successfully
so
that
we
can
move
forward,
but
we
don't
want
to
wait
for
each
one
because
then
someone's
gonna
make
another
commit
and
the
whole
thing
is
gonna
start
over
again.
We
want
to
get
through
them
as
quickly
as
possible,
since
we
have
no
sequence
dependencies,
let's
just
run
them
in
parallel
and
that's
basically,
what
a
merge
train
is.
B
It
lets
you
associate
those
together
and
it's
within
the
context
of
a
repository.
In
this
case,
three
merge
requests
in
the
same
repository.
We
also
may
have
multiple
repositories.
So
if
we
start
linking
repositories
together
to
get
certain
effects
and
micro
services
is
one
example
that
we
might
do
this
for
then
we
can
start
using
environment,
roll-up
dashboards,
and
these
allow
the
various
environments
across
many
projects
to
roll
up
in
a
group
context,
so
we
can
start
seeing
what's
going
on
across
multiple
environments.
B
In
addition,
the
security
and
compliance
roll-up
rolls
up
as
well,
and
it
rolls
up
as
many
group
levels
as
you
have,
and
then
we
can
start
using
something
called
merge,
request,
dependencies
and
merge
request.
Dependencies
can
be
within
the
same
repository
or
across
repositories,
and
what
this
basically
lets
us
do
is
to
start
to
link
repositories.
B
We're
saying
these
merge
requests
depend
on
one
another,
but
they're,
also
sequentially
dependent,
so
merge
requests
one
and
repo
one
would
have
to
complete
successfully
for
merge
request
to
in
repository
one
to
go
ahead
and
then
be
capable
of
completing
and
so
on.
So
all
of
these
dependencies
are
sequential
and
have
to
wait
for
the
build
steps
of
the
previous
merge
to
complete.
So
those
are
merged
dependencies
and
we
have
a
little
bit
of
more
information
about
each
one
of
these.
B
So,
let's
talk
a
little
bit
about
some
patterns.
What
we
have
here
is
a
micro
service
pattern
that
is
twelve
factor
compliant
and,
if
you're
familiar
with
twelve
factor,
it
basically
says
that
for
each
micro
service,
you're
gonna
have
a
repository,
and
when
you
have
a
repository
for
each
one,
you
also
build
a
deploy
independently
or
dependently.
So
you
can
say:
hey
we
updated
two
services
and
both
need
to
be
updated.
B
In
order
for
this
new
functionality
to
work,
then
you
can
link
those
together
in
this
case
with
merge,
request
dependencies
or
you
can
also
have
these
deploying
independently.
If
your
micro
services
are
that
independent
of
one
another,
so
a
12
factor
micro
service
capability,
no
problem
also,
you
might
have
a
situation.
We
have
customers
who
are
software
companies
and
they
have
to
deploy
the
same
exact
software
to
multiple
stacks.
B
Sometimes
this
is
customer
tenants,
so
every
customer
has
their
own
kind
of
stand
up
and
they
need
to
be
able
to
vary
the
version
by
customer
or
only
update
the
customer
and
the
customers
ready.
So
this
is
showing
three
repositories
each
generating
artifacts
and
then
those
artifacts
being
reused
in
deployment
only
repositories,
and
so
we
can
have
those
merge
controls
available
in
order
to
push
that
code
out
a
lot
of
times.
This
has
to
do
with
individual
customer
config,
so
the
all
that
would
be
in
the
environment.
B
Another
possible
scenario
is
having
repose
as
building
blocks
for
Siddhi
push
only
so
a
lot
of
people
are
familiar
with
products
that
only
do
CD
and
they
are
very
sophisticated
around
just
getting
code
artifacts
out,
and
this
is
another
thing
that
can
be
done
in
gitlab
as
well.
So
as
you've
seen
this
flow,
we
know
that,
at
the
end
of
the
day
on
our
production
line
at
the
bottom,
we
can
go
ahead
and
push
through
an
environment.
B
But
what
you
may
not
know
is
we
could
also
push
with
some
different
tags
and
target
a
different
environment,
maybe
with
a
different
version,
and
so
we
don't
really
have
any
kind
of
limitation
on
how
many
times
we
do
a
deploy
once
we
do
a
build.
So
in
this
way
we
can
have
one
a
you
know,
a
more
situation
where
we
have
a
lot
of
target
environments
for
the
same
exact,
build.
What
we
do
potentially
lose
here
is
our
merge
request
capabilities.
B
So
at
this
point
we
only
really
have
protected
environments
capability,
so
listing
list
of
users
or
a
group
of
users
that
are
able
to
approve
this
push,
and
that's
the
only
control
we
have.
So,
if
you
need
more
collaboration,
you'd
want
to
drive
this
back
to
a
merge
request
in
order
to
enable
it,
but
we
can
do
this
model
as
well.
B
Let's
take
a
look,
so
that's
kind
of
some
patterns
as
well
as
some
of
the
capabilities.
I
want
to
go
through
now
kind
of
a
table
view
of
the
control
scope,
whether
we
have
group
capability
and
what
Edition
each
of
these
capabilities
comes
into
so
on
the
screen
here,
we've
covered
most
of
this
already,
one
that
we
haven't
covered
is
resetting
approvals.
B
When
code
is
pushed,
so
you
can
go
ahead
and
say
hey
if
someone
pushes
a
new
commit
reset
all
the
approvals
everybody's
got
to
approve
again
high-impact,
but
it
might
be
necessary
depending
on
your
situation.
You
can
say
pipelines
must
succeed,
and
this
is
where
we
can
also
link
this
with
the
premium
feature
of
pre
merge
pipelines.
So
the
pre
merge
pipeline
must
succeed
in
order
for
us
to
approve
a
merge
request.
All
review
discussions
must
be
resolved
is
where
we
say
hey.
B
If
someone
started
some
concerns,
when
you
comment
your
code
in
review
in
a
merge
request,
you
can
either
create
it
as
a
comment
which
is
basically
hey.
Here's
some
info
or
you
can
hit
start
review
and
when
you
do
that
process,
you're,
basically
saying
I,
don't
want
you
to
ignore
my
input.
I
want
you
to
work
through
it
and
then
we'll
hit
resolve
discussion
when
everybody's
happy,
and
so
that
is
supported
with
core
as
well.
Finally,
preventing
merge,
threading
anyone
who
either
authored
the
merge,
requests
or
authored
any
of
the
code
from
being
a
approver.
B
So
basically
saying
hey
if
you're
the
ones
promoting
this
change,
you're
trying
to
get
it
through
we're
gonna
just
say
that
it
has
to
be
completely
other
people
that
approve
it.
So
we
get
a
lot
of
eyes
reviewing
it.
We
don't
have
basically
the
curse
of
expertise
if
you've
been
working
on
a
bit
of
code
for
a
week
straight
guess
what
you're
not
the
best
person
to
review
it,
because
if
there's
mistakes
and
it
you've
already
looked
at
the
mistakes
a
thousand
times
and
will
probably
let
them
through.
B
B
One
that
we
haven't
discussed
is
merge,
request,
reviews
so
I,
don't
know.
If
you've
had
this
experience
but
I've
gone
in,
made
a
comment
on
someone's
code
and
said:
hey,
you
really
ought
to
consider
XYZ
code
for
lines
down
in
the
diff
and
see
there's
where
they
considered
XYZ.
So
guess
who
looks
dumb
and
has
to
erase
the
comment
or
say:
oh
I
see
it's
already
handled.
Meanwhile,
everyone's
gotten,
an
email
saying
that
you
have
a
code
concern
so
merge
requests.
B
Reviews
allow
you
to
bulk
edit
all
of
your
comments
at
once
and
then
publish
them
all
at
once,
so
that
you
can
make
sure
they're
consistent
within
themselves.
So
that's
a
really
helpful
feature.
Hi
and
I
think
we
talked
about
everything
else
on
this
slide.
Oh
I
guess
overriding
merger
quest
approvals,
so
normally
merger
crests
approvals-
you
set
them
in
the
repository
and
every
merge
request
created
that
repository
must
comply
and
it's
the
point
of
policy.
If
it
doesn't
comply,
it
doesn't
work.
B
However,
if
you
change
this
setting,
you're
basically
saying
these
are
actually
the
suggested
configuration
I,
trust
the
person
who's
allowed
to
make
merge,
requests
to
make
alterations
and
say
you
know
what
we're
updating,
documentation
I.
Don't
think
anyone
from
security
really
want
to
spend
the
time
to
approve
that,
so
you
can
knock
off
the
approvers
for
security
for
Docs.
Only
changes
would
be
an
example.
B
B
We
have
users
and
admins,
and
then,
when
you
premium,
you
have
a
class
called
audit
and
when
you
use
that
those
users
have
read
access
to
everything
in
your
instance
or
group
structure
and
what
that
allows
them
to
do
is
to
do
their
job
of
auditing
code
or
maybe
secured
security
audits
without
having
to
be
added
to
every
repository
in
the
system.
We
also
have
audit
events
that
are
in
the
GUI,
so
you
can
see
when
people
change
things.
B
So,
if
someone's
a
maintainer
and
they
go
change
a
group
so
that
they
go
change
a
setting,
so
they
can
add
a
subgroup,
then
add
the
subgroup
and
then
change
the
setting
back.
So
it
doesn't
look
like
they
have.
The
setting
you're
gonna
have
an
audit
event
and
be
able
to
understand
that
that
happened.
I
also
didn't
mention
that
in
all
merge
requests
you
have
audit
events
automatically
added
to
the
log.
All
the
time
so
people
check
a
check
box
in
a
markdown
check
box.
It's
in
the
body
of
the
merge
request.
B
It
records
that
and
you
can
see
who
checked
it
or
unchecked
it,
and
when
so,
there's
audit
capability
built
in
running
at
that
level
as
well.
We
also
have
additional
audits
events
that
are
available
through
the
API
and
you
get
those
with
premium
and
then
just
dropping
down.
We
covered
protected
environments,
all
those
and
then
security
approvals
and
license
compliance
Kapoor
VLEs.
B
Basically,
if
you
can
set
the
whole
instance
so
that
if
someone
is
accepting
code,
so
developers
are
allowed
to
say
ignore
this
vulnerability,
but
if
they
do
that
on
a
vulnerability
that
has
not
been
reviewed
by
security
before
then,
we
can
require
that
security
must
do
an
approval.
We
can
do
the
same
if
they
accept
a
blacklisted
license.
So
the
license
has
been
blacklisted.
Someone
decides,
you
know
what
I'm
just
going
to
slip
this
one
through
all
of
a
sudden
security
has
to
be
able
to
review
that.
B
So
what
we've
gone
through
is
custom
user
groups
that
it's
a
very
real
and
strong
concept
within
gitlab.
You
just
have
to
know
a
few
little
secrets
about
creating
groups
that
are
dedicated
and
setting
a
couple
settings.
Those
gating
control
are
used
for
both
code
collaboration
and
deployment
control
and
in
many
places
the
custom
user
groups
can
be
used
to
do
that.
B
Also
repositories
and
merger
quests
can
also
be
used
as
workflow
building
blocks,
so
using
them
above
a
set
of
repositories
where
the
repositories
are
actually
components
of
your
workflow,
rather
than
kind
of
the
top-level
concept.
Every
workflow
we
also
enabled
de
facto
development
patterns
such
as
my
croissant,
a
repo
is
one
that
we'll
be
covering
in
a
future
session
next
week.
Actually,
so
you
might
want
to
pick
that
up
if
you
use
mono
repo
instead
of
the
twelve
factor.
Type
model
also
controls
by
addition
and
control,
scope
and
custom
group
support.
B
So
if
you're
one
of
the
kind
of
workflow
architects,
you
usually
want
to
know
what
are
all
the
pieces,
what
context
or
scope
do
they
apply
to
and
can
I
use
very
interesting
things
like
custom
user
grips
in
them,
so
that's
what
that
table
is
all
about
is
helping.
You
work
your
way
through
that
so
I
hope
that
that's
given
you
a
good
overview
of
the
richness,
that's
available
and
some
of
the
ways
we
can
assemble
that
component
tree
to
a
suit.
Your
workflows
and
I
just
like
to
open
it
now
up
to
any
questions.
A
Okay,
thanks
Darwin,
and
if
you
have
any
questions,
do
you
want
to
enter
at
this
time?
You
may
there's
only
one
current
question
and
that
basically
Darwin
was
around
the
code
review
function.
So
if
you
could
share
kind
of
what
that
looks
like,
we
talked
a
lot
about
merge,
requests
and
things,
but
there's
kind
of
a
generic
question
on
code
review.
Okay,.
B
B
But
as
we
look
at
the
single
source
of
truth
for
change
management,
we
can
start
to
get
a
view
of
what's
going
on,
so
this
particular
pipeline
passed
all
of
our
phases
passed
and
if
we
wanted
to,
we
can
dig
into
the
individual
logs
and
find
out
exactly
what
happened
right
down
to
the
level
of
every
detail
within
that
particular
build
step.
This
particular
build
also
for
a
branch
built
us
a
review
app,
so
we
can
open
up
and
see
exactly
what
the
app
looks
like
at
this
level.
B
This
is
obviously
a
very
simple
app,
but
if
you
had
some
changes
that
you
want
to
visibly
verify,
you
could
do
so
or
functionality
changes.
In
addition,
we
can
see
who
our
recruit
approvals
are
required
from.
In
this
case,
we
just
have
one
group,
but
we
could
have
multiple
groups
here.
We
can
view
the
eligible
reprove
errs
find
out
who
has
approved.
We
also
have
roll-ups
of
any
security
scanning
and
license
scanning
that
happened
within
this
workflow.
So
in
the
phases
here
we
have
multiple
security
possibilities
of
what
might
be
tested.
B
We
can
have
a
bunch
of
sass
checks
for
various
vulnerabilities
in
your
source
code
and
then,
if
you're,
how
using
review
environments,
we
can
also
check
for
vulnerabilities
in
your
compiled,
finished
application
from
the
front
end
and
so
those
all
roll
up
into
the
security
panel
you
so
here
we
can
see
all
the
various
Molnar
abilities
that
were
found.
We
can
take
action
on
those
various
mul
nur
abilities.
We
also
have
the
capability
to
break
it
down
by
report
type.
So
all
security
scanning
comes
up
as
some
people.
Sometimes
people
ask
this
question.
B
B
We
assume
you
just
want
to
see
the
top
level
view,
but
you
can
start
to
dig
into
which
is
which
we
also
have
the
licenses
panel,
which
was
linked
from
the
initial
merge
request,
and
this
allows
you
to
see
what
licenses
are
in
play
and
which
ones
might
be
blacklisted,
which
ones
might
be
new
since
the
last
time
the
code
was
compiled
and
so
that
license
panels
available
right
here,
so
you
could
click
through
from
there.
We
have
a
merge
conflicts,
so
we
know
we
have
to
resolve
that
before
moving
forward
and
down.
B
Here
is
where
you
can
see
what
kind
of
things
were
going
on.
So
this
is
an
audit
log
for
the
merge
request
and
you
can
see
what
kind
of
actions
were
taken.
Interestingly,
if
we
had
some
check
boxes,
this
only
says
closes
137,
but
if
we
had
a
checklist
in
here
as
people
check
the
items
off,
it
also
appears
down
here.
B
So
it's
another
way
to
add
kind
of
some
approval
capabilities,
or
at
least
a
checklist
that
must
be
getting
done
and
you
don't
really
care
who
does
each
step
and
finally
down
here
we
see
a
merge
or
a
review,
so
someone's
saying,
hey.
Here's
some
I
have
some
concerns
about
this
code
and
we
need
to
make
sure
that
they
get
resolved.
B
So
if
there
was
an
ongoing
discussion
and
some
code
got
changed
or
got
justified,
why
it's
the
way
it
is,
then
the
person
who
started
the
thread
could
hit
resolve
thread
and
that
would
stop
blocking
our
merge
requests.
So
all
of
these
controls
kind
of
come
together
here
and
we
can
block
merge
based
on
all
the
different
triggers
and
capabilities
that
we
discussed
in
our
sessions.
A
All
right,
excellent,
we
don't
have
any
additional
questions
at
this
point
in
time.
So
I'd
like
to
just
say
you
know:
Thank
You
Darwin,
for
a
very
informative
session,
thanks
everybody
who
attended
for
for
joining
us.
We
are
actually
doing
a
second
webcast
coming
up
next
week
and
that
will
be
on
the
the
use
of
CI
cd44,
robust
pipelines
or
pipeline
visibility
and
some
more
complex
use
scenarios
and
so
feel
free
to
join
us.
A
Then,
and
if
you're
interested
in
learning
other
things
further
about
gate
lab
premium,
you
can
join
us
and
ping
us
using
the
link
that
you
see
here
on
the
screen
with
that.
Thanks
for
joining
us,
we'll
be
sending
over
the
recording
from
this
webcast
in
the
next
few
days,
so
keep
an
eye
out
for
it
and
enjoy
the
rest
of
your
day.
Thank
you
very
much
thanks.
Everyone.