►
Description
Brief demonstration of GitLab CI/CD - build, test and deploy a sample Python application to Google Cloud with GitLab CI.
A
My
name
is
Bart
sang
I'm,
a
channel
Solutions
architect
with
Git
lab
and
today
I'm,
going
to
briefly
demonstrate
how
you
can
leverage
gitlab
CI
for
monolithic
repositories
or
mono
repos
for
short,
in
order
to
facilitate
the
build
test
and
deploy
deployment
of
your
applications
into
production
and
Target
environments.
A
So
what
I
have
here
is
I
have
a
sample
project
right.
It's
called
view
controller,
it's
a
simple
python-based
application
that
that
collects
Imports
and
Aggregates
data
into
a
user
interface
or
a
visualizer
of
this
stack
Overflow
data.
Now
most
important
to
note
is
we
have
a
gitlab-ci.yaml
file.
What
this
yaml
file
includes
is
the
instruction
set
for
how
we
want
to
build
and
test
and
deploy
our
application.
A
So
I'm
going
to
go
into
my
pipeline
editor
and
and
let's
go
ahead
and
inspect
this
this
pipeline,
but
first
before
we
do
that
I
want
to
visualize
at
a
high
level
what
we're
doing
in
each
of
these
individual
stages
of
our
pipeline.
First,
in
the
request
stage,
we're
pooling,
Upstream
artifacts
from
another
project.
That's
going
to
contain
it's:
it's
housing,
all
the
data
that
we
need
for
our
application
and
then
I'm
going
to
build
this
image
using
kaniko,
which
is
a
container
build
tool
from
Google.
A
Then
I'm
going
to
test
my
application
by
executing
a
suite
of
security
and
code
quality
tests
on
my
application,
just
to
check
for
vulnerabilities
within
my
application,
binaries
and
dependencies,
as
well
as
the
files
themselves
and
then
I'm
going
to
deploy
a
dynamic
review
environment.
That's
going
to
reflect
the
latest
changes
to
my
application,
once
I've
done,
that
I
will
dynamically
apply
application
security,
testing
to
that
Dynamic
review
environment
and
then
once
I've
validated
that
I'm
not
introducing
any
vulnerabilities
to
my
application
within
that
Das
stage,
I'm
going
to
deploy
my
application
to
production.
A
A
So,
first,
if
you'll
note,
I
have
included
a
number
of
variables
in
this
pipeline
file,
so
these
variables
get
loaded
as
environment
variables
into
each
of
these
individual
jobs
and
they
can
be
referenced
if,
if
any
of
these
jobs
require
that
variable
now,
there's
also
a
separate
location
to
to
store
variables.
So
you
can
store
Secrets
such
as
service
account
credentials
and
protect
and
mask
them
within
the
gitlab
user
interface,
and
you
can
also
inherit
group
variables
from
a
parent
groups
where
you
can
store
variables
that
you
want
to
apply
to
multiple
projects.
A
Now,
in
this
case,
however,
I've
I've
stored
the
the
majority
and
the
bulk
of
my
variables
within
this
this
ci.yaml
file,
but
keep
in
mind
that
this
file
is
version
controlled
and
visible
to
members
of
of
the
project,
and
and
with
that
in
mind,
please
store
credentials
appropriately
with
third-party
Secrets
management
tools,
such
as
Vault
or
directly
in
our
git
live
user
interface.
A
We
have
something
called
project
level,
secure
files,
which
is
an
active
development
to
help
you
securely
store
your
your
secrets
and
credentials
now
within
the
context
of
this
pipeline.
I've
also
included
a
number
of
templates.
These
templates
host
security
and
co-quality
tests
that
we're
going
to
execute
on
our
application
now
I've
also
defined
the
stages
that
that
this
pipeline
consists
of
within
my
gitlab.ci.gmo
file
and
and
Within
These
individual
stages,
I've
included
a
series
of
jobs
right.
A
So
within
my
request
stage,
I've
included
a
used
Upstream
artifact
job,
and
this
is
going
to
house
the
job
that
pulls
data
from
an
upstream
Pipeline
and
loads.
It
into
this
specific
project
and
I'm,
also
going
to
take
that
artifact
and
and
build
my
my
visualizer
image
using
kaniko,
which
is
a
container
build
Tool
and
I'm
going
to
push
that
to
my
git
lab
Docker
registry.
So
you
can
actually
view
the
content
of
the
stalker
registry.
Now
keep
in
mind.
A
Moving
back
into
our
pipeline
editor
I
I'll
start
where
we
left
off
now:
I've
imported
a
series
of
security
and
code
quality
tests
that
aren't
going
to
be
immediately
visible
in
this
pipeline
editor
once
I've
executed,
those
security
tests
and
co-quality
tests
now
I'm
going
to
deploy
a
dynamic
review
environment
authenticating
into
my
Google
Cloud,
a
service
account
and
pulling
the
appropriate
Service
service
account
cluster
credentials
and
loading
them
so
that
I
can
execute
a
series
of
cube,
cuddle
and
Helm
commands
to
then
dynamically
create
a
namespace
and
deploy
my
application
to
it.
A
Now,
once
I've
done
that
I'm
going
to
execute
a
a
dast
job,
that's
going
to
validate
that
Dynamic
review
environment
that
we
just
deployed
and
once
we've
successfully
run
a
test.
Das
job
now
I
have
the
ability
to
deploy
my
application
to
production,
but
I'm
actually
going
to
involve
a
manual
gate
so
that
any
administrator
or
devops
team
member
can
actually
go
in
review.
The
security
tests
to
check
for
any
vulnerabilities
that
may
have
been
introduced
with
any
commits,
or
you
know,
changes
to
the
application
source
code.
A
So
with
that,
we're
executing
a
similar
series
of
steps
in
order
to
deploy
your
application
to
our
Google
Cloud
kubernetes
cluster.
In
this
case.
So
that's
that's
our
our
pipeline
end
to
end.
We
are
building
testing
and
deploying
our
application
from
that
monolithic
repo
that
involves
not
only
the
the
application
itself,
but
also
the
helm,
charts
that
are
used
to
deploy
it
to
a
cloud
native
platform
such
as
gke.
A
Now
going
back
to
our
editor,
let's
go
ahead
and
touch
base
on
the
and
review
these
stages
that
we've
gone
through
right.
We
have
to
build
the
test
review
as
well
as
Das
and
deploy
to
deploy
application.
Now
we
can
actually
look
at
pipelines
that
were
executed
on
this
Branch
right.
A
We
have
some
that
succeeded
and
some
that
failed,
and
these
are
going
to
actually
show
you
the
results
of
pipeline
execution
so,
for
example,
I'm
going
to
jump
into
one
of
the
jobs
that
succeeded
where
I
deployed
this
application
to
my
target
production
environment.
Using
that
pipeline
instruction
set
that
we
saw
earlier
where
we're
using
Google
Cloud's
gcloud
CLI
commands
in
order
to
authenticate
with
those
service
account
credentials
that
we've
passed
in
through
the
git
lab
CI
CD
variables
and
deployed
our
application
to
that
Target
environment.
A
So
with
that,
hopefully
this
gives
you
an
idea
of
how
we've
deployed
our
application
using
that
pipeline,
as
well
as
built
and
tested
the
artifacts
that
that
resulted
from
that
pipeline
using
things
like
security
testing
templates
that
are
provided
by
gitlab,
as
well
as
a
custom
scripts
to
deploy
my
target
application
to
this
gke
cluster.