►
From YouTube: GitLab and AWS Better Together Partnering
Description
Table of Contents:
00:00 - GitLab and AWS Partnering For Customer Success in Building Software with and for The Cloud
00:13 - Visual Outline
03:05 - A Few of Our Partnered Initiatives
04:25 - Common Approaches to Customer Value
05:03 - Platform: Integrate | Migrate | Consolidate
05:39 - Common “Code First” Principles
06:02 - High Level Value Propositions
08:25 - GitLab Workflow and Review Environments
16:25 - GitLab Walks the Shift-Left Walk
19:40 - Merge Request, SPOG for Developers
22:41 - GitLab Workloads in AWS
29:01 - Workflow Controls in GitLab
37:07 - AWS CodeSuite Comparison
40:29 - AWS CodeSuite Integration
43:42 - Extending GitLab Environments for AWS
48:21 - Wrap Up
A
Hello:
everyone,
my
name
is
darwin
sonoy
and
I'm
a
staff
solutions
architect
with
git
lab
alliances.
I'm
delighted
today
to
talk
to
you
a
little
bit
about
how
we
partner
with
aws,
to
help
you
build
software
with
and
for
the
cloud.
So
let's
take
a
little
look
at
what
we'll
be
covering
today.
The
first
thing
we'll
talk
about
is
the
partnerships
and
common
approach
of
gitlab
and
aws.
A
So
we'll
talk
a
little
bit
about
our
partnership
and
then
we'll
also
talk
about
how
we
have
a
pretty
common
approach
to
bringing
product
to
the
marketplace
which
works
really
well
together.
Next,
we'll
talk
about
how
gitlab
is
a
software
factory
making
tool
kit,
so
it
allows
us
to
make
a
variety
of
factory
floors
so
to
speak
for
manufacturing
our
software.
A
Some
of
these
are
completely
prefabricated,
such
as
auto
devops
and,
of
course,
we
go
all
the
way
to
the
point
of
view
being
able
to
create
your
own
from
scratch.
The
interesting
thing
is,
you
can
create
intermediaries
that
allow
you
to
have
your
own
opinionated
pipelines
for
your
teams
at
your
company
or
opinionated
extensions
to
those
pipelines.
Then
we'll
dig
into
a
really
interesting
aspect
about
get
lab
of
shifting
left
as
well
as
environments.
A
The
frictionless
environments
are
automatically
deployed
upon
creating
a
branch
and
then
automatically
destroyed
upon
merging.
So
this
uniquely
solves
the
problem
of
a
developer
needing
an
environment
in
order
to
do
testing
and
then
those
environments
never
being
torn
down.
So
it
ends
up
in
a
bad
cycle,
and
so
in
this
case,
because
they're,
transparently,
created
and
destroyed
developers,
don't
tend
to
keep
them
around
and
actually
can't
and
it
doesn't
mind
them
being
created
because
there's
no
work
involved
for
anyone
we'll
also
dig
into
gitlab
and
aws
workloads.
A
So
what
are
the
various
workload
implications
of
using
gitlab
to
create
software
that
runs
on
aws,
as
well
as
running
gitlab
infrastructure
on
aws?
Next,
we'll
talk
about
code
suite
coexistence.
So
we
get
a
lot
of
questions
about
how
codesuite
can
be
used
with
lab
or
how
we
can
migrate,
and
so
there's
a
lot
of
good
information
here
about
how
to
work
together
with
these
products
and
then
finally,
we'll
talk
about
extending
that
environment's
capability
into
the
aws
ecosystem.
A
So
one
of
the
interesting
things
is:
while
we
have
it
out
of
the
box
for
kubernetes,
you
can
build
it
for
many
other
types
of
environments.
I
have
a
working
example
for
cloud
formation
that
shows
this
capability
to
create
a
brand
new
stack
on
whenever
a
repository
is
branched
and
then
to
destroy
that
stack
when
that
particular
branch
is
merged
back
into
a
shared
branch.
So
we'll
go
through
that
as
well.
Now
you're
encouraged
to
listen
to
everything
in
this
presentation,
but
the
video
should
also
be
indexed,
so
you
can
jump
around
a
review.
A
So,
if
you're
on
youtube,
you
should
find
an
index
in
the
description
and
then
also
there
are
more
slides
than
just
the
ones
that
are
showing
right
now
in
the
outline.
But
these
slides
are
also
unpacked
as
we
go
along.
So
as
we
go
through
the
slides,
we
talk
about
each
section
and
kind
of
unpack
them
since
they're
a
little
bit
busy
to
look
at
in
total.
So
hopefully
these
explanations
will
help.
You
understand
a
little
bit
better
about
how
git,
lab
and
aws
work
together
and
partner
together
on
the
technical
front.
A
So,
let's
dive
right
in
git
lab
has
been
partnered
with
aws
for
quite
some
time,
and
I
just
want
to
take
you
through
a
few
of
the
initiatives
that
we
work
on
regularly
together.
There
are
others,
but
I
thought
I'd
highlight
a
few
here
for
you.
So
first
of
all,
we
have
a
aws
quick
start,
and
this
works
with
our
cloud
native
hybrid
reference
architecture,
so
we
are
currently
in
the
process
of
getting
it
to
a
ga
status.
A
We
also
have
platform
as
a
service
integrations
when
you
deploy
gitlab
to
aws.
There
are
many
different
services
that
you
can
leverage
when
you're
putting
gitlab
on
top
of
aws
such
as
rds
elasticash,
s3
and
the
numerous
other
ones
as
well.
We
also
have
several
aws
workshops
and
have
provided
those
through
the
amazon's
aws
workshop
io
website
and
then
finally,
we
have
some
formal
partnerships
where
we
are
service
ready
in
public
sector
aws,
graviton
and
devops
software
competency
ready.
So
those
are
some
of
the
ways
in
which
we
have
key
partnerships
with
amazon.
A
So
now,
let's
talk
a
little
bit
about
the
ways
in
which
amazon
and
gitlab
both
deliver
customer
value
to
the
marketplace
in
a
very
similar
way.
One
value
that
we
hold
in
common
is
iteration
and
in
iteration
you
bring
new
parts
of
your
product
online
over
time.
So
gitlab
has
been
bringing
stages
on
over
time,
similar
to
amazon
services
and
then,
once
you
have
those
in
place,
you
continuously
improve
these
year
after
year,
so
get
labs
now
had
10
years
of
month-over-month
releases
for
new
functionality.
A
So
in
that
way
we
share
a
lot
with
amazon
and
how
they
bring
customer
value
to
the
market.
Another
key
way
is
being
a
platform,
so
with
a
platform
like
amazon,
we
have
very
similar
capabilities
in
terms
of
all
the
things
that
we
define.
We
have
an
offering
for
you,
but
also
like
amazon.
We
understand
your
need
to
integrate
other
things.
Sometimes
you
just
need
to
stay
on
a
certain
product
because
of
the
way
that
your
organization
is
built
or
deep
features
that
you
depend
on.
A
A
And
finally,
another
way
is
a
developer
experience
first
or
code
first
principles.
So
in
this
way,
gitlab
and
amazon
tend
to
think
of
everything
as
code
apis
and
clis
first.
So
this
puts
you
in
a
great
spot
for
automation.
We
don't
depend
heavily
on
a
lot
of
graphical
user
environments
and
that
kind
of
thing,
so
we
have
this
very
similar
shared
value
in
that
way
as
well.
A
A
One
of
the
things
it
can
do,
for
you
is
add,
very
high
level
value,
which
is
prefabricated
assembly
lines
or
prefabricated
pipelines.
These
pipelines
allow
you
to
do
fairly
significant
software
development
without
any
devops
configuration
at
all.
They
use
build
packs
in
order
to
recognize
exactly
what
software
is
being
built
and
to
understand
how
to
build
it,
deploy
a
review
application
security,
scan
it
and
eventually
deploy
it
through
staging
and
production.
A
More
and
more
partners
are
creating
similar
sub-assemblies
that
you
can
plug
into
pipelines
in
order
to
use
their
integrating
software
with
git
lab,
and
then
you
can
also
make
your
own.
So,
if
you're
a
part
of
a
enablement
team
of
some
type
that
helps
developers
with
their
productivity
rather
than
each
development
team
having
to
struggle
through
building
very
similar
functionality,
you
can
provide
a
library
of
pre-existing
sub-assemblies
that
they
can
use
in
their
pipelines.
A
We
even
have
some
customers
who
make
their
whole
own
prefabricated
assembly
lines
like
autodevops,
and
then
developers
only
need
to
really
tweak
it
and
customize
it
where
they
need
to
depart
from
that.
We
have
so
much
of
this
goodness
in
terms
of
prefabricated
things.
We
often
get
the
question.
Well
hey
what,
if
I
need
to
just
build
something
from
scratch
that
you've
never
heard
or
thought
of
before,
and
gitlab
does
of
course
have
that
as
well.
A
So
all
of
the
above
things
are
built
upon
a
fundamental
foundation
of
ci
coding,
in
which
you
can
basically
basically
do
anything
that
you
can
do
at
a
command
line
or
already
have
automated
with
code.
You
can
do
that
within
gitlab.
Let's
take
a
little
look
at
how
gitlab's
end-to-end
solution
works
alongside
amazon
web
services.
I
really
want
to
emphasize
and
zoom
in
on
the
fact
that
the
dynamic
review
environments
are
something
that
are
really
valuable
in
most
large
cloud,
build
environments
and
even
small
environments.
A
What
it
allows
your
teams
to
do
is
really
focus
on
delivering
software
rather
than
provisioning
environments
and,
of
course,
avoiding
environment
sprawl.
So,
let's
take
a
look
at
this.
First
of
all,
gitlab
has
a
full
featured
work
management
system
which
allows
you
to
work
with
your
agile
processes
in
terms
of
building
software,
so
there's
all
kinds
of
ways
to
combine
some
very
flexible
things
such
as
epics
milestones
and
issues,
there's
additional
properties
or
attributes
of
iterations.
A
There's
timelines
that
you
can
create
releases
that
interact
with
all
of
this.
So
there's
a
lot
of
capability,
that's
very
rich
in
terms
of
managing
your
work.
Now,
one
of
the
unique
things
about
gitlab
is
when
it
comes
time
to
assign
the
issue
and
then
for
work.
To
begin
is
that
we
give
work
visibility
right
away
in
gitlab
when
we
start
a
merge
request.
It
also
opens
a
branch
for
us
and
what
that
allows
is
for
us
to
understand
that
work
has
commenced
on
something
right
away.
A
Then
that
kind
of
reverses
this
in
a
negative
way
so
that
they
don't
see,
we
don't
see
work
visibility
until
much
later
in
the
cycle.
So
we
do
it
this
way
we
get
visibility
and
we
start
to
be
able
to
get
a
better
feel
for
value
stream
metrics
when
work
actually
begins
and
how
long
it
takes
to
proceed
through
the
system.
A
Now,
once
we
create
this
branch,
another
special
thing
happens
when
you're
using
gitlab's
built-in
componentry,
and
that
is
the
capability
to
create
review
environments.
So
when
we
create
our
merge
requests,
it
automatically
creates
a
branch
that's
associated,
so
all
of
these
are
associated
together.
The
issue,
the
branch
and
the
merge
request
without
the
developer.
Having
to
do
anything
special,
they
don't
have
to
remember
to
go
and
encode
it
and
make
sure
you
type
the
right
issue
number
and
all
of
that
it
just
all
links
up
together.
A
Then
they
push
code
to
their
branch
and,
as
part
of
pushing
code,
the
automated
build
and
test
ci
capabilities
kick
off
now.
One
of
the
things
they
do
that's
sometimes
easy
to
miss.
Is
they
automatically
create
what
is
called
a
review
environment,
and
so
that
was
is
what
allows
us
to
have
an
entire
copy
of
the
application
for
a
single
developer,
and
this
is
really
important
in
certain
kinds
of
testing.
A
Specifically
when
we
proceed
to
security
scanning,
if
you
want
to
do
security
scanning
of
a
running
copy
of
the
application
such
as
dast
requires
api
fuzzing
requires
well,
then
you
need
an
actual
running
copy
of
that
application.
Now
this
dynamic
review
environment
capability
is
largely
shown
and
demonstrated
very
frequently
with
gitlab
as
our
kubernetes
support.
So
this
is
all
very
transparent
if
you're
deploying
to
kubernetes
or
even
if
you're
not
deploying
to
kubernetes,
but
it's
okay
to
stand
up
a
copy
of
the
application
in
kubernetes.
A
In
order
to
test
it
that
can
also
work,
we
use
build
packs
to
identify
exactly
what
software
you're
trying
to
build
and
we
can
make
that
into
a
container.
Even
if
you
haven't
specified
a
docker
file
or
if
you've
specified
a
docker
file,
we
go
ahead
and
use
it
to
to
do
the
build
exactly
like
you
say.
A
However,
the
whole
concept
of
auto
deployment
that's
built
into
gitlab
can
be
extended
and
I
have
extended
it
for
pure
cloud
formation,
so
the
same
capability
becomes
extended
to
cloud
formation
templates
where,
as
soon
as
you
create
a
branch
it
stack,
it
creates
a
whole
new
stack
of
that
cloud
formation
template
to
be
used
in
the
same
manner.
Once
we
get
into
the
scanning,
then
we
can
start
to
get
feedback.
A
So
then,
as
we
get
that
feedback
coming
into
the
merge
request,
then
the
developer
of
course
starts
to
fix
a
vulnerability,
or
someone
makes
a
comment
on
a
better
way
to
do
some
code.
So
they
start
going
through
that
cycle
and
as
they
do
so,
this
green
arrow
here
ends
up
updating
the
environment.
Every
time
they
push.
So
this
dynamic
review
environment
is
not
just
deployed
once
it's
kept
up
to
date
with
each
new
code
push
as
time
goes
on,
we
get
better
and
better.
We
get
the
iteration
looking
really
good.
A
Also,
these
dynamic
review
environments
can
be
used
by
humans.
So
if
you
have
manual
processes,
you
need
to
do
and
you
can
be
all
kinds
of
custom
plugins
into
the
scanning
process,
whether
it's
for
security
code
quality,
there's
lots
and
lots
of
vendors
who
have
extended
their
capabilities
into
gitlab
by
providing
a
little
bit
of
runner
runner
yaml.
Then,
as
we
proceed
with
our
work
here,
eventually
we
acquire
all
of
the
approvals
on
the
merge
request,
so
various
folks
say:
okay,
yeah,
it
looks
good
enough
for
me.
A
My
concerns
are
around
performance
and
a
good
check
mark.
Another
person
might
have
other
concerns
around
maybe
ux,
and
all
of
that
gets
worked
in
and
then,
as
we
get
down
to
the
point
where
we
have
all
approvals,
then
we're
going
to
be
ready
to
merge
and
when
we
do
that,
merge
gitlab
automatically
in
the
background
similar
to
creating
the
environment,
goes
ahead
and
cleans
the
environment.
Up
now,
if
you've
ever
dealt
with
provisioning
of
developer
environments,
this
can
be
a
really
big
anti-pattern
in
many
organizations.
A
So
developers
tend
to
leave
environments
sitting
around
for
a
long
time
consuming
resource
without
any
usage
of
the
environment.
So
then
it
starts
to
get
where
they
put
barriers
or
justifications
up
for
creating
an
environment,
and
then
this
worsens
the
problem
in
a
negative
cycle,
because
when
developers
finally
get
an
environment
justified
and
actually
deployed,
they
don't
want
to
give
it
up
because
of
the
time
it
takes
to
get
a
new
one,
justified
and
deployed.
A
If
you
can
think
about
this
being
a
completely
frictionless
thing
that
both
sides
are
handled
well,
in
that
a
developer
automatically
gets
an
environment
without
doing
anything
and
it's
automatically
torn
down
when
they're
done
with
it
developers.
No
longer
resist
tearing
down
environments,
it's
actually
automatic,
but
they
also
don't
care
because
every
time
they
need
one,
it
automatically
springs
into
existence.
So
this
is
a
pretty
powerful
capability
to
also
help
with
deployment.
A
Then,
when
we
go
to
release,
of
course,
we
deploy
to
a
production
environment,
and
so
this
kind
of
capability
fits
very
well
with
the
cloud
and
with
aws
development,
because
it
removes
some
of
the
key
friction
points
that
frequently
are
left
inside
of
a
devops
iteration
cycle
and
it
causes
the
developer
habits
around.
Doing
really
good
quality,
including
secure
code
to
be
shifted,
and
then
it
also
allows
for
the
environment
issue
to
be
handled
quite
well.
So,
hopefully,
that's
a
good
overview
of
how
git
lab
provides
some
really
good
value.
A
Let's
talk
a
little
bit
about
how
git
lab
walks
the
shift
left
walk.
What
I
mean
by
this
is
there's
a
lot
of
talk
in
the
industry
about
shifting
left,
whether
it's
security
or
other
concerns
about
code,
but
we
talk
a
lot
about
it
and
we
don't
necessarily
boil
it
down
to
practical,
everyday
developer
habits
and
the
tools
that
they
use
in
the
workflows
they
use
in
gitlab.
A
Their
appropriate
information
is
brought
to
the
developer's
attention
at
the
appropriate
time,
with
the
appropriate,
directly
responsible
party
identified,
and
so
this
really
encourages
a
lot
better
habits,
and
it's
actually
something
developers
want
to
step
into.
They
don't
want
to
be
the
person
who
introduces
the
vulnerability
that
brings
down
you,
know
the
company
or
or
causes
significant
problems
at
the
company,
so
they
do
want
to
comply.
It's
just
that
when
we
insert
these
control
measures
and
these
encouragements
at
the
wrong
time,
it
can
be
very
frustrating
for
them.
So
let's
take
a
look
at
this.
A
A
So,
let's
name
this
the
traditional
big
ball
of
mud
context,
we
have
diffuse
responsibility
and
bad
timing.
As
far
as
our
software
engineer
is
concerned,
now
we've
gotten
here,
though,
from
a
compounded
situation
that
was
not
so
bad
at
the
beginning
of
the
cycle.
So,
at
the
beginning
of
the
cycle,
we
have
individuals
working
on
smaller
bits
of
code
and
it's
kind
of
like
out
on
the
workbench.
A
They
have
various
components
of
trying
to
get
working
together
or
bits
of
code,
and
if
you
at
this
time,
identify
problems
with
their
code,
it's
quite
easy
to
swap
something
out,
and
if
it's
going
to
create
a
more
secure
or
more
stable
product,
then
then,
who
wouldn't
want
to
do
that?
And
so
this
is
the
gitlab
context
of
the
problem
with
the
appropriate,
tooling
information
at
the
appropriate
time,
and
so
that
pinpointed
responsibility
with
good
timing
is
really
important.
A
Let's
take
a
look
at
merge
requests.
They
function
as
kind
of
a
single
pane
of
glass
for
developers.
They
can
help
us
in
get
lab
to
change
control
for
both
code
as
well
as
deployment
when
we
start
to
do
some
git
ops,
like
operations
that
allow
our
source
control
management
system
to
be
in
control
of
deployments.
A
A
They
have
the
ability
to
interact
on
the
actual
vulnerability
object,
to
say,
maybe
why
they
might
be
requesting
that
this
be
merged
anyway,
but
in
any
case,
security
doesn't
have
to
look
at
every
merge
approval
and
check
it
for
security
concerns,
and
they
also
don't
have
to
be
worried
about
being
left
out
of
critical
ones.
That
would
require
special
policy
procedures
to
trigger.
So
these
are
really
interesting
threshold
based
rules.
A
Then
we
also
have
a
variety
of
code
quality
browser
performance,
metrics
that
we
build
in.
You
can
also
substitute
your
own
for
this
area
and
then
down
here
we
have
the
security
ones.
Now
these
security
ones
are
different
than
the
other
ones
in
that
they
are
dynamic.
So
each
of
the
blue
linked
items
can
be
clicked
and
you
can
bring
up
a
panel
that
allows
you
to
interact
with
that
particular
vulnerability
object.
Frequently
it
tells
you
what
the
problem
is
links
to
any
known
internet
information
like
cves.
A
A
A
Now
this
is
basically
the
idea
of
using
gitlab
to
develop
apps
that
get
deployed
to
aws.
It's
an
important
aspect,
because,
if
you
think
about
it,
that's
really
where
the
big
money
is.
If
you
had
a
particular
development
team
of
40
developers
that
is
using
git
lab,
we
might
only
need
to
set
them
up
on
a
single
instance
of
gitlab,
which
is
quite
small,
not
a
lot
of
workload.
But
if
the
application
they're
building
is
used
by
20
or
30,
000
users
will
then
obviously
have
a
huge
workload.
A
A
We've
on
the
reference
architectures
rate
this
for
up
to
a
thousand
users,
though
we
know
we
have
customers
that
can
run
it
for
as
many
as
3
000
and
a
lot
of
it
depends
how
much
of
git
lab
they're
using
and
how
intensively
you
they
use
it.
So,
if
you're,
using
all
the
stages
of
git,
lab
and
you're
doing,
you
know,
100
builds
a
day
of
a
very
complicated
monorepo.
A
This
also
has
all
the
advantages
of
the
that's
built
into
these
systems.
When
redundancy
is
incorporated
and
replication
and
other
things,
the
main
ones
are
ec2,
rds,
elastic
and
s3,
although
others
are
very
possible
and
also
tested
and
supported
for
use
with
a
gitlab
instance,
and
then
at
that
point
the
front
end,
the
gitlab
front
end
could
be
deployed
on
ec2
instances.
A
So
this
is
bits
and
pieces
of
git
lab
that
are
part
of
the
git
lab
application
like
sidekick
and
rails
and
other
services
and
then
finally,
the
git
repository
storage
of
gitlab
cannot
be
put
into
platform
as
a
service
or
into
kubernetes,
and
so
you
generally
run
an
ec2,
node
or
cluster
of
something
called
italy,
and
that's
why
it's
called
cloud
native
hybrid.
It's
not
100,
you
know,
paths
and
kubernetes.
A
A
The
next
area
is
get
lab
runner
as
a
workload,
so
gitlab
runners,
depending
on
the
use
case,
can
be
a
significant
amount
of
compute
themselves.
If
you're
doing
ml
ops-
and
you
happen
to
use
gitlab
runner
as
your
scaling
model
processing
framework,
well
then,
of
course
it
can
be
fairly
substantial
and
then
some
organizations
are
just
doing
a
lot
of
heavy-duty
build
activity
because
they're
they're
building
on
every
commit
of
substantially
sized
repositories
or
many
repositories.
A
With
this
we
can
be
on
a
single
ec2
instance.
We
can
also
scale
on
ec2
in
asg,
and
we
can
also
scale
on
eks
with
kubernetes
runner.
The
the
runner
is
actually
so
flexible
and
so
capable
of
running
under
so
many
different
situations
that
it's
hard
to
describe.
It
basically
only
has
a
dependency
on
the
go
run
times,
and
so
if
a
platform
has
a
go
runtimes
a
lot
of
them,
we
support
directly
and
actually
distribute
get
lab
runner
for
those
platforms.
A
And
then,
if
you
have
the
go
runtimes
and
we
don't
distribute
for
it,
you
could
use
the
open
source
runner
code
base
to
try
to
build
the
runner
onto
a
platform
that
we
don't
directly
support.
So
it's
really
flexible
in
all
the
different
ways
that
it
can
be
implemented.
It's
also
open
source,
and
it's
not
something.
A
So
that's
an
overview
of
the
various
workloads
that
are
involved
in
git
lab.
Sometimes
I
find
that
those
of
us
who
are
really
familiar
with
the
plumbing
of
a
cloud
myself
included
get
really
excited
about
the
two
items
on
the
right:
the
actual
git
lab
infrastructure
workload
but
in
reality,
there's
probably
a
lot
more
potential
for
revenues
in
terms
of
get
lab
as
a
catalyst
to
getting
application
workloads
onto
the
aws
cloud.
A
So
let's
take
a
look
here.
One
of
the
first
things
that
gitlab
offers
is
the
capability
to
ensure
that
when
developers
send
code
into
gitlab
that
their
identity
is
verified
and
that
the
content
is
verified
is
untouched
since
they
put
it
together.
So
this
is
done
with
two
features
and
they
are
called
their
only
sign
commits
and
verified
committers,
so
the
first
one
makes
sure
that
every
commit
must
be
signed
and
then
that
way,
if
the
code
was
to
be
manipulated
after
that
person
had
touched
it,
it
would
be
evident.
A
The
other
one
is
verified
committers.
So
if
you're
familiar
with
git,
you
could
theoretically
change
your
email
identity
and
do
a
commit
under
someone
else's
email
and
then
push
that
to
a
server,
and
it
would
look
like
they
had
done
the
commit.
So
both
of
these
together
make
sure
that
the
code
in
the
commit
has
not
been
tampered
with,
since
it
was
done
and
they
make
sure
that
whoever
is
pushing
the
commit
to
gitlab
is
indeed
the
individual
who
is
claimed
inside
of
the
commit.
A
A
Now,
as
the
developer
updates,
the
software
that
environment
is
updated
and
one
of
the
important
things
here
is
that
we
can
do
dynamic
testing
that
requires
a
copy
of
the
running
application
desk
scanning
for
security.
I
asked
scanning
fuzz
testing
for
apis.
All
of
these
require
an
active
version
of
the
application
running.
We
can
also
do
human
q
a
activities
inside
of
this
environment.
If
that's
something
that
is
part
of
our
process
as
well,
that
environment,
then,
is
used
for
the
various
scanning
capabilities
which
come
back
to
the
merge
request.
A
The
merge
request
is
also
where
we
collaborate
around
human
inputs
and
human
approvals
to
the
actual
merge
and
once
the
merge
request
is
ready
to
go,
then
it's
merged
into
the
next
branch.
By
approving
that
merge
request
within
the
approvals,
we
have
a
variety
of
very
flexible
approval
rules.
The
first
one
listed
here
is
just
like
your
standard
approval
that
you've
seen
in
many
other
systems,
and
we
have
both
optional
and
required
approvers.
So
people
can
comment
if
they
wish
to.
A
We
have
a
very
unique
one
called
the
threshold
approval
rule
and
those
rules
only
trigger
under
certain
conditions.
So
one
of
the
most
relevant
is
if
a
developer
tries
to
merge
a
critical
vulnerability
into
the
next
branch,
and
it
has
never
previously
been
merged
before
and
accepted
by.
Whoever
is
in
charge
of
this
approval
rule.
Then
this
approval
rule
triggers
so
in
the
case
of
critical
vulnerabilities.
A
This
rule
will
trigger
for
security,
but
only
if
it's
a
net
new
critical
vulnerability
being
merged,
and
what
that
allows
is
for
security
to
have
lean
oversight
over
a
lot
of
different
projects.
They
don't
have
to
look
at
all
merge
requests,
but
they're
only
pulled
into
merge
requests
when
there's
something
that
doesn't
meet
the
policy.
A
In
addition,
we
have
electronic
signatures,
which
means
that
the
individual,
before
they
hit
the
approve
button
has
to
relog
in
which
proves
that
they
are
the
person
whose
credentials
are
currently
logged
in.
If
you
can
imagine,
a
workstation
left
logged
in
someone
could
theoretically
go
in
and
approve
a
bunch
of
merge
requests
under
that
person's
identity.
So
this
meets
electronic
signature
requirements
of
a
lot
of
different
organizations.
A
A
The
next
thing
we
have
is
several
gitlab
specific
concepts
of
protectedness,
so
protected
branches
are
a
concept
in
git
systems,
where
only
certain
folks
are
allowed
to
merge
to
a
branch.
Gitlab
also
has
protected
git
tags
so
that
only
certain
folks
can
use
a
git
tag
and
then
protected
variables
and
protected
variables
are
variables
that
will
be
allowed
to
go
on
to
a
protected
runner.
So
we
have
some
additional
enhanced
capabilities.
A
Once
we
get
into
the
ci
side
when
we're
processing
ci,
we
have
also
the
ability
to
create
release
evidence
and
so
part
of
the
whole
concept
of
workflow.
Controls
is
also
auditability
or
compliance,
and
so
by
creating
release
evidence
you're
able
to
show
what
happened.
You
can
collect
a
variety
of
logs
and
collect
them
all
up
into
release,
evidence
and
create
a
release,
object
which
can
then
be
the
kind
of
single
source
of
truth
of
what
happened
during
a
particular
release.
A
Then,
as
we
get
this
ready,
we
can
deploy
it
to
an
environment.
So
in
gitlab
we
can
protect
that
environment
and
then
we
can
go
to
target
environments.
Protected
environments
is
an
additional
control.
It's
not
part
of
git.
It
is
part
of
gitlab
ci,
where
you
can
say
that
a
specific
individual
is
the
only
one
allowed
to
press
a
go
button
on
deployed
to
an
environment.
A
We
also
have
the
concept
of
protected
runners,
which
provides
some
more
protections
in
terms
of
what's
happening
on
that
runner,
and
so
one
of
the
things
we
can
integrate
at
that
point
is
secrets
management.
So
the
secrets
have
a
limited
lifetime
and
have
more
protection
against
being
known
by
folks.
You
shouldn't
know
that
we
can
protect
pretty
much
any
environment
by
protecting
the
particular
jobs,
and
so
once
again
we
can
apply
protected
environments
to
a
production
environment
and
deploy
to
production.
A
All
right,
let's
take
a
little
look
at
code
suite
and
compare
it
with
git
lab,
we'll
also
talk
about
some
integration
methods
and
some
migration
options.
So,
first
of
all
just
want
to
note
a
standard
code
build
pipeline
and
code
commit
feeds
into
code
pipeline,
there's,
usually
code,
build
stages,
then
potentially
some
sort
of
deployment
stage
to
allow
environments
to
deploy
very
common
pattern
built
with
all
the
sub
services
of
code.
Suite.
A
A
One
of
the
challenges
with
that
interface
is
that
it
creates
a
net
new
set
of
resources.
Each
time
you
run
it
so
in
large
organizations,
teams
typically
have
to
toolize
the
infrastructure's
code
that
deploys
the
pipeline,
so
they
can
keep
it
simple
for
teams,
so
the
teams
aren't
using
40
different
im
roles
because
they
have
40
pipelines,
and
so
because
of
that
there
does
then
end
up
being
in
scale
development.
A
Quite
a
bit
of
work
around
this
part
that
is
in
the
orange
box
here
now
notice
that
the
blue
box
is
where
we
have
our
build
as
code
or
pipeline
as
code.
So
this
is
in
code
suite.
This
is
the
developer's
capability
to
be
able
to
define
what
should
happen
in
a
build
inside
of
the
code
repository
itself,
so
it
is
limited
in
scope
to
the
build
spec
yaml.
Now,
let's
take
a
look
at
the
gitlab
side,
so
with
pipelines
in
gitlab,
we
have
a
little
bit
of
a
different
approach.
A
The
first
approach
is
that
pipelines
are
not
married
to
a
branch
or
isolated
or
scoped
to
a
branch.
So
a
gitlab
pipeline
is
going
to
default
process
all
branches
in
the
repository
we
can
become
more
selective
after
that
we
can
say,
never
run
ci
for
certain
branches
or
run
these
specific
jobs
for
certain
branches.
That's
all
done
declarative
with
a
little
bit
of
logic
on
each
of
those
jobs
to
determine
what
should
be
done
in
what
branches,
so
developers
do
not
have
to
deploy
multiple
pipelines
for
this
capability.
A
In
addition,
this
is
really
another
aspect
of
get
feature
set.
Is
the
auto
deployment,
so
it's
both
ci
and
cd
and
one
of
the
things
we
leverage
this,
for
is
these
per
branch
review
environments,
where
developers
are
able
to
stand
up
a
standing
copy
of
the
application
and
then
do
things
like
security
scanning
on
that
copy?
A
Now,
security
scanning
isn't
the
only
thing
that
they
can
do
so
they
could
potentially
do
other
types
of
quality
and
assessment
or
even
human
testing
that
require
a
running
copy
of
the
application
so
because
cd
is
also
integrated
and
integrated
very
early.
It's
not
just
a
final
step.
It
allows
us
to
do
this
interesting,
dynamic
review
environments.
A
Those
review
environments
are
also
torn
down
when
the
code
is
merged
into
a
non-review
environment,
targeted
branch,
so
that's
really
handy
having
the
automatic
setup
of
an
environment
and
the
automatic
tear
down
without
any
action
on
the
part
of
the
developer
and
so
for
git
lab.
The
build
is
code.
Definition
is
around
all
of
this,
so
the
developer
tends
to
have
more
control
over
the
pieces
and
parts
of
how
ci
and
cd
operate.
Let's
shift
gears
and
talk
a
little
bit
about
integrations.
A
One
approach
might
be
that
you
need
to
integrate
your
gitlab
pipelines
with
your
code.
Suite
pipelines.
Teams
can
start
to
add
the
value
of
gitlab,
at
least
to
the
front
part
of
their
pipelines
by
integrating
now
code
pipeline
has
several
capabilities
of
triggering
a
pipeline
that
sometimes
folks,
don't
think
about
when
they
think
about
integrating
these
two.
So
the
first
one
is
the
capability
for
code
pipeline
to
monitor
an
artifact
that
is
in
an
s3
bucket
and
decide
to
do
a
new
deployment
based
on
the
appearance
of
a
new
versioned
artifact.
A
So
we
can
leverage
that
to
integrate
these
two
another
one.
That's
similar
is
ecr,
so
we
have
the
capability
to
integrate
ecr
so
that
when
a
new
image
appears,
a
code
pipeline
can
trigger
and
then
finally,
we
have
documented
in
our
gitlab
push
mirroring
how
to
mirror
a
git
lab
repository
into
code
commit
repository,
and
this
gets
us
right
into
the
very
front
of
the
entire
pipeline.
A
Most
of
you
probably
know,
gitlab
does
not
appear
as
one
of
the
providers
when
you're
setting
up
brand
new
code
pipelines
and
we
get
customers
asking
hey.
You
know
I
really
need
to
have
my
my
gitlab
repository
there
at
the
beginning,
and
so
this
is
a
way
to
work
around
this.
It
is,
unfortunately
on
both
sides
on
the
gitlab
side
and
on
the
amazon
side,
not
the
easiest
thing
to
figure
out
all
the
details
of
how
to
get
this
working.
A
So
if
you,
google,
gitlab,
push
mirroring
and
look
for
the
section
that
talks
about
mirroring
into
code
commit
that
can
help
you
over
the
hump
of
getting
this
particular
aspect.
Configured
a
third
way
is
to
just
integrate
directly
with
amazon
deployment
services,
the
ability
to
just
use
a
command
line
container
and
call
code
deploy,
for
instance,
in
an
area
of
call
guided
explorations.
A
We
also
have
the
build
as
code
self-service
for
developers,
so
it's
a
little
bit
more
full-featured
there,
the
multi-branch
capability,
the
automatic
deploy,
dynamic
review
environments
and
then
security
scanning
and
merge
requests
which
we
covered
in
a
previous
section
and
then
because
of
more
control
for
the
cd
aspect.
We
can
now
start
to
do
some
git
ops
workflows,
so
we
can
do
merge,
requests
to
a
new
branch
to
trigger
a
deployment
and
that
merge
request
can
have
all
the
gitlab
controls
of
any
merge
request
in
the
system.
A
The
change
sets
are
collected
as
artifacts
into
the
pipeline,
so
they
can
be
reviewed
before
deploying
to
production.
So
it
just
uses
a
multitude
of
best
practices
around
cloud
formation,
but
then
it
also
integrates
those
into
some
of
the
wiring
harness
so
to
speak,
of
git
lab
for
environments,
so
utilizing
the
environment
capability
to
bring
back
an
environment
url
that
you
can
then
click
on
and
see
the
environment
when
the
branch
is
merged
back
into
the
shared
default
branch.
A
A
So
let's
just
take
a
look
at
this,
as
this
is
our
main
branch
in
our
software
notice,
where
we
see
the
orange
gear.
This
is
something
happening
happening
completely
automatically
that
the
developer
does
not
have
to
manage
at
all.
First
of
all,
in
our
main
branch,
when
we
initially
create
it
and
do
an
initial
deployment,
we
will
get
a
deployment
of
the
production
environment.
So
normally
the
default
branch
represents
the
production
environment,
and
so
that
will
be
deployed
for
us.
A
The
cloud
formation
things
that
have
to
happen
here
are:
we
have
to
make
sure
that
a
our
cloud
formation
templates
are
completely
unique,
based
on
the
first
stack
name
of
the
parent.
Now
this
is
a
very
normal
thing
for
cloudformation
infrastructure
as
coders
to
do,
but
it's
especially
important
to
interface
with
gitlab.
The
second
thing
we
need
to
do
is
make
sure
that
environment
identifier,
which
is
usually
the
branch-
but
it
could
be
a
tag
that
it
is
part
of
that
stack
name.
A
So
now,
every
time
we
deploy
a
stack,
we're
going
to
get
a
unique
copy
if
it's
off
of
a
unique
branch
and
that's
the
essential
link
in
making
this
kind
of
happen
cleanly.
So
we
get
that
production
environment
deployed,
and
then
we
have
the
aspect
of
creating
a
new
feature.
So
when
the
developer
creates
a
new
feature,
they
create
a
feature
branch
and
because
of
following
the
auto
deploy
model
of
auto
devops.
That
branch
causes
a
new
environment
to
be
immediately
built.
Now
it's
built
on
the
first
commit,
which
means
it's
built.
A
It
will
be
identical
to
production
as
soon
as
the
branch
is
made,
because
you
haven't
actually
created
any
code
yet,
and
so
these
environments
are
private
to
the
feature
they're
ephemeral
and
they
enable
any
interactivity
testing
that
we
might
need
to
do
with
a
copy
of
the
application.
So
one
of
the
primary
ones
at
gitlab
is
dynamic
application
security
scanning
and
you
need
a
copy
of
the
engine,
apis
fuzzing
api
testing.
All
of
this
testing
can
be
done
dynamically.
Then.
A
The
next
thing
that
generally
happens
is
the
developer
is
going
to
get
feedback
in
their
merge,
request
and
they're
going
to
make
changes
to
the
code
or
add
more
functionality,
and
when
they
do
this,
we
get
another
commit
to
the
to
the
feature
branch
and
an
automatic
update
to
the
environment.
So,
as
the
developer
is
committing
to
gitlab
they're,
updating
that
environment
and
all
of
the
scanning
runs
again
now
you
can
control
this.
A
So
it's
a
wrap
on
talking
about
get
lab
and
aws
partnering
for
customer
success
in
building
software
with
and
for
the
cloud.
I
hope
that
this
information
is
really
helpful
to
you
as
you're,
considering
how
to
use
both
of
these
solutions
to
accelerate
your
development
and
to
get
more
value
out
of
your
development
activities.