►
From YouTube: Solutions Architecture GitLab Building Block Index for Workflow Control for CI and GitOps CD
Description
Working Examples with Detailed Tutorials:
- Terraform Deployment to AWS: https://url2go.to/glawstf
- Serverless Framework to AWS: https://url2go.to/glawssls
A
Hello:
everyone,
it's
Darwin
from
gitlab
today,
I
want
to
chat
with
you
a
little
bit
about
something
we
get
a
lot
of
questions
about
and
that's
what
are
all
the
little
levers
and
knobs
in
git
lab
that
will
allow
you
to
build
workflow
controls
that
help
you
with
your
CI
and
CD.
So,
let's
Dive
Right
into
this.
A
The
first
thing
I
want
to
point
out
is
that
we're
going
to
be
talking
about
a
Solutions
architecture
perspective.
So
a
lot
of
times
we
get
questions.
Does
the
product
have
feature
XYZ
or
do
you
have
a
feature
to
do
such
and
such
and
that's
the
domain
of
product
engineering
and
product
architecture?
We
have
substantial
developer
experiences
built
right
into
gitlabs,
such
as
the
capability
support
environments.
That's
example
of
a
product
feature:
that's
gone
through
product
architecture.
A
Solution
architecture
is
when
we
take
potentially
a
lot
of
the
little
knobs
and
levers
in
gitlab,
and
maybe
even
some
other
external
stuff
and
knit
them
together
into
a
solution
that
works
for
our
organization.
So
today's
perspective
is
solution.
Architecture.
How
do
I
create
a
solution
that
works
for
me
using
some
of
the
gitlab
features.
A
We're
going
to
be
talking
about
a
building
block
index
for
workflow
control.
What
this
means
is,
while
I'm
going
to
depict
it
as
though
it's
a
single
workflow
and
highlight
all
the
inflection
points
at
which
you
might
use
a
gitlab
feature
for
something
it's
really
going
to
be
comprehensive
by
the
end,
a
kind
of
ideological.
It's
not
really
going
to
be
something
where
you
would
turn
on
all
of
these
controls
in
any
given
circumstance.
A
A
However,
if
you
hold
on
to
it
too
tightly,
you
can
end
up
making
things
overly
complicated
or
difficult
for
yourself
and
we're
specifically
going
to
be
focused
in
on
CI
and
get
Ops
deploy
as
the
two
areas
that
we
will
be
talking
about.
One
of
the
things
that
is
missed
sometimes
by
folks,
is
that,
if
you're
doing
deployment
in
an
external
product,
you're
kind
of
like
well,
what
does
gitlab
do
for
deployment?
A
Let's
start
with
our
developer,
so
developers
work
on
feature
branches
and
those
feature
branches
are
intended
to
be
merged
in
when
they
are
feature
ready.
Now
within
gitlab,
before
the
developer
can
even
push
commits
to
gitlab.
We
have
the
concept
of
signed,
commits
and
verified
committers,
and
what
this
means
is
that
developer
has
to
sign
their
commit
when
they
make
it
and
then,
when
they
push
it
verified
committers
will
make
sure
that
the
identity
inside
of
a
commit
matches
the
person
who's,
pushing
it
to
the
server.
A
A
So
these
two
things,
together
with
everything
else,
we'll
discuss,
can
be
very
powerful
for
making
certain
things
happen.
So
the
first
thing
we
do
is
Branch
CI
checks.
So
when
you
push
code
to
the
server
and
it
accepts
it
through
the
push
rules,
we
then
have
Branch
CI
checks
and
those
branch.
Ci
checks
are
generally
static,
checks
that
are
grabbing
the
code
and
taking
a
look
at
it,
we
think
of
security.
Sas
scanning
also
code
quality
scanning
linting.
So
all
those
kind
of
things
can
happen
as
part
of
CI.
A
That
information
then
feeds
back
into
the
merge
request.
So
one
of
the
important
things
here
in
git
lab
is
that
when
you
work
from
a
merge
request,
it
becomes
the
developer
single
source
of
Truth.
So
a
lot
of
the
information
about
the
tests
and
the
feedback
instead
of
you
having
to
Rifle
through
CI
jobs
or
look
through
artifact
files,
you
can
actually
just
go
to
the
merge
request
and
a
lot
of
this
information
is
very
helpfully
visualized
right
in
the
merge
request
now.
A
Another
thing
that
gitlab
does
that's
super
helpful,
but
sometimes
easy
to
miss
is
that
we
also
steal
a
little
bit
of
CD,
so
we
shift
CD
left
if
you
will
and
we
can
create
an
ephemeral
review,
app
or
environment
for
the
specific
developer
feature
Branch
now.
Why
would
we
want
to
have
an
environment
for
every
feature?
Branch?
It's
because
we
want
to
shift
all
of
the
possible
scanning
results
left
into
that
merge
request,
and
so,
if
we're
leaving
Dynamic
scanning
till
later,
because
environments
are
hard
well,
that's
going
to
be
lower
quality
software.
A
A
An
interesting
feature
of
merge
requests
is
that
when
there
are
findings
from
these
two
areas
of
scanning,
they
are
just
for
code.
The
developer
changed.
So
if
you
can
imagine
the
developer
workflow,
they
make
a
change
to
code.
Maybe
they
upgrade
an
open
source
component,
but
they're
unaware
that
there's
an
even
newer
one
and
the
one
they
upgrade
to
has
a
vulnerability.
Well,
that
would
be
immediately
surfaced
in
the
merge
request
and
in
the
merge
request,
we
have
controls
that
can
prevent
that
developer
from
merging
that
vulnerability
forward.
A
In
fact,
we
have
a
lot
of
controls,
so
there's
optional
approval
rules
required
approval
rules
and
what
I
was
just
mentioning
security
policy
approval
rules
which
make
sure
that
your
company
can
set
policies
on
a
whole
bunch
of
repositories
at
once.
That
basically
say
things
like
hey
you're,
not
allowed
to
merge
any
brand
new
criticals
into
the
next
branch,
and
so
that's
a
way
of
controlling
that
a
particular
issue
and
problem.
The
developer
resolves
the
the
vulnerabilities
that
are
violating
the
policy.
They
don't
have
to
talk
to
anyone.
A
They
can
now
push
the
software
forward
and
security
doesn't
have
to
come
in
and
approve
unless
the
developer
says,
look
I.
Think
I've
really
got
an
exception
on
my
hands
in
this
case,
even
though
I'm
the
one
who
introduced
this
vulnerability,
we
have
your
standard
code
owner's
approval.
We
have
electronic
signatures,
which
just
basically
makes
you
sign
back
into
git
lab
whenever
you're
going
to
click
the
approve
button
to
make
sure
you're
the
one
sitting
at
the
workstation.
A
We
also
have
the
ability
to
deny
a
merge
request
author
or
anyone
who
has
any
commits
in
the
merge
request
from
being
an
approver,
even
if
they
qualify
to
be
an
approver
with
one
of
the
other
rules.
That's
on
the
screen.
We
also
have
external
API
status
checks,
so
we
frequently
get
a
question
about:
hey,
can
I
block
all
deployments
based
on
some
sort
of
indicator
that
we
set
in
some
change
management
systems?
And
the
answer
is
with
external
API
checks?
You
can
do
that.
A
I.
Want
you
to
notice
that
on
several
of
these
rules
here
we
have
a
picture
of
a
little
group
with
a
gitlab
icon
on
it.
You
can
actually
set
up
user
only
groups
in
gitlab,
so
you
can
create
a
group
structure.
Only
add
users,
there's
even
a
checkbox
to
say,
don't,
allow
any
projects
in
this
particular
group
and
that
group
can
then
be
used
as
a
user
group
throughout
the
gitlab
system.
Then
this
is
separate
from
roles.
A
This
branch
is
about
getting
all
the
merge
requests
and
all
the
features
that
are
under
development
to
be
completely
resolved.
So
if
we
have
any
merge
conflicts,
because
some
folks
are
changing
the
same
code
at
the
same
time,
this
is
where
we
resolve
that
we're
going
to
pretend
in
this
case
that
this
is
also
our
final
code
branch
that
you
know
when
we're
done
this.
Our
code
looks
good
and
then
the
next
thing
we
can
do
is
merge
forward
to
a
git
Ops,
deploy
Branch.
A
What
we
mean
by
git
Ops
in
this
circumstance
is
that
we
simply
use
the
same
git
system
controls
for
deploying
software
into
environments.
As
we
use
for
managing
software
development-
so
that's
all
git
Ops
means
here
it's
not
attached
to
a
specific
technology
and
we
can
Target
any
deployment
technology
we
need
to.
So
once
we
have
this
merge
request
and
we're
going
to
merge
forward
into
a
new
Branch
just
to
deploy
to
an
environment.
A
We
have
all
the
same
controls
as
you
see
in
the
red
box,
so
all
those
same
controls
come
into
play
for
a
deployment,
as
could
be
used
for
an
actual
code
integration.
In
addition,
we
automatically
have
CI
CD
and
with
that
CI
CD,
we
have
that
ability
to
create
another
environment.
This
environment
might
be
longer
lived
because
the
branch
is
longer
lived,
but
we
have
that
ability
to
have
that
environment
and
do
both
static
and
dynamic
checks.
A
At
this
time,
once
in
a
while,
you'll
have
developers
work
on
code
eliminate
all
their
vulnerabilities,
but
when
you
combine
their
code
there's
a
new
vulnerability
that
has
to
do
with
how
that
code
works
all
together.
Then
all
of
this
information,
just
like
it
did
with
our
feature,
Branch
feeds
back
into
that
merge
request.
A
So
we
probably
have
a
lot
more
people
with
eyes
on
this
merge
request,
because
now
we're
talking
about
deploying
to
an
environment
when
we
go
through
here,
we'll
just
depict
deploying
to
two
environments,
but
you
could
have
as
many
of
these
branches
as
you
want.
In
fact,
there's
two
approaches:
one
would
be
to
merge
forward
to
branches,
to
get
to
New
environments
or
to
promote
to
an
environment,
and
another
approach
is
having
environments
on
one
branch
and
gitlab
can
do
either
as
we'll
see
here
in
just
a
minute.
A
The
next
thing
is,
we
have
the
concept
of
protected
branches,
which
is
a
standard,
git
concept
and
protected
tags,
and
basically,
when
we
protect
either
of
these,
if
anyone
is
trying
to
do
a
merge
using
that
particular
Branch
or
tag,
then
they
have
to
be
on
the
list
of
individuals
who's
allowed
to
merge
into
that
Branch
or
push
to
that
Branch.
Once
again,
we
can
use
gitlab
groups
here
next,
the
new
Branch
will
also
have
CI
CD.
A
So
once
we
get
through
our
merge
approval
processes,
then
we're
going
to
start
deploying
and
that
causes
CD
to
fire
up
now
within
CD.
We
have
the
capability
to
create
release
evidence,
so
we
can
say:
hey
here's,
the
exact
software
that
was
released
and
we
can
upload
a
zip
archive
into
a
special
releases
area
of
gitlab,
and
this
is
where
you
might
grab
your
software
bill
of
materials.
Your
license
list.
You
might
grab
any
security
testing
you
did
on
the
software.
A
You
might
also
grab
a
copy
of
the
source
code
at
that
point
in
time
and
put
all
of
this
together
so
that
you
have
an
attestation
that
your
development
process
was
solid,
that
there's
not
someone,
hacking
it
and
adding
stuff
somewhere
along
the
line.
So
release
evidence
is
more
of
a
point
of
auditability,
but
that's
something
that
you
should
consider
when
designing
out
your
Pipelines.
A
Next,
we'll
talk
about
deployment
to
an
environment,
so
in
this
case
we'll
talk
about
deployment
to
the
staging
environment.
In
this
case,
we
have
a
new
capability
which
is
not
standard
part
of
gate,
which
is
protected
environments.
So
in
gitlab
we
can
say
that
an
environment
is
protected
from
deployment,
except
for
a
certain
group,
and
that
capability
means
that,
while
most
of
the
pipeline
can
run
the
job
that
actually
will
deploy
to
the
environment
can
only
be
started
by
specific
individuals.
A
It
turns
a
job
into
manual,
which
also
makes
sense,
because
they're
essentially
approving
when
they
press
that
button
and
allow
that
deployment
to
happen.
So
this
is
a
yet
another
capability.
That's
deployment
oriented
in
gitlab,
so
this
is
our
stage
environment,
so
gitlab
also
supports,
and
you
may
have
seen
in
something
called
Auto
devops
that
there's
a
stage
and
a
production
environment
on
a
single
Branch.
This
can
also
be
done
within
gitlab,
and
so
then,
if
we're
going
forward
to
production,
we're
also
going
to
show
you
that
we
can
do
something
called
protected.
A
Runners
now
anywhere.
Where
you
see
the
gear
icon,
I
could
be
using
a
protected
Runner
and
a
protected
Runner
just
has
some
additional
capabilities,
most
notably
only
protected
variables
are
passed
to
it.
So
if
a
variable
is
not
indicated
as
protected
in
gitlab
Ci's
user
interface,
well,
then
that
variable
is
not
pushed
forward
into
a
protected
Runner.
A
So
it's
got
some
control
over
what
you're
allowed
to
tell
the
runner
and
what
you're
allowed
to
configure
for
the
runner
while
we're
in
here
and
really,
we
can
do
this
at
any
point
in
a
runner,
but
it
makes
more
sense
when
we're
in
a
protected
status.
We
can
also
look
up
secrets
in
hashicorp
vault
as
an
external
Secret
store.
A
So
this
allows
us
to
have
fairly
nuanced
and
environment
specific
Secret
store
that
we
can
consult
usually
for
secrets
that
the
software
once
deployed
has
to
use
within
the
environment,
but
it
can
also
be
for
secrets
for
infrastructures
code
and
we're
just
going
to
depict
that
going
to
production.
Okay.
If
we
got
protections
on
stage,
we
probably
have
protections
on
production
as
well,
so
that's
kind
of
a
view
of
all
the
different
levers
that
are
within
gitlab
to
help
you
create
a
solution
that
works
for
you.
A
This
is
sort
of
the
key
here,
so
anything,
that's
in
a
purple
box
is
a
something
that
can
be
used
as
a
control
and
then
also
anything
with
the
red
lock
on.
It
is
something
that
generally,
you
can
lock
down
so
that
the
the
folks
building
the
software,
don't
necessarily
have
all
the
permissions
to
do
all
the
parts
of
the
process.
Keep
in
mind,
too
that
this
is
not
just
for
CI.
It's
also
for
get
UPS
deployments.
A
So
when
we
use
deployments
as
merging
forward
into
a
branch
or
specific
CD
stages
within
our
pipeline,
then
we
can
apply
a
lot
of
these
controls
to
a
git
Ops
deploy
as
well,
so
I
hope
this
has
been
helpful
to
help.
You
have
a
better
understanding
of
what's
available
to
you
in
gitlab
and
I
just
want
to
call
out
that
in
the
notes
on
this
particular
video,
there
will
be
links
to
multiple
tutorials
that
have
working
example,
code
that
show
you
all
of
these
capabilities
in
play.
Thanks
a
lot
for
your
time
and
attention.