►
Description
This course will teach you how to use GitLab CI to create CI/CD pipelines for building and deploying software to AWS.
🎥 Course created by Valentin Despa.
📚 Course Notes: https://gitlab.com/gitlab-course-public/freecodecamp-gitlab-ci/-/blob/main/docs/course-notes.md
📺 Valentin on YouTube: http://www.youtube.com/channel/UCUUl_HXJjU--iYjUkIgEcTw?sub_confirmation=1
🔗 Valentin's website: https://www.vdespa.com
🐦 Valentin on Twitter: https://twitter.com/vdespa
⭐️ Course Contents ⭐️
⭐️ Unit 1 - Introduction to GitLab
⌨️ Lesson 1 - Welcome (0:00:00)
⌨️ Lesson 2 - Your first GitLab project (0:03:03)
⌨️ Lesson 3 - Your first pipeline (0:13:00)
⌨️ Lesson 4 - Help, my pipeline is not working (0:23:32)
⌨️ Lesson 5 - What is YAML? (0:26:22)
⌨️ Lesson 6 - What is a shell? (0:35:12)
⌨️ Lesson 7 - GitLab architecture (0:37:50)
⌨️ Lesson 8 - Pipeline stages (0:43:14)
⌨️ Lesson 9 - Why do pipelines fail? (0:48:11)
⌨️ Lesson 10 - Job artifacts (0:52:34)
⌨️ Lesson 11 - Testing the build (0:59:02)
⌨️ Lesson 12 - Variables (1:04:33)
⌨️ Lesson 13 - What is DevOps (1:10:27)
⭐️ Unit 2 - Continuous Integration with GitLab CI
⌨️ Lesson 1 - Unit overview (1:16:53)
⌨️ Lesson 2 - Your first GitLab project (1:18:41)
⌨️ Lesson 3 - Building the project (1:22:05)
⌨️ Lesson 4 - Assignment (1:33:10)
⌨️ Lesson 5 - Assignment solution (1:34:43)
⌨️ Lesson 6 - How to integrate changes? (1:40:24)
⌨️ Lesson 7 - Merge requests (1:43:50)
⌨️ Lesson 8 - Code review (1:51:38)
⌨️ Lesson 9 - Integration tests (1:56:29)
⌨️ Lesson 10 - How to structure a pipeline (2:10:53)
⭐️ Unit 3 - Continuous Deployment with GitLab & AWS
⌨️ Lesson 1 - Unit overview (2:16:41)
⌨️ Lesson 2 - A quick introduction to AWS (2:17:14)
⌨️ Lesson 3 - AWS S3 (2:20:57)
⌨️ Lesson 4 - AWS CLI (2:23:35)
⌨️ Lesson 5 - Uploading a file to S3 (2:29:04)
⌨️ Lesson 6 - Masking & protecting variables (2:33:00)
⌨️ Lesson 7 - Identity management with AWS IAM (2:38:49)
⌨️ Lesson 8 - Uploading multiple files to S3 (2:47:54)
⌨️ Lesson 9 - Hosting a website on S3 (2:53:15)
⌨️ Lesson 10 - Controlling when jobs run (3:00:06)
⌨️ Lesson 11 - Post-deployment testing (3:07:03)
⌨️ Lesson 12 - What is CI/CD? (3:13:01)
⌨️ Lesson 13 - Assignment (3:16:47)
⌨️ Lesson 14 - Assignment solution (3:17:26)
⌨️ Lesson 15 - Environments (3:24:40)
⌨️ Lesson 16 - Reusing configuration (3:33:52)
⌨️ Lesson 17 - Assignment (3:36:57)
⌨️ Lesson 18 - Assignment solution (3:40:53)
⌨️ Lesson 19 - Continuous Delivery pipeline (3:44:15)
⭐️ Unit 4 - Deploying a dockerized application to AWS
⌨️ Lesson 1 - Unit overview (3:48:129)
⌨️ Lesson 2 - Introduction to AWS Elastic Beanstalk (3:49:25)
⌨️ Lesson 3 - Creating a new AWS Elastic Beanstalk application (3:51:48)
⌨️ Lesson 4 - Creating the Dockerfile (3:59:02)
⌨️ Lesson 5 - Building the Docker image (4:02:12)
⌨️ Lesson 6 - Docker container registry (4:09:27)
⌨️ Lesson 7 - Testing the container (4:15:59)
⌨️ Lesson 8 - Private registry authentication (4:20:04)
⌨️ Lesson 9 - Deploying to AWS Elastic Beanstalk (4:34:18)
⌨️ Lesson 10 - Post-deployment testing (4:45:54)
⌨️ Lesson 11 - CI/CD recap (4:50:29)
⭐️ Unit 5 - Conclusion
⌨️ Lesson 1 - Final assignment (4:51:37)
⌨️ Lesson 2 - Conclusion (4:55:16)
🎉 Thanks to our Champion and Sponsor supporters:
👾 Raymond Odero
👾 Agustín Kussrow
👾 aldo ferretti
👾 Otis Morgan
👾 DeezMaster
--
Learn to code for free and get a developer job: https://www.freecodecamp.org
Read hundreds of articles on programming: https://freecodecamp.org/news
B
Hello
frequent
campers
and
welcome
to
this
course,
which
will
introduce
you
to
gitlab,
ci
and
devops.
My
name
is
valentine.
I'm
a
software
developer
and
I
like
to
share
my
passion
for
technology
with
others
in
a
way
that
is
easy
to
understand
when
I'm,
not
speaking
at
a
conference
or
traveling
the
world,
I
like
to
share
what
I
know
by
being
active
in
groups
and
forums
and
creating
tutorials
on
youtube
or
online
courses.
B
I've
created
this
course
for
people
new
to
devops,
who
want
to
use
gitlab
to
build
test
and
deploy
their
software.
Don't
worry
if
none
of
this
makes
sense
right
now,
if
you're
a
beginner.
That
is
totally
fine,
you
don't
need
to
install
any
tools
or
anything
else.
Also,
no
coding
knowledge
is
required,
but
if
you
have
some,
it
is
great.
It
will
help
a
bit.
I
will
explain
to
you
everything
you
need
to
know
step
by
step.
B
This
course
focuses
on
gitlab
ci,
but
the
course
notes
are
packed
with
resources.
I
recommend
exploring,
if
unfamiliar
with
a
specific
topic,
go
right
now
to
the
video
description
and
open
the
course
notes
there.
You
will
find
important
resources
and
troubleshooting
tips.
If
something
goes
wrong,
I
will
also
be
publishing
there
any
corrections,
additions
and
modifications.
B
Yes,
this
is
a
very
dynamic
industry
and
things
change
all
the
time.
So
if
something
is
not
working,
first
check
the
course
notes.
I
am
a
big
fan
of
learning
by
doing
and
you
will
get
hands-on
experience,
building
pipelines
and
deploying
software
to
aws
throughout
the
course.
I
will
give
you
assignments
to
practice.
What
you
have
learned
well
in
this
course
we'll
be
focusing
on
a
specific
technology
and
cloud
provider.
B
What
you're,
actually
learning
are
the
concepts
around
devops
with
the
skills
acquired
in
this
course,
I'm
sure
you'll
be
able
to
start
using
gitlab
ci
for
whatever
you
need
in
no
time
at
all.
This
is
an
action-packed
course,
which
I'm
sure
will
keep
you
busy.
At
least
for
a
few
days,
as
always
here
on
freecodecamp,
please
help
us
make
such
courses
available
to
you
by
liking
and
subscribing
also
don't
forget
to
drop
a
comment
below
the
video.
B
If
you
like
this
course,
I
invite
you
to
check
out
and
subscribe
to
my
youtube
channel
link
in
the
video
description,
which
is
packed
with
content
around
devops
software
development
and
testing
also
feel
free
to
connect
with
me
on
social
media.
I
would
really
love
to
hear
from
you.
Finally,
I
would
like
to
thank
those
who
will
support
free
code
camp
by
clicking
that
thanks
button
and
making
a
small
donation,
I
hope
you're
excited
to
learn
more
about
gitlab,
ci,
aws
and
devops,
and
with
that
being
said,
let's
get
started.
B
I
have
designed
this
course
to
be
as
easy
to
follow
along
as
possible.
You
don't
need
to
install
any
software
on
your
computer
and
you
should
be
able
to
do
everything
just
from
a
browser
I'll
be
using
gitlab.com
throughout
the
course.
If
you
don't
have
a
gitlab.com
account,
please
go
ahead
and
create
one
by
default.
You
will
get
a
free
trial
with
your
account,
which
will
be
downgraded
to
a
free
one
after
30
days.
B
B
Now
that
the
registration
process
is
completed,
let's
begin
by
creating
our
first
project
and
we're
going
to
create
a
blank
project,
and
I'm
going
to
call
this
project.
My
first
pipeline,
I
have
the
option
of
providing
a
project
subscription
which
is
optional,
and
I
can
also
decide
on
the
project
visibility
either
private,
which
means
that
only
I
or
people
who
I
explicitly
grant
access
to
can
view
this
project
or
public,
which
means
that
can
be
viewed
by
anyone
without
any
authentication.
B
B
If
the
concepts
around
git
are
not
clear
check
the
course
notes
for
a
free
course
on
getting
started
with
git
for
gitlab.
Since
for
this
account,
I
haven't
configured
git,
you
will
also
get
here
this
warning
in
regards
to
adding
the
ssh
key.
This
is
also
covered
in
the
material
I
have
mentioned,
but
for
the
moment
we
don't
need
this,
so
we
can
simply
discard
it.
B
And
here
from
the
syntax
highlighting
theme,
what
I
like
to
do
is
to
select
monokai.
So
this
is
essentially
a
dark
theme
and,
as
you
probably
know,
we
like
to
use
dark
themes
because
light
attracts
bugs
and
we
definitely
don't
want
any
bugs
now,
leaving
the
joker
side,
some
people
like
it,
some
people
don't
like
it.
I
prefer
to
use
a
dark
theme
when
writing
code,
but
totally
agree
that
depends
on
everyone's
preference
on
how
to
use
this.
There
are
also
some
other
settings.
B
B
B
This
will
open
up
the
gitlab
ide,
so
I'm
going
to
create
a
new
file,
and
we
are
already
provided
here
with
a
template,
and
this
file
name
must
be
called
dot.
Gitlab
dash,
ci,
dot
yaml.
If
it's
not
exactly
this
name,
if
you're
writing
it
on
your
own,
this
pipeline
will
not
be
recognized,
so
the
pipeline
find
will
not
be
recognized
by
gitlab.
This
is
a
very
common
mistake
that
beginners
make
probably.
B
This
is
why,
if
you
click
directly
on
this,
one
you'll
be
pretty
sure
that
you
don't
name
this
file
like
anything
else
now
in
this
file,
we're
gonna,
define
the
pipelines
and
essentially
gonna
write
here,
configuration
to
create
pipelines
in
gitlab,
say
it's
totally.
Fine.
If
you
don't
know
what
that
is
right
now,
just
want
to
create
a
very
simple
example
to
make
sure
that
we
have
everything
we
need
in
order
to
follow,
along
with
the
rest
of
the
course.
B
So
what
I'm
going
to
do
here,
I'm
going
to
write
something
like
test
column
and
then
I'm
going
to
go
to
the
next
line,
and
you
will
see
here
everything
is
already
indented
so
with
this
indentation
with
this
four
spaces
that
you
can
see
right
now.
Here
I'm
gonna
write,
script,
column,
space
and
then
I'm
going
to
use
the
echo
command
to
display
a
text.
B
This
is
going
to
be
the
text
that
we
want
to
display.
The
echo
command
is
used
to
display
a
text
and
we'll
be
able
to
see
it
later
on
and
this
dot
gitlab
ci
that
yaml
file
allows
us
to
describe
our
pipeline.
As
I
said,
don't
worry
if
this
does
not
make
any
sense
right
now.
This
is
just
a
test
to
ensure
we
have
everything
we
need
to
get
started
so
now.
What
we're
gonna
do
is
to
actually
commit
these
changes,
which
means
introducing
this
file
inside
the
gitlab
repository.
B
If
we
click
again
here
on
the
project,
name
we'll
exit
this
view-
and
you
will
see
here
that
the
pipeline
failed
so
every
time
we
make
changes
to
this
project,
the
pipeline
will
be
executed
based
what
we
have
defined
in
this
yaml
file.
But
you
will
see
here
right
on
top
there's
this
indication
that
something
is
wrong,
and
even
here,
if
you
look
inside
the
pipeline,
you
will
get
this
additional
information.
So
what
is
going
on
in
order
to
run
your
pipeline
using
the
gitlab.com
infrastructure?
B
B
B
I
also
know
that
credit
cards
are
not
that
widespread
in
some
countries,
and
this
may
be
inconvenient.
Maybe
you
can
ask
a
friend
to
help
out.
I
hope
that
gitlab
will
introduce
alternative
verification
options.
Nevertheless,
verifying
your
gitlab.com
account
and
using
the
gitlab.com
infrastructure
is
the
easiest
way
to
follow
along
with
the
course.
B
So,
if
you
can
invest
five
minutes
now
and
get
this
done,
it
will
save
you
hours
later.
You
can
use
your
own
infrastructure
to
run
gitlab,
but
it
is
more
complex
and,
from
my
experience
of
training,
thousands
of
students
is
that
people
new
to
gitlab
who
use
their
own
infrastructure,
have
issues
running
their
pipelines
and
waste
a
lot
of
time
trying
to
get
them
to
run
properly.
B
You
have
been
warned,
but
if
you
want
to
go
this
path,
I've
added
some
resources
to
the
course
notes
which
you
can
find
in
the
video
description
now
in
order
to
get
started
with
the
verification
process,
you
have
to
click
here
on
validate
account.
You
will
be
asked
to
enter
your
credit
card
information.
B
I
hope
that
the
validation
has
been
okay
and
in
order
to
see
if
everything
is
working
properly,
I'm
gonna
go
back
to
the
project
and
open
the
web.
Ide,
I'm
gonna
click
on
the
get
lab
ci
file
to
make
a
change
to
it
and
I'm
gonna
change
here.
The
message,
so
this
is
gonna-
be
now
hello,
world
2
and
going
to
go
here,
commit
so
essentially
making
a
new
change
to
this
file
and
commit
it
directly
into
the
main
branch.
B
B
B
And
additionally,
what
we're
also
interested
in
seeing
here
is
seeing
this
text
here,
which
says
pulling
docker
image
now.
This
is
very
important
not
for
this
job
itself,
but
what
we
are
going
to
do
throughout
the
course.
We
want
to
make
sure
that,
whatever
we
have
here
in
terms
of
the
execution
that
we
are
actually
using
docker,
if
this
is
working,
it's
fantastic,
you
can
jump
directly
into
the
next
lecture,
otherwise
check
the
course
notes
for
some
troubleshooting
ideas.
B
B
Let's
take
a
laptop,
for
example,
to
oversimplify
the
assembly
line
would
have
the
following
steps:
we'll
take
an
empty
laptop
body
case,
we'll
add
the
main
board
and
add
a
keyboard.
We
would
do
some
quality
assurance
to
ensure
it
turns
on
and
works
properly.
Then
we
would
put
it
in
a
box
and
finally
ship
it
to
customers,
and
we
are
not
using
gitlab
to
produce
physical
products.
We
want
to
build
software,
but
producing
software
has
similarities
to
what
I
have
described
before
before
we
can
ship
anything.
We
go
through
a
series
of
steps.
B
B
Now
we
already
have
a
job
and
this
job
is
called
test,
but
probably
we
should
go
ahead
and
rename
this
to
maybe
build
a
laptop,
or
we
can
also
call
it
simply
build
laptop
now
in
the
script
part.
This
is
where
we
can
essentially
write
commands.
Now
so
far
we
have
used
this
echo
command,
but
the
way
we
written
this
allows
us
only
to
write
one
command.
B
So
what
I'm
going
to
do
here,
I'm
going
to
go
on
the
next
line
and
I'm
going
to
start
here
with
the
dash-
and
this
will
allow
us
to
essentially
write
multiple
commands
one
after
the
other.
So
let's
rename
this
in
something
like
building
a
laptop
just
to
give
us
some
information
in
regards
to
what
we're
trying
to
do.
B
As
I
said,
the
language
that
we're
using
here
to
describe
our
pipeline
is
called
yaml
and
yaml
is
essentially
a
way
to
represent
key
value
pairs.
It
may
look
a
bit
weird
in
the
beginning,
but
after
a
few
examples,
I'm
sure
you
will
get
used
to
it
now
so
far.
Our
problem
doesn't
do
anything
and
inside
this
job
we
actually
said
we
want
to
build
this
laptop,
and
we
also
said
that
we're
not
going
to
use
physical
components,
we're
going
to
use
folders
we're
going
to
use
files,
we're
going
to
use
some
text.
B
B
So
now
we
have
a
folder
and
let's
go
to
the
next
line
and
actually
create
a
file.
So
I
want
my
file
to
be
inside
this
build
folder
and
in
order
to
create
this
file,
we're
going
to
use
the
touch
command
now
the
touch
command
is
generally
used
for
modifying
the
timestamp
of
a
file
essentially
you're
touching
it
you're
modifying
it,
but
it
also
has
an
interesting
behavior
which
we
will
use
here.
If
the
file
does
not
exist,
it
will
create
an
empty
file
and
initially
for
us,
that's
perfectly
fine.
B
So
we're
going
to
create
this
file
inside
the
build
folder
which
we
created
one
step
before
and
with
the
forward
slash
we
go
inside
this
build
folder.
We
can
specify
the
file
name,
which
in
this
case,
will
be
computer.txt
now.
The
next
question
is:
how
do
we
get
some
text
inside
this
file
and
in
order
to
do
that,
we're
going
to
use
a
command
we
have
already
used
before-
and
this
is
the
echo
command
now
echo?
B
If
we
don't
do
anything
else
like
we
did
here,
it
will
just
print
this
message
and
we'll
see
it
in
our
build
logs,
but
we
can
also
kind
of
redirect
this
and
send
it
directly
to
a
file
and
for
that
we're
going
to
use
an
operator.
So
let
me
show
you
what
I
mean
by
that
I'm
going
to
write
here
again,
echo,
and
the
first
thing
that
we
are
going
to
do
is
we're
going
to
add
here
the
main
board.
B
So
if
you
want
to
take
a
look
and
see
exactly
what
is
the
contents
of
the
file,
we
can
do
that
as
well,
and
for
that
we
there
are
different
commands
that
we
can
use.
One
option
would
be
to
use
the
cat
command
and
cat
stands
for
concatenate
and
can
be
used
for
creating,
displaying
or
modifying
the
contents
of
files.
In
this
case,
we're
using
this
hat
command
to
view
the
contents
of
a
file
and
again
we
have
to
specify
the
path
to
that
file.
B
So,
just
to
make
sure
I
don't
make
any
mistakes
and
always
go
ahead
and
copy
paste
the
value
of
the
file,
the
name
of
the
file
and,
of
course,
we
can
also
go
ahead
and
add
the
other
steps
so
which
other
steps
did
we
had.
For
example,
we
wanted
to
add
a
keyboard,
I'm
gonna
add
this
again
with
a
new
command,
and
I
think
that
should
be
it's
a
way.
We
have
the
main
board.
B
We
have
the
keyboard
and
of
course
we
can
also
try
this
cat
command
once
again
at
the
end,
and
this
will
give
us
an
idea
of
how
the
job
itself
is
working
in
the
previous
execution,
we
haven't
specified
a
docker
image
to
use,
and
by
default
it
will
download
a
ruby,
docker
image
which,
for
our
use
case
here,
doesn't
really
make
a
lot
of
sense.
So
we're
going
to
use
a
very
simple
docker
image.
It's
a
linux
distribution
that
will
be
started
with
our
job
and
we
can
do
that
by
specifying
here.
B
Another
keyword-
and
you
will
see
here
it's
under
the
job
itself,
which
is
build
laptop,
but
at
the
same
level
with
the
script.
So
I'm
going
to
write
here,
image,
column
and
the
image
name
will
be
alpine,
so
alpine
linux
is
a
very
lightweight
linux
distribution.
What's
most
important
for
us
that
this
distribution
has
these
commands
that
we're
using.
So
these
are
pretty
standard
commands
that
are
available
essentially
in
any
linux
distribution,
but
having
a
very
small
linux
distribution
will
make
our
job
run
much
faster.
B
So,
let's
go
ahead,
commit
these
changes
and
see
how
the
pipeline
runs.
I'm
going
to
commit
again
to
the
main
branch,
and
if
I'm
in
patient,
I
can
click
directly
here
on
the
pipeline,
or
I
can
also
go
directly
on
the
project
page,
and
you
will
only
see
here.
The
pipeline
running
pipeline
is
also
available.
B
If
you
go
here
inside
cicd
pipelines,
it
will
display
your
list
of
all
the
pipelines
that
are
running.
You
can
click
here
on
this
one,
which
is
the
id
of
the
pipeline.
You
will
see
now
our
pipeline
contains
a
job,
and
this
job
has
been
assigned
to
the
stage
test
by
default.
If
no
stage
is
defined,
the
job
will
use
the
test
stage.
B
Now
it
doesn't
really
matter
how
the
name
of
the
stage
has
been
called.
We
just
want
to
make
sure
that
the
commands
that
we
have
executed
are
actually
working
properly,
we're
getting
here,
no
errors,
so
the
job
is
running
so
the
job
has
executed
successfully.
We
can
click
on
it.
Take
a
look
at
the
execution
logs,
see
exactly
what
has
happened
here
and
you
will
see
here
in
the
logs
the
commands
that
we
have
executed
they're
all
visible
here.
B
You
will
see
here,
echo
building
laptop.
You
will
see
the
text
being
displayed
after
that
we
are
creating
a
new
folder,
we're
putting
a
file
inside
that
folder
we're
adding
some
text
to
that
file.
Then
we're
checking
the
contents
of
the
file
to
make
sure
everything
is
fine.
You
see
here
the
word
mainboard
being
displayed
and
then
we
add
the
keyboard
and
then
again
you
will
see
here
the
contents
of
the
file
containing
both
main
board
and
keyboard.
B
B
I'm
going
to
make
this
a
bit
bigger
on
the
screen
so
that
you
can
easily
check
and
compare
it
with
what
you
have
it's
very
important
that
in
some
places
you
have
this
column
so,
for
example,
here
I'm
defining
the
job
and
in
order
to
add
image
and
scripts,
as
essentially
properties
of
this
job.
It's
important
to
have
here
this
column.
B
If
I'm
removing
that
you
will
see
here
in
the
editor,
when
you
see
these
lines
here,
it
will
indicate
that
something
is
wrong.
Most
of
the
time,
these
messages
are
really
not
so
easy
to
understand.
So
it's
more
important
to
double
check
what
you
have
written
here
to
make
sure
it
is
exactly
as
it
should
be.
B
So,
for
example,
here
with
the
commands
and
whenever
you're
writing
echo
or
make
deer
or
touch
there
needs
to
be
a
space
between
the
dash
and
the
command.
This
is
why,
in
the
beginning,
I've
asked
you
to
enable
this
white
spaces
so
that
you
can
easily
see
them
in
your
script.
So
if
I
write
something
like
this,
this
again
will
make
something
weird.
B
So
it
will
not
show
here
an
error,
because
this
is
actually
valid
yamo,
but
when
gitlab
will
try
to
execute
this
pipeline
and
we'll
look
at
these
commands,
we'll
think
that
you're
trying
to
run
a
command
that
starts
with
dash
echo
and
we'll
say
I
cannot
find
this
command.
So
for
that
reason
you
need
a
space
here
to
make
a
difference
between
this
dash
here,
which
indicates
a
list
and
this
command.
B
What's
also
important,
is
the
indentation,
as
you
can
notice
here,
there
are
four
spaces,
so
everything
that
is
under
build
laptop
is
indented
with
the
level.
If
I
add
something
like
this
here,
it
it
will
no
longer
belong
to
build
laptop
and
will
come
out
as
something
that's
really
weird
and
most
likely
it
will
be
invalid,
so
always
make
sure
that
you
have
the
right.
Indentation
two
spaces
are
also
fine.
By
default,
this
web
ide
will
use
four
spaces
just
make
sure
you
have
that
indentation
there
in
place.
B
The
most
important
reason
why
you
need
to
know
some
yaml
basics
is
because
you'll
be
facing
many
errors,
while
writing
yaml
and,
as
I
mentioned
in
the
beginning,
this
is
normal
trust
me.
I
also
did
the
same
mistakes
that
you
did
and
sometimes
I'm
still
making
mistakes,
while
writing
yaml.
If
I'm
not
paying
attention
if
you've
already
been
exposed
to
formats
such
as
json
or
xml,
I'm
sure
you'll
be
able
to
understand
the
basics
around
yaml
very
easily.
B
Actually,
yaml
is
a
superset
of
json
and
you
can
easily
convert
json
to
yaml,
both
xml,
json
and
yaml
are
human,
readable
data
interchange
formats,
while
json
is
very
easy
to
generate
and
parse.
Typically
yaml
is
considered
easier
to
read,
as
you
will
see
not
so
easy
to
write,
but
we'll
get
to
that.
B
Quite
often
yaml
is
being
used
for
storing
configuration,
especially
if
you're
learning
devops,
you
probably
face
yaml
a
lot,
and
this
is
exactly
why
we're
using
it
in
gitlab
as
well
to
store
a
pipeline
configuration
at
its
core.
Yaml
follows
key
value,
storage
principles
and
let
me
open
up
here
inside
the
editor,
a
new
file
and
I'm
gonna
start
writing
some
yaml
basics.
B
B
So
this
is
something
that
anyone
would
understand
now
in
yaml,
we
use
a
column
to
separate
that,
and
so
I'm
going
to
add
here,
name,
column,
john
and
what's
also
more
important,
that
we
have
a
space
after
this
column.
So
it
will
be
like
this,
and
you
will
see
here.
The
color
here
will
also
change.
So
now
we
have
a
key
value
pair.
The
key
is
name
and
the
value
is
john.
We
also
call
this
a
mapping,
we're
mapping
a
key
with
a
value
of
course,
on
a
new
line.
B
We
can
start
adding
an
additional
key
value
pair,
for
example.
Let's
say
here,
h,
23
and
what's
important
to
know
is
that
the
order
of
the
properties
does
not
matter
so
we
can
define
them
in
any
order.
So
if
I
write
first
name
john
and
after
that,
h
or
the
other
way
around,
that's
actually
the
same
both
are
defined
here
in
this
yamo.
B
Quite
often,
we
need
to
define
lists
which
in
yaml
are
called
sequences,
and
we
do
that
by
writing
each
value
on
a
new
line.
So,
for
example,
let's
write
here,
some
hobbies
call
them
sports
youtube
and
hiking
right
and
what
you
also
do
is
we
put
them
each
of
them
on
a
new
line,
but
each
line
must
start
with
a
dash
and
a
space.
So
we
have
here
a
dash
and
a
space,
a
dash
and
a
space
dash
and
a
space.
B
Now
we
have
a
list
now
the
way
I've
written.
This
doesn't
really
work
like
that.
So
if
we
remove
everything
from
here,
this
will
be
probably
a
valid
list,
but
we
cannot
simply
just
combine
this
properties
and
now
just
add
this
list
here
in
between
what's
important
to
know
about
yaml
is
that
it
uses
indentation
for
scope.
Essentially,
it
allows
you
to
know
which
value
belongs
to
which
key,
because
it
has
the
proper
indentation.
B
So,
for
example,
now
we
know
this
is
not
valid
here,
but
if
you
write
here,
for
example,
hobbies
as
a
key,
then
this
list
here
will
belong
to
this
key.
So
essentially
the
mapping
will
contain
a
key
and
this
list
of
values.
Well,
this
is
valid.
We
also
like
to
indent
this,
I'm
going
to
select
everything
and
click
on
tab,
and
this
will
indent
all
these
values
here.
B
Additionally,
we
can
have
some
nested
structures,
so,
for
example,
if
I'm
trying
to
write
here
an
address,
so
this
will
be
the
key
and
then
on
a
new
line.
I
can
write
additional
key
value
pairs
which
all
belong
to
the
address,
and
you
will
see
here
I
have
the
indentation,
so
I
can
write
something
like
street
and
on
a
new
line.
I
can
go
ahead
and
write
a
city
and
again
on
a
new
line.
B
I'm
gonna
write
here
the
zip
code
and
essentially
by
using
this
indentation,
we
show
that
street
city
and
zip
they
all
belong
to
address.
If
we
didn't
have
this
indentation
and
it
would
all
be
a
property
of
something
else.
This
is
why,
in
this
case,
we're
using
here
name
age,
hobbies
and
address
these
are
like
properties
on
the
first
level
and
street
city
and
zip
they
are
under
address
in
terms
of
lists.
We
can
also
build
some
more
advanced
lists,
so
this
is
a
very
simple
list
that
we've
used
for
hobbies.
B
But
let's
say,
for
example,
that
we
want
to
add
here
a
new
key,
which
is
called
experience
and
here
for
the
experience,
we're
gonna
create
a
list
and
we
just
wanna
say
like
what
is
the
professional
experience
of
this
person.
For
example,
we
can
have
here
job
title
that
could
be
junior
developer
and
instead
of
creating
here
a
new
item
in
the
list.
We
just
go
to
the
same
level
as
with
title.
Then
we
can
start
writing
something
like
period,
so
it
will
indicate
in
which
period
this
person
has
been
a
junior
developer.
B
B
B
B
So
if
we're
looking
here
at
our
pipeline,
we
can
just
decide
to
use
something
else.
So,
for
example,
instead
of
image,
we
cannot
just
decide
we're
going
to
call
it
docker
image
or
docker
or
instead
of
scripts.
We
cannot
write
here
scripts,
because
this
is
something
that
gitlab
will
not
understand.
Yes,
from
a
yaml
perspective,
this
is
still
valid,
but
from
the
perspective
of
gitlab,
this
is
something
that's
not
according
to
what
we
agreed,
essentially
in
advance
when
we
started
writing
these
pipelines.
B
So
it's
just
important
that
you
understand
like
what
we're
doing
here
and
how
this
indentation
and
how
this
key
value
pairs
are
being
written.
But
when
we're
writing
jobs,
we
we
decide
how
this
job
will
be
named.
We
decide
what
exactly
will
happen
inside
it.
Some
keys
will
be
reserved
and
simply
cannot
be
renamed.
You
just
have
to
pay
attention
that
what
you're
writing
here
is
really
important,
and
it
has
to
be
exactly
at
least
exactly
as
the
examples
that
I'm
showing
you.
Otherwise
gitlab
will
not
be
able
to
understand
what
you're
seeing.
B
B
I
can
switch
inside
that
folder,
we'll
see
here,
for
example,
with
ls.
I
will
be
able
to
list
the
contents
of
that
folder.
Let's
go
ahead
and
write
here,
touch
this
touch
command
and
create
here
file,
name,
computer
and
again
with
ls.
I
can
see
which
files
are
inside
the
current
folder,
so
we
typically
type
these
commands
that
you
have
seen
in
the
pipeline
through
this
command
line
interface
or
cli.
B
Sometimes
we
call
it
a
console,
a
terminal
or
a
shell
while,
technically
speaking,
they
are
not
the
same
thing
you
may
notice
me
and
others
use
them
interchangeably.
A
command
line.
Interface
is
the
opposite
of
a
graphical
interface.
This
is
a
graphical
interface.
You
will
be
able
to
see
text
colors.
You
have
buttons
that
you
can
click
things
are
happening
through
your
interaction,
you're,
moving
your
mouse
and
you're
clicking,
or
something
or
you're,
using
your
keyboard
and
something
changes
on
the
screen.
B
This
is
a
command
line
interface.
We
will
work
with
the
command
line
interface
to
write,
commands
computers.
We
interact
with
have
no
user
interface
that
we
can
use
anyway.
Automating
graphical
user
interfaces
is
not
as
easy
and
as
reliable
as
simply
using
commands
the
command
line
interface
that
computers
have
is
called
the
shell.
The
shell
is
simply
the
outer
layer
of
the
system,
the
only
thing
that
we
can
see
from
outside
and
interact
with,
so
we
send
these
commands
to
the
system
and
the
system
will
run
them.
B
This
is
how
we
can
interact
with
it
when
using
gitlab
ci,
we
essentially
automate
a
set
of
commands,
which
we
execute
in
a
particular
order,
while
I
will
explain
every
command
that
we'll
be
using
throughout
the
course.
If
this
is
something
new,
there's,
absolutely
no
replacement
for
trying
things
on
your
own.
B
B
A
runner
will
retrieve
a
set
of
instructions
from
the
gitlab
server
download
and
start
the
docker
image
specified,
get
the
files
from
the
project.
Git
repository
run.
All
the
commands
specified
in
the
job
and
report
back
the
result
of
the
execution
of
the
gitlab
server.
Once
the
job
has
finished,
the
docker
container
will
be
destroyed
if
docker
is
something
new
to
you
check
the
course
notes
for
a
quick
introduction.
B
B
B
In
this
case
the
executor
is
docker
machine,
and
here
on
line
four
you
will
see
here
which
image
is
being
downloaded
and
you'll
see
here,
pulling
docker
image
alpine,
because
this
is
what
we
have
specified
and
then
essentially,
the
environment
is
being
prepared
and
then,
in
the
upcoming
steps
you
get
the
files
from
the
git
repository.
So
essentially
all
the
files
that
you
have
inside
the
git
repository
will
also
be
available
here
inside
the
runner.
So
after
this
point
the
docker
container
has
been
started.
B
So
the
job
succeeds
because
there
are
no
errors
and
the
container
is
destroyed.
So
this
docker
container
that
has
been
created
in
the
beginning,
just
maybe
a
few
seconds
ago,
is
then
destroyed.
You
cannot
log
into
it.
You
cannot
see
it
anymore.
It
doesn't
exist
anymore,
so
it
has
done.
Its
job
has
executed
this
command
that
we
have
specified
and
then
it
has
been
destroyed
since
every
job
runs
in
a
container.
This
allows
for
isolation
and
flexibility.
B
B
Also,
this
architecture
ensures
that
we
can
add
or
remove
runners
as
needed,
while
the
gitlab
server
is
a
complex
piece
of
software
composed
of
multiple
services.
The
gitlab
runner
has
a
relatively
simple
installation
and
can
run
on
a
dedicated
server
or
even
on
your
laptop
now
right
here.
On
top
of
the
job,
you
have
seen
some
information
in
regards
to
the
runner.
So
the
question
is:
where
is
this
job
actually
running
and
to
be
able
to
understand
this?
B
B
So
as
long
as
that,
runner
knows
how
to
deal
with
a
docker
image
and
was
able
to
execute
these
commands,
then
we're
fine
with
any
runner.
Now.
This
is
an
oversimplified
version
of
the
gitlab
architecture.
The
main
idea
I
want
you
to
get
from
this
is
that
we
are
using
docker
containers
in
our
jobs
and
every
time
for
every
job,
the
gitlab
runner
will
start.
A
new
docker
container
will
execute
any
commands
that
we
have
and
then,
when
the
job
execution
is
done,
that
docker
container
will
be
destroyed.
B
So
now
we
have
created
this
laptop
and
have
defined
all
the
steps
inside
the
build
laptop
job
and,
of
course,
with
this
cad
command.
We
have
also
visually
verified
that
indeed,
this
computer.txt
file
contains
everything
that
we
expect,
but
we
really
want
to
automate
this
process.
We
don't
want
to
go
inside
the
job
itself
and
to
look
and
see
if
everything
was
successful.
B
B
So
this
would
be
like
a
very
basic
test,
and
what
we
can
do
here
is
to
use
the
test
command,
so
the
test
command
will
allow
us
to
check
if
this
file
has
been
created,
and
this
command
also
has
a
flag
which
we'll
gonna
write
with
dash
f
and
then
we'll
specify
the
path
to
the
file.
So
essentially,
this
command
will
ensure
that
this
file
really
exists,
and
if
it
doesn't
exist,
it
will
fail
the
job.
B
So,
let's
go
ahead,
commit
this
and
see
how
the
pipeline
looks
like
if
we're
looking
at
the
pipeline,
we'll
notice
something
unusual,
and
that
is
we're
building
the
laptop
and,
at
the
same
time
we're
testing
it.
And
essentially,
what
we
wanted
to
do
is
to
have
this
in
two
separate
stages.
Right,
we
first
build
and
then
we
test
now
currently
what
we
did
is
we
assigned
by
default
both
of
these
jobs
to
the
test
stage.
B
They
both
are
running
in
parallel,
but
of
course,
these
are
not
the
kind
of
jobs
that
we
can
execute
in
parallel
because
they
depend
on
one
another,
particularly
the
test
job
depends
on
first,
the
build
job
completely.
So
I'm
not
even
going
to
look
at
why
the
test
build
failed,
because
by
the
way
this
pipeline
looks
like
doesn't
make
a
lot
of
sense
and
we
have
to
go
back
to
the
concept
of
stages.
B
So
what
we
want
to
do
is
to
have
two
different
stages
and
we're
going
to
change
our
pipeline
configuration
and
define
these
stages.
We
want
to
have
a
build
stage
and
we
want
to
have
a
test
stage
in
gitlab.
We
can
go
ahead
and
define
another
configuration
which
is
called
stages,
and
here
as
a
list,
we
can
define
the
stages
that
we
want
to
have
so
we
can
see
here.
B
We
want
to
have
the
build
stage
and
we
want
to
have
the
test
stage
and
in
order
to
specify
which
job
belongs,
to
which
stage
in
the
job
configuration
we
will
also
say
to
which
stage
this
job
belongs.
So,
for
example,
we
want
the
build
laptop
job
to
belong
to
the
build
stage,
so
I'm
going
to
write
here
stage
and
the
stage
will
be
built.
B
B
So
let's
commit
these
changes
and
take
a
look
again
at
the
pipeline.
If
we're
looking
at
the
pipeline,
we'll
be
able
to
see
now
the
two
stages
that
we
have
build
and
test,
so
these
stages
will
run
one
after
the
other.
This
stage
does
not
start
until
the
build
stage
is
over.
So
first
we
have
to
build
a
laptop
and
then
we
can
start
with
a
test.
B
B
And
we'll
see
here
that
the
last
command
that
we
have
executed
is
this
test
command
here.
So
up
to
this
point,
everything
seems
to
be
working
fine.
This
has
been
the
last
command
that
we
have
executed
and
somehow
this
job
has
failed
in
the
next
lecture.
We'll
try
to
understand
why
do
pipelines
fail,
so
let's
jump
into
that
and
continue
debugging.
This
problem.
B
B
B
B
So
in
this
case,
what
test
is
trying
us
to
tell
is
that
it
has
tested
for
the
existence
of
this
file
and
couldn't
find
it
if
the
file
would
have
been.
There
would
have
gotten
an
exit
code
0
and
the
execution
would
have
continued
in
this
case.
The
file
is
for
some
reason,
not
there
and
we
have
retrieved
an
exit
code
1..
This
tells
gitlab
that
this
job
has
failed
and
then
the
entire
execution
will
stop.
B
If
a
job
in
the
pipeline
fails
by
default,
the
entire
pipeline
will
be
marked
as
failed
as
well.
Let
me
show
you
an
example:
let's
go
back
to
our
pipeline
definition
and
we
already
know
that
the
build
laptop
job
works.
Just
fine.
So,
let's
see
here
somewhere
in
the
middle,
we're
going
to
add
a
new
command.
B
B
So
now
I've
executed
a
pipeline
again.
You
will
see
here
that
a
build
job
failed
and
because
this
job
failed,
the
rest
of
the
pipeline
was
not
executed,
so
it
was
interrupted
as
soon
as
something
has
failed.
It
actually
doesn't
really
make
a
lot
of
sense
to
continue
with
the
rest
of
the
stages
if
one
of
the
jobs
before
has
failed,
so
let's
go
inside
it
and
take
a
look
at
the
execution
logs
to
see
what
exactly
has
happened
here
and
you'll
be
able
to
see.
B
As
I
said,
we
have
here,
the
this
echo
command
that's
being
executed.
We
have
created
this
directory,
we
have
created
this
file
and
then
we
have
exit
one
and
then
we
says
here
job
failed
exit
code,
one
now
we
have
forced
this
failure
here,
but
I
just
wanted
to
demonstrate
like
where,
in
the
execution,
you
can
notice
that
something
went
wrong
and
actually
going
through
these
commands
that
are
executed.
B
Looking
at
your
job
configuration
trying
to
figure
out
what
has
happened,
what
is
the
last
command
that
did
something
sometimes
inside
the
logs.
You
will
find
hints
in
regards
to
what
went
wrong
in
this
case.
There
are
not
a
lot
of
hints
in
terms
of
what
went
wrong,
but
these
are
also
very
simple
commands,
but
it's
very
important
to
read
the
logs
from
from
the
beginning
as
high
as
possible
to
understand
like
which
docker
image
has
been
used.
What
is
happening
before
are
there
maybe
any
any
warnings
or
any
hints
that
something
went
wrong.
B
B
Let's
go
back
to
our
pipeline
configuration
and
understand
what
are
we
doing
wrong?
As
you
probably
remember
from
the
architecture
discussion,
every
job
runs
independently,
which
means
here
the
build
laptop
job
will
start.
The
docker
container
will
create
this
folder,
and
this
file
will
put
this
text
as
instructed
and
then
at
the
end,
we'll
destroy
the
container
meaning.
The
file
that
we
had
created
inside
this
docker
container
will
be
gone
as
well,
and
test
laptop
will
start
a
completely
new
container
that
doesn't
have
this
file
there,
and
for
that
reason
it
cannot
pass
this
test.
B
B
B
This
case,
the
output
of
the
job,
what
we
are
actually
interested
in
this
job
is
this
file,
including
this
folder
and
gitlab.
Has
this
concept
of
artifacts
now
an
artifact
is
essentially
a
job
output.
It's
something
that's
coming
out
of
the
job
that
we
really
want
to
save
it's,
not
something
that
we
want
to
throw
away.
For
example,
we
may
have
used
any
other
files
or
any
other
commands
within
the
job,
but
we're
only
interested
in
the
final
output
that
we
have
here.
B
So
in
order
to
tell
gitlab
hey,
I
really
want
to
keep
this
file
in
this
folder.
We
need
to
define
the
artifacts,
so
the
artifacts
are
an
additional
configuration,
an
additional
keyword
that
we
add
to
our
pipeline,
as
the
name
tells
its
artifacts,
don't
write
it
artifact,
because
gitlab
will
not
recognize
that
and
as
a
property
of
artifacts
we're
going
to
use
paths
so
notice.
It
is
indented
it's
not
a
list
and
then
below
paths.
B
Now,
if
we're
looking
at
the
pipeline
execution,
we
now
see
that
both
building
the
laptop
and
testing
the
laptop
are
successful.
So
what
exactly
has
happened
behind
the
scenes?
Did
we
reuse
the
same
docker
container
or
what
has
happened
there
well
to
understand
exactly
what
has
happened
and
how
these
jobs
now
work?
B
So
in
this
case
the
runner
has
finished.
This
job
has
noticed
inside
the
configuration.
Oh,
I
need
to
do
something
with
these
files
and
we'll
essentially
archive
these
files
and
we'll
give
them
back
to
the
gitlab
server
and
tell
them
hey.
I'm
finished
with
this
job.
I'm
just
gonna
destroy
this
docker
image.
B
B
Now,
when
the
next
job
is
being
executed,
something
pretty
similar
is
happening.
I'm
gonna
go
here
to
the
test
laptop
job
and
what
you
see
here
in
the
beginning,
there's
also
a
new
indication
inside
the
logs
that
something
different
is
happening
and
we'll
see
here
downloading
artifacts
and
says
again
downloading
artifacts
from
coordinator,
which
essentially
means
we
now
are
downloading.
This
build
folder
inside
the
new
docker
container
that
we
have
just
created.
B
B
And
if
we
go
inside
the
build
laptop
job
here,
on
the
right
hand,
side,
you
should
see
some
information
in
regards
to
the
job
artifacts
and
in
order
for
these
job
artifacts
to
exist,
they
are
saved
even
after
the
job
has
terminated
and
you
have
the
possibility
of
inspecting
them.
So
if
you're
not
really
sure
like
what
is
the
contents
of
the
file,
you
don't
really
need
to
go
inside
the
build
pipeline
and
make
some
debugging
there.
You
could
do
that.
B
B
At
this
point,
I
wouldn't
say
that
we
are
really
done
with
testing
the
build
output.
Yes,
this
file
exists
and
we
have
now
tested
it.
So
this
is
a
very
basic
test
that
we
have
written
here,
but
how
about
checking
the
contents
of
the
file
to
see
if
it
contains
the
main
board
and
the
keyboard,
as
we
expect
again
just
using
a
command
like
cat
and
displaying
this
into
logs,
doesn't
really
help
us
automate
this.
B
So
this
is
the
grep
command
and
grep
is
a
cli
tool
that
allows
us
to
search
for
a
specific
string
in
a
file.
So
we're
going
to
specify
here,
for
example,
the
string
to
be
main
board
and
I'm
going
to
copy
it
from
above,
just
to
make
sure
I
don't
make
any
mistakes
there,
and
we
also
can
specify
in
which
file
we're
looking
for
this.
So
we
know
that
this
file
already
exists.
B
So
this
is
an
additional
test
here
that
we're
adding
on
top
of
this,
and
now
we
actually
know
that
the
file
exists,
but
now
we
want
to
check
if
this
word
main
board
is
inside
the
file
and
of
course
we
can
also
duplicate
this
and
write
an
additional
test
here.
Gonna
check
for
the
keyboard
as
well
we're
checking
for
the
main
board
and
the
keyboard
now
grep
is
really
complex
command
and
can
support
regular
expressions
and
many
other
advanced
features,
but
I
won't
get
into
those.
B
B
Tests
is
to
also
ensure
that
your
pipeline
will
fail
if
one
of
these
tests
doesn't
work,
and
sometimes
you
may
think
that
the
command
does
what
it's
supposed
to
do,
but
the
best
way
to
make
sure
that
you're
really
mastering
that
command
to
actually
introduce
an
error
inside
your
build
job
essentially
and
to
check
if
the
test
job
will
fail.
So
let's
go
ahead
and
try
that
out
so
here
inside
our
build
job.
What
can
we
do?
Well,
for
example,
we
could
try
and
make
a
change
here.
B
We've
been
looking
now
inside
the
tests
we'll
be
able
to
see
here
that
the
last
command
that
was
executed
was
grep.
You
will
see
it
in
comparison
to
the
previous
one.
There's
no
text
being
outputted
below
this
is
the
last
command
that
was
executed,
we're
getting
an
exit
code
1,
which
essentially
means
grep,
has
looked
inside.
This
file
couldn't
find
the
word
main
board.
B
I'm
gonna
go
and
add
here
main
board
back
to
the
configuration
and,
as
we
expect
now,
the
pipeline
will
also
work
again.
Tests
also
play
a
very
particular
role
when
we're
working
on
this
pipeline.
When
we're
building
software,
there
are
many
various
levels
of
testing,
but
essentially
tests,
allow
us
to
make
changes
to
our
software
or
to
our
build
process
and
to
ensure
that
everything
works.
The
same.
B
So
how
about
we
try
this
out
and
see
if
we
can
rely
on
the
tests
to
get
this
to
work,
so
I'm
going
to
simply
remove
this
touch
command
and
I'm
going
to
commit
a
configuration,
we'll
see
what's
going
on.
So
let's
take
a
look
at
the
pipeline
and
what
do
we
see
this
test?
Job
is
successful
and
if
we
really
want
to
manually
check
once
again,
we
can
go
to
the
build
laptop
job.
We
can
take
a
look
at
the
artifacts,
we'll
see
the
build
folder.
Is
there
the
computer.txt
file
is
there.
B
B
Now
this
is
a
local
variable
that
is
available
only
inside
this
script,
and
it
will
only
be
available
inside
this
job.
So
for
this
job
we
need
to
do
the
same
thing
as
well
as
you've
noticed.
Quite
often,
we
write
local
variables
in
lowercase
and
using
lowercase
helps
avoid
any
conflicts
with
any
other
existing
variables.
B
B
So
we'll
have
some
duplication
here
in
terms
of
the
configuration
we
can
also
define
a
global
variable
which
is
available
for
all
jobs
in
order
to
define
something
globally.
All
we
have
to
do
is
take
it
from
here
and
due
to
the
indentation,
we're
going
to
move
it
outside
of
the
job,
and
everything
that's
happening
here
is
on
a
global
level,
so
I'm
gonna
move
it
here
at
the
root
of
this
document.
B
Essentially,
here
we
define
variables-
and
this
is
the
name-
and
whenever
we
have
this,
we
have
to
use
this
syntax
and
of
course,
we
can
go
ahead
and
remove
it
from
the
test
job
because
it
would
also
be
available
there
now.
This
is
essentially
as
defining
an
environment
variable
which
is
available
for
the
entire
system.
B
B
B
This
is
just
something
to
keep
in
mind,
but
this
is
a
very
simple
text
here
that
we
have
so
that
will
not
cause
any
conflicts
in
general
with
the
yaml
syntax.
So
let's
commit
these
changes
and
see
if
the
pipeline
is
still
working
as
it
should,
the
pipeline
is
running
successfully
and
we
can
go
inside
the
build
job
that
we
had
here
and
we
can
take
a
look
at
the
artifacts
and
indeed
we'll
see
that
now
we
are
using
this
file,
name
laptop.txt
and
no
longer
computer.txt.
B
B
B
B
The
developers
will
build.
This
feature
pass
it
on
to
the
testers
who
would
test
it
once
ready.
The
project
manager
would
review
the
work
and,
if
all
looks
good,
would
ask
the
developers
to
pass
the
software
package
to
the
sysadmins
to
deploy
it.
As
you
can
see,
there's
a
lot
of
passing
stuff
around
and
in
the
end,
if
something
goes
wrong
and
often
things
go
wrong
in
such
situations,
everyone
is
unhappy
and
everyone
else
is
to
blame.
B
B
The
it
operations
team
is
responsible
for
building
and
maintaining
the
t
infrastructure,
ensuring
the
I.t
systems
run
smoothly
securely
and
with
as
little
downtime
as
possible.
Do
these
groups
have
something
in
common?
Yes,
of
course,
the
software
the
product.
The
problem
is
the
idea.
Operation
team
knows
very
little
about
the
software
they
need
to
operate
and
the
developers
know
very
little
about
the
infrastructure
where
the
software
is
running.
B
B
So
we
want
to
have
everyone
collaborate
instead
of
working
in
silos
and
stages
instead
of
finger,
pointing
everyone
takes
responsibility
for
the
final
outcome.
If
the
final
product
works
and
the
customers
or
users
of
the
product
are
happy,
everyone
wins
the
customers,
the
project
managers,
the
developers,
the
testers,
the
sys
admins
and
anyone
else
I
did
not
mention
everyone
wins.
B
However,
devops
is
more
than
just
culture
to
succeed.
Organizations
adopting
devops
also
focus
on
automating
their
tasks.
Manual
and
repetitive,
work
is
a
productivity
killer,
and
this
is
what
we
are
going
to
address
in
this
course
automatically
building
and
deploying
software,
which
falls
under
a
practice
called
cicd.
B
B
B
The
most
important
thing
I
want
you
to
notice
in
this
representation
is
that
this
process
never
stops.
It
goes
on
and
on
in
an
endless
loop.
This
means
that
we
continue
going
through
these
steps
with
each
iteration
or
new
version
of
the
software.
What
is
not
represented
here
is
the
feedback
that
goes
back
into
the
product.
B
B
B
B
In
this
unit,
we
will
start
working
on
a
simple
project.
We
want
to
automate
any
of
the
manual
steps
required
for
integrating
the
changes
of
multiple
developers
and
create
a
pipeline
that
will
build
and
test
the
software
we
are
creating.
In
other
words,
we
will
do
continuous
integration.
Continuous
integration
is
a
practice
and
the
first
step
when
doing
devops,
usually
we're
not
the
only
ones
working
on
a
project
and
when
we're
doing
continuous
integration,
we're
integrating
our
code
with
the
code
other
developers
created.
B
It
means
that
every
time
we
make
changes
to
the
code,
that
code
is
being
tested
and
integrated
with
the
work
someone
else
did.
It
is
called
continuous
integration
because
we
integrate
work
continuously.
As
it
happens,
we
don't
wait
for
anything
to
do
that.
We
don't
want
to
integrate
work
once
per
week
or
once
per
month,
as
it
can
already
be
too
late
or
too
costly
to
resolve
some
issues.
The
more
we
wait,
the
higher
the
chances
we
will
run
into
integration
issues.
B
In
this
unit
we
will
use
gitlab
to
verify
any
changes
and
integrate
them
in
the
project.
I'm
going
to
be
honest
with
you
as
we
build
more
advanced
pipelines,
you
will
most
likely
encounter
some
issues.
If
you
haven't
done
it
yet
go
right
now
to
the
video
description
and
open
the
course
notes
there,
you
will
find
important
resources
and
troubleshooting
tips.
Finally,
let's
do
a
quick
recap
when
we
have
multiple
developers
working
against
the
same
code,
repository
ci
is
a
pipeline
that
allows
us
to
add
and
integrate
our
changes
even
multiple
times
per
day.
B
B
Now
we
don't
want
to
get
too
much
into
the
technical
details,
because
they
don't
really
matter
so
much
at
this
point,
but
the
first
step
in
order
to
be
able
to
make
changes
to
this
repository
is
to
make
a
copy
of
it.
So,
for
example,
if
you're
trying
here
to
open
a
web
ide
in
this
project,
I
will
get
this
option
to
fork
the
project
by
the
way
you
will
find
a
link
to
this
project
in
the
course
notes,
and
the
course
notes
are
linked
in
the
video
description.
B
B
Essentially,
here
in
this
project,
we
have
a
couple
of
files.
One
of
these
files
is
this
package.json
file
and
this
file
essentially
documents
which
requirements
this
project
has,
and
in
order
to
actually
run
this
project,
we
first
need
to
install
this
requirement
so
locally.
I
already
have
a
copy
of
this
project
and
the
command
to
install
these
requirements
is
called
yarn
install.
B
B
And
during
this
process,
what
has
actually
happened
is
that
a
build
folder
has
been
created
and
this
build
folder
contains
multiple
files
that
are
required
for
the
website.
So
let
me
give
you
an
idea
how
this
website
looks
like
and
what
we
actually
did
here.
So
I'm
going
to
run
the
command
serv
minus
s
and
going
to
specify
the
build
folder
and
now
essentially
we
have
started
a
server.
We
started
an
http
server
which
is
serving
the
files
available
there.
B
So
I'm
going
to
open
this
address
in
a
new
tab,
and
this
is
how
the
website
looks
like.
So
essentially,
what
we're
trying
to
do
in
this
section
is
to
automate
these
steps,
so
we
want
to
install
the
dependencies
we
want
to
create
a
build.
We
want
to
test
the
bill
to
see
if
the
website
is
working
and
I've
shown
you
these
tools,
because
it
is
always
a
good
idea
to
be
familiar
with
the
cli
tools
that
we'll
be
using
in
gitlab
ci.
B
Now
in
gitlab,
we
try
to
automate
any
manual
steps,
but
before
we
do
that,
we
must
know
and
understand
these
steps.
We
cannot
jump
into
automation
before
we
understand
what
the
commands
that
we
want
to
do
are
actually
doing
now.
I'm
not
really
referring,
in
particular,
to
the
commands
that
I've
shown
you
here,
because
they
are
specific
to
this
project.
You
may
be
using
python
or
java
or
anything
else,
so
you
don't
need
to
be
familiar
with
these
tools.
In
particular,
I
will
explain
to
you
what
they
do
and
how
they
work.
B
B
So
we
have
here
in
the
source
files
you
will
see
here
an
app.js
and
any
other
file.
So
essentially
the
build
process
will
take
all
these
files
and
will
make
them
smaller
and
will
put
them
together
in
a
way
other
programming
languages
may
need
to
have
a
compilation
step
or
any
other
steps.
So
typically
something
happens
in
the
build
process
where
we
actually
are
putting
our
project
together.
B
B
The
first
step
is
to
essentially
run
yarn
and
yarn
is
a
tool
that
is
helping
us
build
this
project.
This
is
specific
for
javascript
projects.
Essentially
node.js
projects
and
yarn
is
a
tool
that
can
be
used
for
getting
dependencies.
They
can
also
be
used
for
building
the
software,
so
the
command
that
we
are
running
here
is
build.
B
Locally,
as
you
remember,
the
first
thing
that
I
did
was
to
do
a
yarn
install
to
install
dependencies,
and
this
is
something
that
needs
to
happen
before
the
build.
So
every
time
when
we
are
building
this
website,
we
need
to
get
the
dependencies
to
make
sure
that
we
have
all
the
dependencies
that
we
need
and
to
ensure
that
all
of
them
are
up
to
date
and
because
they
don't
remain
anywhere
in
the
container.
We
need
to
do
that
all
the
time
and
normally
locally
would
do
that
only
when
we
need
to
do
that.
B
B
B
B
Well,
we
have
to
look
like
what
is
the
command
that
we
try
to
execute
and
we'll
find
here
something
saying
that
yarn
not
found
so
essentially
what
this
means
is
that
the
docker
image
that
we
have
used
does
not
have
yarn.
So
how
do
we
install
yarn
or
how
do
we
normally
do
this
now?
The
thing
is
we
don't
have
to
use
this
alpine
image
that
you
have
seen
here
essentially
for
most
projects,
and
this
includes
node.js,
which
is
actually
what
we're
using
here
and
which
I
already
have
installed
locally.
B
This
is
why
it
worked
locally.
There
are
official
docker
images
that
we
can
use
and
the
central
repository
for
such
images
is
docker
hub.
So
this
is
a
public
docker
repository.
So,
for
example,
if
I'm
typing
here
node,
I
will
be
able
to
find
here
the
official
image
for
node,
and
I
can
essentially
instead
of
using
alpine.
I
can
simply
use
here
node.
B
B
Sometimes
it
may
work,
but
sometimes
the
latest
version
may
contain
some
breaking
changes
which
may
lead
to
things
not
working
anymore
in
our
pipeline
if
one
day
we're
getting
one
version
and
next
day
we're
getting
something
else
without
us
making
any
changes
things
may
break.
So.
For
that
reason
it
is
generally
not
a
good
idea
to
just
use
node,
for
example,
or
just
to
use
alpine
as
we
have
done
before.
B
It
is
better
to
specify
a
version
to
put
it
down,
like
which
version
do
we
need
here
and
to
write
it
down
as
essentially
as
a
tag
now?
How
do
we
know?
Which
version
do
we
need
now
for
node?
What
we're
going
to
do
here,
we're
going
to
head
to
nodejs.org
and
here
you'll,
see
here
two
versions
that
are
currently
available
for
download.
B
What
we
want
to
do
is
we
want
to
use
the
lts
version
now.
You
will
see
here
that
the
latest
lts
version
that
I'm
currently
seeing
right
now
is
16.13.2
now
what's
important.
Here
is
the
major
version
which
is
16.
when
you
are
watching
this.
It's
important
that
you
come
to
this
page
and
you
look
at
a
number
here.
Probably
it
will
increase
over
time
most
likely
it
will
increase
over
time.
You'll
get
a
different
version.
It's
important
here
that
you
get
the
latest
lts
version
that
you
see
here
all
right.
B
So
let's
go
inside
our
pipeline
and
then
write
this
16
version
here.
So
the
way
we're
going
to
do
here,
we
have
node,
which
is
the
base
image,
and
then
we
can
specify
a
tag
by
writing
column
and
then
I'm
going
to
write
16
right
and
most
likely.
This
version
is
already
available
on
node,
but
you
can
always
make
sure
and
check
here,
go
to
the
tags
and
see
if
this
specific
tag
is
then
available
there,
but
this
major
tags.
Typically,
they
are
available
and
will
have
no
issues
downloading
this.
B
B
But
fortunately
everything
is
then
successful
in
the
end-
and
this
is
the
most
important
step
at
this
point-
we
don't
want
to
waste
a
lot
of
time
when
we
are
actually
executing
these
builds,
and
I
know
for
a
fact
that
this
note
image
is
a
few
hundred
megabytes
large
in
size.
This
is
because
it
contains
a
lot
of
tools
and
a
lot
of
dependencies
which
we
may
not
need.
B
B
So
if
we're
selecting
to
use
this
image
every
time
we'll
have
to
download
300
something
megabytes,
that's
a
lot
of
download
and
a
lot
of
time
that
we
are
wasting
just
to
start
this
image.
So
for
that
reason,
what
I
typically
do
is
I
go
here
in
the
tags
and
I
search
for
alpine,
sometimes
slim
or
other
images,
can
also
be
a
good
idea,
and
what
I'm
interested
in
is
something
like
16
alpine.
So
let
me
write
directly
16
alpine,
and
this
looks
absolutely
fine
here.
B
B
B
So
this
job
still
needed
quite
a
bit
of
time,
one
minute
and
26
seconds.
You
may
see
this
duration
varying,
but
generally,
it
is
a
very
good
practice
to
use
images
that
are
as
small
as
possible,
because
this
can
save
time,
and
you
may
see
that
maybe
this
job
will
even
go
below
one
minute.
It
really
depends
like
how
fast
the
runner
will
pick
up
the
job
and
will
able
to
start
this
image.
B
B
Now
the
alpine
image
didn't
work
because
it
didn't
have
node
js
installed
now.
Essentially,
what
we're
using
here
is
essentially
the
same
image
as
before
the
same
alpine
image
alpine
linux
image,
but
it
has
node
installed,
so
it
has
the
dependency
that
we
need
and
this
node
dependency
contains
yarn.
This
is
why
yarn
didn't
work
before
now.
It's
working
just
fine
and
it's
building
the
project.
B
The
most
important
thing
that
you
can
do
when
you're
learning
something
new
is
practicing,
and
I
want
to
give
you
the
opportunity
in
this
course
to
practice
along
so
not
just
following
along
what
I'm
doing,
but
you
also
have
the
opportunity
to
do
something
on
your
own
and
for
the
next
assignment.
I
already
think
that
you
have
to
know
how
necessary,
in
order
to
do
that,
what
we're
trying
to
do
is
to
create
two
new
additional
jobs
in
this
pipeline.
This
is
your
job
now
to
write
these
jobs.
So
what
are
these
jobs
all
about?
B
The
first
job
is
trying
to
test
the
website,
and
the
website
is
currently
inside
the
build
folders.
If
I
go
inside
the
build
folder,
you
will
see
here
a
list
of
files.
Now
your
job
is
to
ensure
that
the
index.html
file
is
available
inside
the
build
folder.
So
this
is
the
first
job
that
you
need
to
create.
B
The
upcoming
lesson
will
contain
the
solution
to
this,
but
please
it's
super
important
that
you
pause
this
video
and
try
this
on
your
own.
Try
as
much
as
you
can,
because
this
is
the
best
way
to
learn
and
to
ensure
that
what
I'm
showing
you
in
this
course
is
something
that
you
will
be
able
to
use
in
your
projects
as
well.
B
I
hope
you
have
tried
to
solve
this
assignment
on
your
own,
but
anyway.
This
is
how
I
would
approach
this
problem,
so
I'm
here
inside
the
editor
for
the
pipeline
and,
let's
begin
just
with
the
skeleton.
So
what
are
we
trying
to
do?
We
have
two
new
jobs.
We
have
test
website
where
we're
essentially
trying
to
test
the
output
of
the
build
website
job
and
we
also
have
a
unit
tests
job.
So,
first
of
all,
we
have
to
think
about
stages.
B
What
we
want
to
do
happens
essentially
after
the
build.
Well,
it
really
depends
a
bit
so,
for
example,
the
test
website.
This
definitely
needs
to
happen
after
the
build
the
unit
tests.
They
don't
necessarily
need
to
happen
after
the
build,
but
we're
going
to
put
them
inside
a
different
stage
as
well.
B
So
let's
go
ahead
and
define
the
stages
here,
so
we're
going
to
have
two
stages:
we're
going
to
have
here
built
and
we're
going
to
have
another
stage
which
is
called
test
and
what
we
need
to
do
is
to
assign
this
jobs
to
a
stage.
So
the
build
will
be
assigned
to
the
stage
built,
of
course,
and
then
the
test
website
will
be
assigned
to
the
stage
test
and
the
same
goes
with
the
unit
test
right
in
order
to
test
the
website.
What
we
are
trying
to
do.
B
B
Now
what
we
haven't
done
so
far
is
inside
this
build
website
job
to
declare
artifacts.
So
as
it
is
right
now,
this
command
will
fail.
So
what
we
have
to
do
here
is,
of
course,
think
about
the
artifacts
so
which
artifacts
do
you
have?
We
have
to
define
the
paths
and
the
only
paths
that
we're
interested
in
is
the
build
path.
So
then
this
will
be
able
to
test
for
this
file.
B
The
next
thing
we
need
to
think
about
is
which
image
do
we
need
for
test
website?
So,
theoretically,
we
could
use
node
16,
but
actually
this
command
test
doesn't
require
something
like
that.
So
we
could
just
use
alpine
and
test
is
a
pretty
general
command.
So
we
don't
have
to
worry
about
specifying
a
version
or
anything
like
that.
B
B
So,
let's
double
check
to
make
sure
that
we
have
everything
in
place.
We
have
defined
two
stages,
build
and
test.
We
have
assigned
build
website
to
the
stage
build
and
we
have
assigned
the
test
website
and
the
unit
tests
we
have
assigned
them
both
to
the
stage
test.
So
this
means
these
two
jobs
will
run
in
parallel
here,
we're
just
using
the
test
command
to
verify.
If
this
file
exists,
and
here
we're
installing
the
dependencies
and
then
running
the
tests,
so
I'm
gonna
go
ahead,
commit
these
changes
and
we'll
inspect
together.
The
pipeline.
B
So
if
looking
here
at
test
website,
what
do
we
see?
Well,
we
see
here
the
command
test,
minus
f,
so
it's
testing
if
this
file
actually
exists,
if
it's
part
of
the
job
artifacts.
Of
course,
if
you're
looking
inside
the
build
website,
you
can
go
here
and
look
at
the
artifacts
see
here.
The
build
folder
we'll
see
here,
multiple
files,
so
not
only
the
index.html
file
but
we'll
see
here
some
images,
some
additional
files
that
we
don't
really
care
so
much
at
this
point,
but
they
are
available
there.
B
B
B
B
B
B
B
B
The
main
branch
should
always
work
and
allow
us
to
deliver
new
versions
of
the
software
anytime.
We
need
to
do
that.
So
how
do
we
solve
this?
The
idea
is
simple.
We
just
don't
push
untested
work
in
the
main
branch,
since
we
can't
trust
that
developers
remember
to
run
all
tests
locally
before
pushing
a
change.
We
want
to
take
advantage
of
automation
and
gitlab
to
automatically
run
the
tests
before
adding
any
changes
to
the
main
branch.
B
B
There
are
various
git
workflows,
but
we
will
use
one
that
is
simple
to
understand.
It's
called
the
git
feature
branch
workflow.
The
idea
is
simple:
for
each
new
feature,
bug
idea,
experiment
or
change.
We
want
to
make.
We
create
a
new
branch.
We
push
our
changes
there.
Let
the
pipeline
run
on
the
branch
and,
if
everything
seems
okay,
we
can
integrate
the
changes
in
the
main
branch,
so
in
other
words,
we
simulate
running
the
main
branch
before
we
actually
run
the
main
branch.
B
If
our
branch
pipeline
fails
no
worries,
all
other
developers
are
unaffected
and
we
can
focus
on
fixing
it
or
if
we
don't
like
how
things
turned
out,
we
can
just
abandon
the
branch
and
delete
it
no
hard
feelings
there,
either
as
part
of
working
with
branches.
We
create
a
merge
request
that
allows
other
developers
to
review
our
code
before
it
gets
merged.
B
B
So
how
can
we
create
merge
requests
in
gitlab,
first
of
all
to
ensure
that
the
chances
of
breaking
the
main
branch
are
as
small
as
possible?
We
need
to
tweak
a
few
settings
so
we're
going
to
go
here
to
settings
general
and
right
here
in
the
middle.
You
should
see.
Merge
requests,
I'm
going
to
expand
that
and
what
I
like
to
use
when
using
merge
requests
is
to
use
this
fast
forward.
Merge
essentially,
no
merge
commits
are
created,
and
generally
the
history
remains
much
cleaner.
B
There's
also,
the
possibility
of
squashing
commits
directly
from
gitlab-
and
you
can
put
it
here
and
encourage
scratching
commits-
is
when
you're
pushing
multiple
changes
to
a
branch
and
instead
of
pushing
all
these
changes
back
into
the
main
branch
we
scratch
them
all
together.
So
we
essentially
like
we
have
only
one
commit
again,
makes
the
history
much
easier
to
read
going
forward
here
in
the
merge
checks.
We
want
to
make
sure
that
the
pipelines
succeed
before
we
are
merging
something.
B
So
essentially
we
don't
want
to
commit
changes
to
the
main
branch
anymore.
We
want
to
prohibit
that,
so
nobody
will
be
allowed
to
directly
commit
something
to
the
main
branch.
So,
in
order
to
do
that,
we
have
to
go
here
to
allow
to
push
and
instead
of
having
something
selected
or
some
role
selected
here,
can
I
use
no
one,
so
no
one
is
allowed
to
push
to
this
protected
branch
only
if
it
goes
through
a
merge
request.
B
Open
the
pipeline
file,
and
now,
let's
say
I'm
trying
to
add
here
a
new
stage
where
I'm
trying
to
do
some
checks.
For
example,
there
is
linter
that
I
can
use
and
linter
is
simply
a
static
code,
analyzes
tool
that
is
used
to
identify
potential
programming
errors,
stylistic
issues,
and
sometimes
you
know
questionable
code
constructs.
B
Since
it
is
static,
it
does
not
actually
run
the
application,
it
just
looks
at
the
source
code
and
most
projects
do
tend
to
have
such
linter
inside
and
just
for
the
sake
of
completion.
I
also
want
to
add
here
linter,
so
I'm
gonna
go
ahead
here
and
I'm
gonna
write
here
linter.
This
is
the
name
of
the
job,
the
image
that
I'm
using
is
still
node
here
and
the
reason
for
that
is
inside
the
script.
B
The
command
that
we
are
running
is
actually
yarn
lint
and,
of
course,
we
also
need
to
install
all
dependencies,
and
additionally,
we
have
the
possibility
of
assigning
this
job
to
a
stage
now
by
default,
gitlab
comes
with
some
predefined
stages.
Prefined
stages
include
a
press
stage,
build
stage
a
test
stage,
deploy
stage
and
post
stage.
B
The
same
goes,
for
example,
here
with
the
unit
tests.
The
unit
tests
are
also
not
dependent
on
the
build,
so
I
could
go
ahead
and
move
them
to
the
same
stage
just
to
make
this
clear,
so
there's
a
dot
there,
and
because
this
is
a
predefined
stage,
we
don't
need
to
redefine
it
again,
so
I
could
go
ahead
and
write
it
here,
but
it's
not
really
needed
all
right
now
going
back
here.
B
The
editor
that
I
opened
here
is
from
the
main
branch
you
will
see
here.
Main
is
selected
right
and
let's
go
ahead
and
commit
and
you'll
see
here,
I'm
no
longer
allowed
to
commit
to
the
main
branch.
So
this
is
by
default
disabled
the
settings
that
we
did
ensure
that
we
are
no
longer
allowed
to
directly
make
changes
to
the
main
branch.
So
we
have
to
create
a
new
branch.
B
Quite
often
when
we
are
creating
branches,
we
tend
to
use
some
naming
conventions
now
totally
up
to
you
what
you
want
to
use
or
how
your
organization
uses
that
quite
often
you
will
have
something
like
feature,
for
example,
for
what
slash
and
then
a
name
of
a
feature.
Sometimes
you
may
reference
a
ticket
or
something
like
that.
So,
for
example,
you
have
your
ticket
number
one.
Two
three
four
add
linter,
so
you
will
see
here,
I'm
adding
no
spaces
or
anything
like
that.
It's
totally
up
to
you
how
you
use
these
forward.
B
B
The
branch
name
will
be
feature
forward,
slash
and
some
name,
I'm
gonna
click
here
on
commit
this
will
open
an
additional
window,
so
the
branch
has
been
created,
but
now
I'm
also
opening
a
new
merge
request,
and
here
in
the
merge
request,
there
are
a
few
things
that
I
should
fill
out.
So,
for
example,
the
title
is
not
very
suggestive,
so
I'm
going
to
write
here,
something
like
add
linter
to
the
project.
B
B
So
what
is
happening
here
is
that
the
changes
that
we
made,
which
you
will
be
able
to
see
here,
what
we
do
do
we
added
here
a
new
stage.
We
added
here
a
linter,
also
made
some
changes
to
the
do
the
unit
test,
so
we
can
go
ahead
and
look
at
these
changes.
We
have
here
a
pipeline,
that's
executing
it's
going
through
all
these
stages.
We
have
here
the
pre-stage,
the
build
stage
and
the
test
stage,
and
now
we
can
simulate
running
this
pipeline
to
see
if
it
fails.
B
B
The
next
important
step
in
the
life
of
a
merge
request
is
the
review
process,
especially
the
code
review,
where
somebody
else
from
the
team
is
taking
a
look
at
our
changes
and
is
giving
us
feedback
now.
Just
in
case
you
don't
know
where
your
merge
request
is.
You
will
find
here
on
the
left
hand,
side.
This
panel
says
here
merge,
requests
and
we'll
indicate
how
many
merge
requests
are
open
at
this
time.
So
we
only
have
one
merge
request
you
will
see
here.
B
This
is
the
title
of
the
merge
request,
so
we're
trying
to
add
linter
and
you'll
find
here
like
the
most
important
information.
So
this
is
a
request
to
merge
this
feature
into
the
main
branch
right.
If
you
need
to
make
changes
to
it,
you
can
open
this
branch
in
the
id
and
continue
making
changes
to
it.
B
B
You
can
compare
these
files
and
someone
can
also
leave
comments
here.
So,
for
example,
I
could
simply
click
here
on
the
line
and
ask:
why
did
you
use
the
prestage
right
and
you
can
add
a
comment
now?
Where
does
this
merge
request?
Go
now?
Typically,
when
someone
has
reviewed
this
can
go
ahead
here
and
approve
it.
B
Comments
can
appear
so,
for
example,
here
I've
added
a
question
to
these
changes,
so
maybe
there's
some
discussion
that
needs
to
happen.
There.
Feedback
can
be
gathered
from
different
people
involved
and
this
feedback
may
need
to
be
integrated.
So,
for
example,
as
I
mentioned,
you
can
still
do
changes
to
this.
The
merge
request
will
always
have
the
latest
changes,
so
we
can
make
more
commits.
B
It's
also
possible
that
for
some
reason
these
changes
are
no
longer
needed.
They
are
wrong
or
the
approach
that
was
taken
doesn't
really
make
sense.
So
so,
there's
also
the
possibility
of
closing
a
merge
request.
You
can
go
here
and
see
closed,
merge
requests,
so
this
will
be
closed
and
no
changes
will
be
merged,
so
that's
also
a
possibility,
but
typically
what
happens
after
the
review
after
some
changes
have
been
integrated.
B
We're
gonna
go
here
on
this
merge
button
and
what
is
happening
here
is
we
are
merging
this
branch
into
the
main
branch
and
there
are
two
options
that
are
enabled
by
default:
the
source
branch,
so
the
branch
that
we
have
created
will
be
deleted,
which
makes
sense
because
we
don't
need
it
anymore
and
in
case
we
have
multiple
commits.
We
can
also
squash
those
commits-
and
in
this
case
we
have
only
one
commit.
B
This
merge
button
is
available
only
if
the
pipeline
succeeded,
but
our
pipeline
did
succeed.
So
this
is
why
we
can
see
it
so
now.
Gitlab
will
merge
these
changes
into
the
main
branch
and
again
a
new
pipeline
will
be
generated,
and
this
is
the
pipeline
for
the
main
branch.
So
you
will
see
exactly
the
changes
that
we
made.
B
We
have
here
the
pre-stage,
the
build
and
the
test.
These
are
all
available
here
and
exactly
what
we
have
run
inside
a
merge
request.
The
pipeline
is
running
again
against
the
main
branch,
and
this
is
needed
just
to
ensure
that
indeed,
everything
is
working,
fine
and
that
there
are
no
integration
issues
or
no
other
issues.
So
it's
a
good
practice,
not
something
that
may
seem
that
it's
happening
somehow
as
a
duplicate,
it's
actually
important
to
ensure
that
the
main
pipeline
is
working
properly.
B
This
is
what
we
care
most
about
to
ensure
that
this
main
pipeline
is
working
as
it
should
work.
That's
the
reason
why
we
have
reviewed
the
merge
request
to
ensure
that
whatever
we're
changing
here
in
the
main
branch
is
as
good
as
it
gets,
and
that
the
chances
of
breaking
something
are
drastically
reduced.
B
How
can
we
replicate
this
in
gitlab?
Essentially,
we
want
to
make
sure
that
we
indeed
have
a
website,
that's
running
that
can
be
started
by
a
server,
and
we
want
to
make
sure
that
you
know.
For
example,
this
text
here
shows
up,
learn:
gitlab
ci.
How
can
we
do
that
inside
the
pipeline?
Currently
we're
just
checking
if
we
have
a
file
which
is
called
index.html?
B
That's
not
really
telling
us
the
entire
story,
so
this
lecture
we're
going
to
take
a
look
at
how
we
can
do
essentially,
what's
sometimes
called
an
integration
test,
we're
really
testing
that
the
final
product
is
really
working.
I'm
going
to
open
up
the
web
ide
and
inside
the
pipeline
file
kind
of
focus
on
this
test
website
job.
B
So
this
current
test
is
not
really
that
helpful.
We
want
to
do
something
else.
So,
for
example,
you
have
seen
me
running
the
following
command,
which
has
been
serve
dash
s
build
right,
so
this
takes
the
build
and
we'll
be
able
to
start
a
server,
and
then
we
can
take
a
look
at
what's
going
on
so
we're
going
to
remove
this
because
we
don't
need
that
anymore.
B
I'm
going
to
start
here
server
and
just
because
I
want
to
make
sure
that
this
is
running
as
fast
as
possible
and
that
we're
not
wasting
a
lot
of
time,
I'm
going
to
go
ahead
and
disable
some
jobs.
So
I'm
going
to
disable
here
the
linter
job-
that's
not
really
needed.
In
the
beginning,
I'm
going
to
also
disable
the
unit
test
so
to
disable
the
job,
you
simply
add
a
dot
in
front
of
the
job
name
and
that
job
will
be
disabled.
B
B
If
you're
looking
at
the
pipeline,
we'll
see
that
the
build
has
succeeded,
but
there
seems
to
be
an
issue
with
testing
the
website,
so
let's
take
a
look
at
the
logs
and
understand
what
is
going
on
we'll
try
to
understand
here.
What
is
the
error?
We're
getting
an
exit
code,
the
last
command
that
we
executed
is
serv
and
we're
getting
here
surf,
not
found
so
again
we're
trying
to
run
a
command.
B
This
command
was
working
locally
for
me,
but
at
least
the
docker
image
that
we
are
using
here
does
not
have
this
command
so
which
docker
image.
Are
we
using
we're
using
alpine
and
alpine
does
not
have
this
command,
so
we
need
to
find
a
way
to
install
this
command
as
well.
So
for
that
we're
going
to
go
back
to
the
editor,
we
can
go
here
from
the
merge
requests,
click
on
the
merge
request
and
we'll
find
here
open
in
web
id
and
then
we'll
be
able
to
see
here.
B
B
B
I'm
gonna
see
here
yarn,
add
serve
and
actually
you're
going
to
use
this
as
a
global
dependency.
So
I'm
going
to
write
here
global,
so
using
yarn
global,
add
serve
right.
This
will
ensure
that
we
now
have
serve.
We
can
use
yarn
because
we
now
have
the
node
image
again.
This
time
we
are
already
in
a
merge
request,
so
we
can
go
ahead.
B
B
So
what
is
going
on?
Well,
we
have
started
an
http
server
which
is
serving
these
files
inside
this
gitlab
job
and
when
does
a
server
end?
Well,
it
never
ends.
That's
the
purpose
of
the
server.
It
will
serve
these
files
indefinitely
and,
of
course,
this
approach
that
we
started
here
is
not
good,
because
we're
gonna
wait
here
forever.
B
B
So
this
is
an
important
concept
when
you're
starting
a
server
inside
a
job
that
job
will
never
end
or
will
run
into
this
timeout,
so
be
very
careful.
When
you're
doing
things
like
that,
now
I'm
going
to
go
ahead
and
manually,
stop
this
job.
You
will
see
here
this
cancel
button
here.
We
cannot
wait
forever,
so
I'm
going
to
cancel
it
and
then
this
will
stop
now.
There
is
a
way
to
start
a
server
and
there
is
a
way
to
check
that
text,
but
we
still
need
to
make
some
changes.
B
Let's
go
inside
the
code,
open
the
pipeline
and
see
what
we
have
here
now.
What
do
we
want
to
do
so?
We
have
managed
to
start
this
server.
It
will
run
forever.
But
how
do
we
test
something?
So
in
order
to
test
something,
we
have
to
execute
the
upcoming
command
and
in
order
to
actually
get
this
information
we
need
essentially
an
http
client.
We
need
another
tool
that
will
go
to
this
address,
which
is
you
have
seen
there.
B
B
So
curl
is
a
tool
that
will
be
able
to
go
to
this
address,
download
the
website,
and
then
we
can
do
something.
I'm
gonna
use
here
a
pipe,
so
this
will
send
the
output
of
this
website
to
the
next
tool
and,
as
you
remember,
from
working
with
files,
we
have
the
possibility
of
using
grep,
so
grep
will
search
for
a
specific
string.
B
B
Then
we
have
this
curl
command
and
in
grab
we're
getting
the
website,
and
then
we
can
search
for
this
string.
We
still
haven't
solved
the
problem
with
the
server
running
forever.
We
don't
want
it
to
run
forever,
so
we're
going
to
use
a
small
trick-
and
I
use
here
this
and
sign,
and
what
will
this
do
is
to
start
this
process
in
the
background,
so
it
will
essentially
still
start
the
server,
but
it
will
be
in
the
background
and
it
will
not
prevent
this
job
from
stopping
so
when
the
curl
command
has
been
executed.
B
This
job
will
also
stop
because
this
command
will
be
executed
right
after
this
one
curl
will
not
wait
for
the
server
to
actually
start.
The
server
needs
a
few
seconds
to
start,
and
in
order
to
wait
for
that,
we
don't
know
exactly
when
this
will
start.
So
we're
going
to
use
another
command,
which
is
called
sleep
and
sleep
will
take
a
parameter
here,
so
this
will
be
in
seconds,
so
we
can
decide
how
many
seconds
we
want
to
wait
just
to
be
sure.
I'm
gonna
use
here
10
seconds.
B
B
B
B
Curl
has
downloaded
this
and
then
has
sent
this
to
grab,
but
we
are
getting
here
an
exit
code,
one
because
we're
not
seeing
any
errors
from
curl,
which
means
that
curl
has
downloaded
this
information.
We
have
to
wonder
like
what's
going
on
with
grep,
why
isn't
this
information
available
there
in
the
response?
B
B
What
curl
is
actually
doing
is
downloading
this
now
this
is
the
index.html
file,
and
this
index.html
file
will
download
other
things
in
the
background
we'll
download
some
scripts
so
that
information
there
is
not
really
coming
from
the
page
from
this
page
that
we
are
getting
with
curl
and
curl
doesn't
have
the
possibility
of
actually
rendering
javascript
and
images
and
so
on.
So
it's
very
basic
tool.
B
What
we
have
here,
for
example,
is
this
react
app
in
the
title.
So
how
about?
If
we
change
this-
and
we
are
asserting
that
we
have
this
title,
so
let's
go
ahead
in
the
application
and
figure
out
where
this
react
app
appears.
Now
I
change
it
to
something
with
git
lab,
so,
instead
of
using
learn,
gitlab
we're
gonna,
simply
try
and
use
react
app,
because
we
know
this
is
available
here
so
from
the
project
I'm
going
to
open
the
web
ide.
B
B
The
linter
has
been
disabled
and
then
we're
gonna
put
all
these
changes
together,
commit
them
to
the
branch
we're
not
going
to
start
here.
A
new
merch
request.
We
already
have
a
merge
request,
so
we're
going
to
disable
that
if
it's
enabled
I'm
going
to
commit
again
and
finally,
the
tests
are
working,
so
let's
go
again
and
inspect
the
job
logs.
So
what
we
find
here
well,
we
have
everything
that
we
are
interested
in
and
particularly
the
last
part,
was
the
one
that
was
failing
and
now
it's
able
to
locate
this
inside
here.
B
So
this
is
why
you're
getting
back
the
entire
text
you'll
see
here,
react
app.
It's
in
the
response,
so
curl
and
grab
now
work
together
and
this
job
succeeds
has
been
a
bit
of
work.
But
I'm
happy
that
we
have
this
test
and
it
ensures
that
our
pipeline
really
works
a
bit
better
and
that
we're
more
confident
in
what
we're
building
I'm
gonna
go
here
to
the
merge
request.
You
will
see
here
we
have
four
commits.
B
We
have
here,
essentially
the
changes
that
we
made,
so
we
reverted
all
the
other
jobs
that
we
have
disabled
and
we
just
have
adapted
this
test
website.
So
from
that
point
of
view,
everything
is
good.
We're
gonna
squash
here
the
commits,
so
we
can
also
modify
the
commit
message.
Commit
messages,
add
integration
test,
so
that
looks
good.
B
So
currently,
our
continuous
integration
pipeline
looks
like
this.
It
is
divided
in
three
separate
stages
and
the
way
I've
structured.
This
is
just
an
example.
There
is
no
hard
rule.
Different
programming,
languages
and
technologies
may
require
a
different
order.
You
are
smart
people
and
I'm
sure
you'll
be
able
to
apply
these
ideas
to
whatever
you're
doing.
B
However,
I
just
wanted
to
mention
two
principles
or
guidelines
that
you
should
consider.
One
of
the
most
important
aspects
is
failing
fast.
For
example,
we
want
to
ensure
that
the
most
common
reasons
why
pipeline
would
fail
are
detected
early,
for
example,
here,
linting
and
unit
test,
quite
often
developers
forget
to
check
their
linting,
make
a
mistake
or
forget
to
run
the
unit
test.
So
if
we
notice
that
this
is
happening
a
lot,
it
really
makes
sense
to
put
this
as
the
first
stage
of
the
pipeline.
B
They
typically
don't
need
a
lot
of
time,
so
the
faster
they
fail,
the
better
it
is
because
we'll
get
fast
feedback,
we'll
use
less
resources
and,
of
course,
we
know
if
we're
running
here
in
parallel
jobs
that
are
similar
in
size.
That's
also
a
relatively
good
way
of
grouping
jobs
together.
Now
you
also
have
to
be
very
careful
when
you're
grouping
jobs
in
peril.
B
For
example,
if
you
have
a
job
that
finishes
in
15
seconds
and
you
have
a
job
that
finishes
in
five
minutes,
for
example,
let's
say
here:
linter
needs
15
seconds
unit
test
needs
five
minutes.
If
the
lender
fails
after
just
five
seconds,
the
unit
test
will
still
run
for
five
minutes,
there's
no,
no
stopping
there,
so
it
does
make
sense
to
put
in
parallel
jobs
that
are
similar
in
size.
B
Another
aspect
that
you
need
to
consider
are
the
dependencies
between
the
jobs,
so
what
I
mean
by
dependencies?
Well,
for
example,
here
we
cannot
test
the
website
until
we
have
actually
built
the
website,
but
the
linter
and
the
unit
tests.
They
don't
depend
on
the
build
output.
So
for
that
reason
we
can
run
them
before
the
build.
We
can
run
them
after
a
build.
We
don't
have
a
dependency
there,
but
in
this
case
for
the
website,
we
are
dependent
on
the
job
artifacts
because
we're
using
them
for
something.
B
So
from
that
perspective,
we
always
need
to
have
the
build
job
before
here.
We
can
test
the
website.
So
if
jobs
have
dependencies
between
them,
they
need
to
be
in
different
stages.
Now
I
have
to
say
that
there
is
no
replacement
for
experimentation
and
trying
things
on
your
own.
If
you
are
unsure,
if
something
works
or
not
just
give
it
a
try
and
see
how
far
you
can
go
and
why
that
pipeline
fails,
as
you
have
noticed
so
far,
our
pipeline
does
require
a
bit
of
time
and
actually
optimizing.
B
B
B
B
We
could
theoretically
put
everything
in
a
single
job,
but
I'm
just
doing
it
now
for
performance
purposes
and
in
order
to
save
a
bit
of
time,
we're
just
gonna,
stick
to
this
two
different
stages:
the
build
stage
and
the
test
stage,
and
even
if
you're
doing
here
a
bit
of
testing,
it's
acceptable
now
to
be
able
to
save
a
bit
of
time,
and,
as
I
said,
it's
totally
up
to
you
how
you
structure
your
pipeline.
But
this
is
why
we
are
removing
now
this.
B
B
If
you're
binge
watching
this
course
make
sure
to
take
a
break
after
a
few
lessons.
There
is
a
lot
to
take
in,
but
you
need
to
take
care
of
your
body
as
well,
so
get
up
from
time
to
time,
drink
some
water
eat
or
go
outside
and
relax
your
mind
and
trust
me.
Taking
a
break
is
so
much
more
productive
than
staying
all
day
in
front
of
your
computer.
If
your
body
does
not
feel
well,
this
impacts
your
productivity
and
energy
levels.
B
In
this
unit,
we'll
learn
about
deployments
and
we'll
take
our
website
project
and
deploy
it
in
the
aws
cloud
along
the
way,
we'll
learn
about
other
devops
practices
such
as
continuous
delivery
and
continuous
deployment.
By
the
end
of
this
section,
we'll
have
a
complete
ci
cd
pipeline
that
will
take
our
website,
build
it
test
it
and
let
it
float
in
the
cloud.
Just
a
quick
reminder
in
case
you
get
stuck
or
something
does
not
work
check.
The
video
description
for
the
course
notes,
which
include
troubleshooting
tips.
This
sounds
exciting.
Let's
begin.
B
Amazon,
web
services
or
simply
aws,
is
a
cloud
platform
provider
offering
over
200
products
and
services
available
in
data
centers
all
over
the
world.
Aws
offers
a
pay-as-you-go
model
for
renting
cloud
infrastructure,
mostly
for
computation
or
data
storage.
So,
instead
of
buying
physical
hardware
and
managing
it
in
a
data
center,
you
can
use
a
cloud
provider
like
aws.
B
Such
services
include
virtual
servers,
managed
databases,
file,
storage,
content,
delivery
and
many
others
aws
started
in
the
early
2000s
and
its
adoption
continued
to
increase
over
time.
Maybe
you
have
heard
the
story
when
the
new
york
times
wanted
to
make
over
1
million
old
articles
available
to
the
public.
A
software
architect
at
new
york
times
has
converted
the
original
article
scans
into
pdfs
in
less
than
24
hours
at
a
fraction
of
the
cost,
a
more
traditional
approach
would
have
required,
and
this
was
back
in
2007
today.
B
B
If
you
don't
already
have
an
aws
account,
don't
worry
it's
quite
easy
to
create
one
and
your
personal
details
and
click
on
continue
since
we're
using
aws
for
learning
and
experimenting
with
it.
I
recommend
choosing
a
personal
account:
aws
is
a
paid
service,
and
even
though,
in
the
beginning,
there
is
a
free
tier
that
has
some
generous
limits
and
is
ideal
for
learning
and
experimenting.
B
B
B
B
B
You
can
use
whichever
region
you
like
just
remember
the
one
you
have
selected
as
this
will
be
relevant
later
on.
Typically,
the
data
centers
in
the
u.s
have
a
lower
cost
than
others
that
are
spread
around
the
globe
and
right
here
you
have
a
list
of
all
services
available.
You
can
also
search
for
services
in
this
search
bar.
B
B
B
B
B
First
of
all,
we
have
to
give
our
bucket
a
name,
and
the
name
of
the
bucket
needs
to
be
unique.
So
I'm
going
to
give
this
bucket
a
unique
name
so
that
I
don't
run
into
conflicts
with
anyone
else
who
may
have
created
the
bucket
with
the
same
name.
So
I'm
gonna
just
give
here
my
name
and
a
dash,
and
after
that
I
will
give
here
a
date.
B
Additionally,
you'll
have
here
the
aws
region
and
in
my
case
I'm
gonna
keep
it
exactly
as
it
is,
and
there
are
also
a
bunch
of
settings
that
we'll
not
look
into
right
now
so
right
here.
At
the
end,
I'm
going
to
click
here
on
create
bucket
all
right,
so
the
bucket
has
been
successfully
created
and
we
can
go
inside
the
bucket
and
to
see
if
there's
anything
in
there.
But
at
this
point
there
are
absolutely
no
files.
B
Of
course
we
could
go
ahead
and
manually
upload
files
or
download
files,
or
things
like
that
so
through
the
web
interface,
it's
possible
to
add
files
and
folders.
But
this
is
not
what
we
are
trying
to
accomplish
with
devops.
We
want
to
automate
this
process
so
for
that
reason,
I'm
going
to
leave
it
as
it
is
and
in
the
upcoming
lectures,
we're
going
to
find
a
way
on
how
to
interact
with
aws
s3
from
gitlab.
B
B
We
need
to
find
the
docker
image
and
the
best
place
to
search
for
docker
images
is
in
docker
hub,
so
here
inside
docker
hub
I'm
going
to
go
ahead
and
write
aws
cli
and
I'm
going
to
find
here,
we'll
see
it.
It's
under
verified
content,
if
possible,
we
always
try
to
use
verified
official
docker
images.
I'm
gonna
take
this
one.
B
This
image
has
a
thing
which
is
called
an
entry
point
essentially
when
we're
starting
the
image,
there's
already
a
program,
that's
running
with
that
image,
and
this
is
something
that
conflicts
a
bit
with
the
way
we're
using
images
in
gitlab.
So
we
need
to
override
that
entry
point.
So
for
that
reason,
I'm
going
to
move
this
to
a
new
line,
I'm
going
to
write
here,
another
property
which
is
called
name.
So
this
is
under
image,
and
this
is
not
a
list
and
below
it.
B
I'm
gonna
write
entry
point,
and
here
I'm
gonna
overwrite
the
entry
point
with
this
square
brackets
and
this
quotes
here
so
then
comes
the
script
part
and
in
the
script
part
we
are
essentially
writing.
Well,
let's
test.
If
the
tool
is
working,
so
typically,
almost
every
tool
will
have
the
possibility
of
printing
out
the
version,
so
the
name
of
the
tool
is
aws
and
then
the
version
will
be
dash
dash
version.
B
B
Typically,
anything
that
starts
with
two
should
be
good
enough.
So
let's
commit
these
changes
in
a
branch
and
see
how
the
pipeline
looks
like
now
right
now,
I'm
getting
an
error,
and
if
I'm
looking
inside
the
pipeline
to
see
what's
going
on,
there
are
some
errors,
because
the
stage
I
have
chosen
in
this
case
the
deploy
stage
doesn't
exist
so
the
pipeline
hasn't
been
executed.
So
we
still
need
to
make
some
changes
to
it.
B
So
now
the
entire
pipeline
has
been
successful.
Let's
take
a
look
at
the
deploy
job,
see
exactly
what
has
happened
there
and
we
take
a
look
at
the
logs
here.
We
have
used
this
aws
cli
image
and,
of
course,
we
have
printed
here
the
version
so
we'll
see
exactly
which
version
we're
using
I've
used
the
tag.
B
So
with
that
tag,
I'm
gonna
always
get
this
version,
but
sometimes,
if
you
don't
wanna
specify
a
tag,
it's
still
a
good
practice
to
lock
the
version
in
the
logs,
just
in
case
you
know
from
one
day
to
the
next
one
or
like
one
month
later
or
something
like
that.
Your
pipeline
doesn't
work
anymore.
At
least
you
can
compare
previous
logs
with
existing
ones
and
see
if
there's
any
differences
in
the
version
that
you
have
used
for
the
various
tools.
B
B
I
always
like
to
make
things
as
simple
as
possible
and
whenever
I'm
working
with
a
new
tool,
I
want
to
make
sure
that
I
don't
make
any
mistakes
or
that
I
can
easily
understand
what's
going
on
so
for
that
reason,
I'm
gonna
leave
aside
this
complexity
with
building
and
testing
the
website.
We're
gonna
only
focus
on
deploy
2s3,
so
we
have
here
the
aws
version
and
then
what
you're
going
to
use
here
is
aws.
This
is
the
name
of
the
cli
tool.
B
Then
I'm
going
to
specify
the
service
name,
which
is
s3
and
then
on
the
service
name.
We
are
gonna
use
copy
right,
so
we
are
copying
something
to
s3
now.
What
are
we
copying?
Well,
for
example,
let's
create
a
new
file
from
scratch,
just
to
make
sure
that
everything
is
working
properly.
So
how
do
we
create
a
file?
I'm
gonna
use
echo.
I'm
gonna
write
here,
hello,
s3,
I'm
gonna
put
it
inside.
B
Let's
call
this
test.txt
right,
so
we
are
putting
hello
s3
inside
this
file,
so
we
now
we
have
this
file,
so
we
know
exactly
what
we
are
uploading
and
the
question
is:
where
are
we
uploading
this,
where
we're
uploading
this
to
the
bucket
that
we
have
created
now?
For
that
reason
we
need
to
have
the
bucket
name
and
if
you
still
have
your
bucket
open
you'll
be
able
to
see
here
the
destination.
Now
this
is
my
destination.
You
will
have
a
different
bucket
name.
B
B
So
we
are
taking
this
file
that
we
have
created
inside
gitlab.
We
are
uploading
it
to
this
bucket
and
the
name
of
the
file
will
be
the
same
in
this
case.
Let's
give
it
a
try
and
see
how
it
works,
because
we
have
disabled
the
build
and
the
test
stages.
Essentially,
we
now
only
have
the
deploy
to
s3,
so
this
makes
the
entire
pipeline
execution
much
faster,
but
let's
take
a
look
why
this
failed,
so
what
we
did
we're
still
printing
the
aws
version
and
then
the
last
command
that
we
have
executed.
B
B
The
thing
is:
how
is
aws
cli
supposed
to
know
who
we
are?
I
mean
if
this
would
work
as
it
is
right
now,
we
should
be
able
to
upload
files
to
any
bucket
that
belong
to
other
people
or
to
delete
objects
from
buckets
that
belong
to
other
people.
So
we
need
to
tell
aws
cli
who
we
are,
and
this
is
what
we're
going
to
do
in
the
upcoming
lectures
and
in
order
to
have
the
entire
context.
In
terms
of
this,
we
have
to
go
through
a
few
stages
of
preparation.
B
Existence
right
now
there's
something
about
this
pipeline
that
I
don't
like,
and
that
is
because
we
have
something
inside
here
that
may
change
later
on,
and
I
would
really
like
to
make
this
configurable
and
not
to
have
this
information
inside
here.
At
the
beginning
of
the
course
we
looked
at
the
defining
variables
and
I've
shown
you
how
you
can
define
some
variables
within
the
pipeline.
B
There's
also
another
place
where
you
can
define
variables
and
for
that
I'm
going
to
copy
this
value
and
I'm
going
to
go
inside
the
settings
so
from
your
project.
You
can
go
to
settings
here
on
the
right
hand,
side
and
what
you're
gonna
do
here
is
select
ci,
cd
and
right
here
in
the
middle.
You
will
see
variables
I'm
going
to
expand
this
so
that
we
are
able
to
add
variables
now.
B
Typically,
here
we
tend
to
store
passwords
or
secret
keys,
but
I'm
going
to
use
this
bucket
name
as
an
example
for
some
important
features
you
need
to
know
about.
So,
let's
go
ahead
here
and
click
on
add
variable
and
I'm
going
to
name
my
variable
aws
underscore
s3
underscore
bucket,
and
the
value
will
be
exactly
what
I've
copied
from
the
pipeline.
B
Now
there
are
some
additional
settings
here.
I
want
you
to
pay
attention
to.
There
are
two
flags:
one
of
them
is
typically
enabled
by
default,
and
that
is
protect
variable.
This
flag
alone
is
the
single
cause
for
a
lot
of
confusion
and
a
lot
of
wasted
time
for
people
who
are
just
getting
started
with
gitlab.
I
just
wanted
to
point
this
out.
B
B
B
Now
you
typically
want
to
keep
the
protected
variables
for
the
main
master
branch
which
deploys
to
production.
In
this
way,
you
ensure
that
nobody
has
the
credentials
to
accidentally
deploy
to
production
from
a
different
branch.
So
this
is
a
security
measure.
Now
we
are
using
branches
and
we
are
using
these
services
directly.
So
at
least
at
this
stage
we're
going
to
go
ahead
and
disable
this
flag,
because
we
don't
want
to
protect
this
variable
because
it
will
not
be
available
in
our
pipeline
execution.
B
As
we
are
running
this
on
a
branch,
the
second
flag
is
disabled
by
default.
This
is
something
that
will
be
masked
in
order
to
mask
a
variable.
This
is
particularly
useful
for
password,
so,
for
example,
if
you
accidentally
try
to
print
one
of
these
variables
in
your
code,
it
will
not
appear
there.
It
will
just
appear
like
a
must
masked
out
with,
like
simply
stars,
it's
okay
to
have,
for
example,
usernames
or
other
things
like
this
packet
name.
B
We
don't
need
to
mask
this
because
it's
not
really
a
secret,
but
if
we
had
here
a
password
for
a
password,
it
would
make
sense
to
mask
this.
So
for
this
variable
I'm
gonna
disable
the
protect
variable
flag
and
I'm
gonna
disable
the
mask
variable
flag.
Many
people
think
that
if
you
don't
have
the
protect
variable
flag,
the
variable
is
somehow
public
or
unprotected.
That's
not
the
case.
It's
simply
available
for
all
the
branches
inside
a
project,
and
at
this
stage
that's
totally
fine.
B
B
You
will
be
able
to
see
it
here
being
added
and,
of
course,
if
you
need
to
make
changes
to
it,
you
can
go
ahead
and
make
changes
from
here
going
back
to
the
pipeline.
Instead
of
having
this
value,
I'm
going
to
start
here
with
the
dollar
sign
aws
s3
bucket,
so
the
name
has
to
be
exactly
as
you
have
defined
it
and
don't
forget
to
put
the
dollar
sign
in
advance,
because
this
is
what
makes
this
a
variable.
B
We
can
run
this
pipeline
again
and
see
how
it
looks
like
see
if
we
notice
any
changes
now,
if
we're
looking
at
the
logs,
we
should
be
able
to
notice
something
interesting.
So
what
is
interesting
about
this
is
the
following:
we
have
the
same
command,
but
now
inside
the
command.
You
notice
this
variable.
So
when
we're
writing
the
command
the
command-
that's
being
locked
here,
this
doesn't
change.
B
It
will
still
show
you
with
the
variable,
so
it
may
seem
that
it's
not
resolved,
but
actually,
if
you're
looking
here
at
the
error
that
we're
getting,
you
will
see
here
that
the
variable
has
been
resolved.
An
indication
that
the
variable
has
not
been
resolved
is,
for
example,
not
seeing
this
text
at
all.
So
I
invite
you
to
play
around
with
the
protected
flag
and
to
run
the
pipeline
again
to
see
what's
happening,
and
you
should
be
able
to
see
here
that
after
s3
you'll
got,
you
will
get
three
forward
slashes.
B
So,
let's
go
back
to
what
we
wanted
to
achieve
to
actually
upload
this
file
and
we're
still
getting
this
error
unable
to
locate
credentials.
So
what
should
we
do?
Should
we
put
our
aws,
email
and
password
somewhere
in
these
variables
so
that
aws
can
locate
them
well,
you're,
getting
pretty
warm
with
that?
Yes,
essentially,
we
have
to
provide
some
credentials,
but
those
credentials
won't
be
our
regular
email
and
password,
because
that
will
be
highly
insecure.
Whenever
we're
using
a
service,
we
try
to
give
limited
access
to
that.
B
So
in
order
to
give
this
limited
access
to
services,
in
this
case,
we
only
need
s3.
There
is
also
a
service
that
manages
that.
So,
if
we
go
back
here
to
aws
and
search
for
services,
the
service
that
we
are
interested
in
is
iam
or
yum,
and
this
is
essentially
an
identity
manager
service
that
aws
offers.
B
Let's
go
inside
it
and
see
what
we
can
do
so,
first
of
all,
if
you
didn't
activate
multi-factor
authentication
you're
going
to
get
this
warning,
and
I
definitely
recommend
that
you
do
that.
This
is
just
a
testing
account
for
me,
which
will
be
very
short-lived.
So
for
that
reason
I
didn't
do
that
at
this
point
now
here
from
this
service,
we
can
create
new
users.
B
So
we
have
to
give
here
this
user
a
username
can
be
any
user,
typically
I'm
using
something
so
that
I
know
why
I
created
it.
So
I'm
going
to
call
this
gitlab.
I
know
exactly
that
this
user
is
intended
for
gitlab
and
we
have
to
select
an
access
type
now.
What
we
are
interested
in
is
also
called
programmatic
access,
so
we're
going
to
click
this,
and
you
will
see
here
that
this
enables
an
access,
key
id
and
secret
for
aws,
api,
cli
and
so
on,
so
we're
interested
in
having
this
for
aws
cli.
B
So
this
is
why
we
are
creating
this
user
and
we
are
enabling
this
programmatic
access.
We
don't
need
a
password.
We
don't
need
this
user
to
have
access
to
the
management
console
like
we
do
so.
For
that
reason,
that's
sufficient.
Let's
go
to
the
next
part,
which
is
the
permissions,
so
essentially
the
permissions
tell
what
the
user
is
allowed
to
do
and
permissions
in
aws.
B
I'm
going
to
say
it's
not
an
easy
topic,
so
I'm
going
to
go
the
most
straightforward
way,
I'm
going
to
attach
an
existing
policy.
So
I'm
going
to
go
here
to
attach
existing
policies
in
this
search
bar
I'm
going
to
select
s3,
I'm
going
to
search
for
s3
you're
going
to
get
some
predefined
policies.
So
policy
is
essentially
like
a
set
of
rules
that
we
can
apply
to
a
user
and
the
set
of
rules
that
we're
going
to
use
here
is
amazon,
s3,
full
access.
B
So
essentially
we're
gonna
give
this
user
access
to
everything
that
is
aws
s3,
so
we
should
be
able
to
create
new
buckets,
should
be
able
to
delete
files,
and
so
on
so
a
bit
more
than
what
we
actually
need
for
this
use
case,
but
just
to
simplify
things.
I'm
gonna
give
this
full
access
to
the
user.
But
of
course
it's
the
topic
on
its
own.
B
B
B
B
I'm
going
to
start
here!
Writing
aws
and
you
will
see
there
already
some
predefined
things
that
pop
up,
so
one
of
them
is
aws
access.
Key
id.
This
has
to
be
written
exactly.
As
you
see
it
here,
there's
something
that's
different
about
this
away.
Cli
will
not
be
able
to
pick
up
this
variable.
It
will
look
exactly
for
this
variable
name
and
will
automatically
pick
it
up
without
us
doing
anything
else,
so
it
has
to
be
exactly
as
it
is,
I'm
going
to
paste
here,
the
value.
B
B
Of
course,
I'm
gonna
delete
this
right
after
recording,
but
I'm
showing
you
just
to
know
exactly
how
it
looks
like
it's
also
important
that
you
don't
add
any
spaces
or
anything
like
that.
So
I'm
going
to
copy
this
secret
access
key
and
go
here,
add
a
variable
and
I'm
going
to
start
typing
aws
secret
access,
key
and
I'll
paste.
The
value
here,
I'm
gonna
disable
the
protect
variable,
flag
and
click
on
add
variable.
B
Finally,
there's
still
another
thing
that
we
need
to
configure,
and
that
is
our
region.
So
again,
I'm
gonna
add
here
variable
start
typing
aws
and
we
have
here
the
default
region.
So
when
we're
setting
this
variable
all
services
that
we
use
will
be
in
this
region
and
we
don't
need
to
specify
the
region
all
the
time.
Aws
know
exactly
where
this
bucket
or
any
other
service
is
located,
and
we
cannot
simply
write
here
anything
we
have
to
write
exactly
as
aws
uses
it
internally.
So
what
do
I
mean
by
that?
B
What
we're
actually
interested
in
is
this
code,
so
I'm
going
to
copy
this
information
and
paste
it
here.
So
this
will
be
the
default
region
and
again,
I'm
not
going
to
protect
this
variable,
and
I'm
going
to
add
it
here.
What
I
forgot
to
do
in
terms
of
the
secret
access
key
is,
I
haven't
masked
it,
so
it
would
be
idea
to
go
back
to
it.
B
Click
on
this
edit-
and
you
will
see
here
this
flag,
because
this
is
essentially
a
password,
and
I
click
here
this
flag
to
mask
it
and
update
it,
and
then
you
also
have
here
an
overview
like
which
one
of
them
is
protected,
which
one
of
them
is
masked
and,
of
course,
if
you
need
to
inspect
some
of
these
variables,
you
can
go
back
and
click
on
them
and
you
will
be
able
to
see
the
value
but
list
on
this
overview
here
they
are
hidden.
There's
also
this
possibility
of
copying
the
value
without
revealing.
B
This
can
be
useful
as
well
or
you
can.
Click
here
on
reveal
values
and
they
will
be
displayed
all
right,
so
it
seems
that
we
have
everything
in
place
now,
at
least
we
have
these
credentials
and
because
we
named
them
the
way
we
named
them,
aws
cli
will
automatically
pick
them
up.
So
there's
actually
nothing
that
we
need
to
change
in
our
pipeline.
So
for
that
reason
we
can
simply
go
ahead
and
rerun
the
same
pipeline.
B
This
will
start
the
exact
same
job
once
again,
all
right,
so
this
already
looks
so
much
better.
The
job
has
succeeded.
We
don't
see
here
any
errors.
Aws
cli
is
telling
us
which
files
have
been
uploaded,
so
we
could
jump
into
s3
and
take
a
look
inside
our
bucket
to
see
if
we
have
any
files
here,
you
will
be
able
to
see
here
our
test.txt
file
right
inside
here
say
when
it
was
modified
and
so
on.
B
All
right,
so
we
have
made
some
progress
and
we
have
managed
to
finally
upload
this
file,
but
if
you
remember,
we
have
an
entire
website
with
a
lot
of
files,
so
you
know
going
file
by
file
and
uploading.
That
is
not
really
the
way
to
go,
so
I
can
make
sure
that
whatever
we
have
inside
the
build
folder
it's
going
to
be
synced
to
our
packet.
B
Now,
if
you
remember
in
the
beginning,
I
mentioned
the
documentation
the
reference
for
the
aws
cli,
essentially
for
any
service
there
is
here
documentation.
There
is
here
an
additional
command,
so
we
have
used
aws
s3
as
the
name
of
the
service.
So
in
this
list
of
services
here
you
will
find
s3
somewhere.
B
I'm
going
to
be
honest
with
you
in
the
beginning,
this
documentation
will
look
very
scary,
but
if
you
take
a
bit
of
time,
if
you
have
a
bit
of
patience
and
you
go
through
the
documentation,
this
is
the
way
to
really
master
the
cli
commands
that
you
will
be
using,
and
this
doesn't
only
apply
to
aws
cli,
applied
to
any
tools
out
there.
So
reading
the
documentation.
Looking
at
all
the
parameters,
everything
that
you
can
do
with
this
is
really
super
helpful.
B
So
for
s3
you
will
see
here
a
lot
of
documentation,
but
also
at
the
end.
You
will
see
here
a
list
of
available
commands,
so
we
have
used
cp
for
copy,
so
we've
copied
this
file
and
it's
also
definitely
possible
to
copy
an
entire
folder,
but
I
wanted
to
show
you
also
different
command,
which
is
sync
now
typically
syncing.
Something
means
that
whatever
we
have
on
one
side,
we
have,
on
the
other
side
as
well,
for
example,
to
ensure
this
with
copy.
B
B
So
for
that
reason
using
something
like
sync,
which
ensures
that
all
the
files
are
in
sync
does
make
a
lot
of
sense.
So
we
can
go
here
on
sync
and
we'll
tell
right
from
the
description
it
syncs
directories
and
essentially
it
ensures
that
whatever
we
have
there
on
one
side
is
also
available
on
the
other
side.
So
how
do
we
use
this?
Let
me
demystify
this
and
take
a
look
at
our
existing
pipeline
that
we
have
here.
So,
first
of
all,
we're
going
to
give
up
on
this
test
file
that
we
have
uploaded
here.
B
This
was
just
for
testing
purposes
and
to
make
sure
that
we
have
everything
set
up
correctly,
so
we're
gonna
use
here,
aws
s3,
so
the
command
will
be
sync.
So
what
are
we
thinking?
We're
syncing
the
build
folder,
so
instead
of
that
file,
we're
going
to
have
an
entire
folder
and
the
question
is:
where
are
we
syncing
this
we're
syncing
this
to
the
bucket?
B
It
will
essentially
ensure
that
if
we
delete
some
files
during
our
build
process
which
existed
previously
in
previous
builds,
that
are
also
deleted
during
the
sync.
So
if
I
had
a
file
in
the
build
folder,
I
synced
it
in
the
last
build.
Then
I
later
removed
that
file.
I
want
that
one
removed
from
s3
as
well,
so
I'm
gonna,
add
here
delete,
so
this
essentially
should
be
enough
to
upload
our
build
folder
now
in
order
to
get
this
to
run.
B
And
the
pipeline
is
now
successful
and
we're
most
interested
in
this
last
job
that
we
have
executed
and
now,
if
we're
looking
at
the
logs,
we'll
see
exactly
which
files
we
are
uploading,
so
we'll
see
here
uploading
this
uploading
that
so
these
are
all
the
files
that
we
have
inside
the
build
folder,
what's
also
important
to
notice.
Is
you
notice
here
this
delete,
so
this
file
is
then
deleted
because
it
no
longer
exists
in
the
build
folder.
B
It
actually
never
existed
in
the
build
folder,
but
sync
detects
that
this
file
doesn't
exist
there
and
says:
okay.
If
it
doesn't
exist
in
the
build
folder,
it
doesn't
make
any
sense
to
stay
on
s3
and
goes
ahead
and
removes
it.
So,
let's
take
a
look
at
the
s3
service,
I'm
going
to
refresh
this
page
and
take
a
look
to
see
how
it
looks
like
so
now
we
are
able
to
see
all
the
files
that
we
are
actually
interested
in.
B
B
Now,
in
order
to
make
this
bucket
publicly
accessible,
we
need
to
change
a
few
things
and
we're
going
to
start
here
with
properties
and
actually
what
we
are
definitely
interested
in
is
enabling
static
web
hosting.
So
again,
I'm
here
in
my
bucket
inside
properties
right
at
the
end,
there's
static
website
hosting
I'm
gonna
go
ahead
here.
Click
on
edit
and
we're
going
to
enable
static
website
hosting
and
the
hosting
type
will
be
host
a
static
website,
and
there
are
also
some
settings
here
that
we
are
gonna
input.
B
Websites
typically
have
an
index
page,
which
is
a
start
page
and
also
they
have
an
error
page
for
this
application
that
we
have
the
index
page
and
the
error
page
are
the
same,
and
this
is
the
index.html
file.
If
you
look
inside
the
bucket,
you
should
see
the
index.html
file,
so
this
is
exactly
what
we're
going
to
have
here
for
the
index
and
the
error.
B
We
could
also
get
the
domain
and
point
this
to
this
address,
but
for
what
we're
trying
to
do
right
now,
this
is
board
enough,
so
we
can
go
ahead
and
click
on
it
and
in
the
beginning,
we're
gonna
get
this
error
and
there's
still
a
few
things.
We
need
to
configure,
don't
worry
about.
It
just
wanted
to
point
out
the
address
and
where
you
can
view
it.
B
So,
let's
see
which
other
settings
do
we
need
to
make.
I'm
gonna
go
here
to
permissions
and
you
will
see
here.
The
first
thing
that
appears
is
access
bucket
and
objects,
not
public
whatever
we
have
here
in
the
bucket
is
not
public.
So
this
is
why,
even
if
we
have
enabled
static
website
hosting,
we
still
cannot
access
this
information.
B
So
let's
take
a
look
at
how
we
can
enable
public
access,
I'm
going
to
click
here
on
edit
and
I'm
going
to
disable
this
block
all
public
access
and
save
the
changes
and
again
because
this
is
like
a
major
thing.
Abs
really
wants
to
make
sure
that
we
know
what
we're
doing
so.
I'm
going
to
enter
here
confirm
I've
been
going
to
the
website.
We
can
try
a
refresh
and
it
will
still
display
the
same
error
page
here
so
there's
something
that's
still
not
working
properly.
B
What
we
need
to
do
in
addition
to
what
we
did
here
with
in
regards
to
the
public
access,
is
a
bucket
policy.
Now,
essentially,
we
need
a
policy
for
the
objects
that
are
inside
the
bucket.
I
want
to
get
too
much
into
the
details,
but
essentially
we
need
to
write
this
policy,
so
we
can
go
ahead
here
and
click
on
edit.
B
This
is
like
policy
generator.
Now
what
you
see
here
is
json,
and
this
is
the
format
in
which
this
policy
will
be
written
here.
There
are
a
few
things
that
we
need
to
change
about
this
policy,
so
essentially
we
can
go
ahead
here
and
add
an
action.
So,
let's
search,
for
example,
for
s3,
I'm
going
to
select
hit
here
and
the
permission
that
we
are
looking
for
is
essentially
get
object.
B
I'm
going
to
click
on
this
get
object,
but
additionally,
there
are
also
a
few
other
things
that
we
need
to
change
here,
just
to
make
sure
that
everything
is
working
properly
and
this
changes
will
be
made
in
text.
But
you
also
find
the
template
in
the
course
notes.
Just
in
case
something
doesn't
go
well,
you
will
have
the
possibility
of
using
that.
So
essentially,
I'm
gonna
give
here
a
name
and
I'm
gonna
call
this
public
read.
This
is
just
a
name
to
identify
this
policy
and
the
principle
here.
B
We
need
to
be
put
between
double
quotes
and
I'm
going
to
put
here
this
star
and
then
the
action
will
be
get
s3
object,
that's
allowed.
The
effect
is
allow
and
resource.
We
also
need
to
specify
the
resource
and
the
resource
is
our
bucket.
I'm
going
to
copy
this
name,
it's
essentially
the
address
of
the
bucket
and
I'm
gonna
put
this
here
also
in
quotes,
and
I'm
gonna
add
here
very
important,
a
forward
slash
and
this
star,
which
essentially
means
that
everything
that
is
in
this
bucket
can
be
retrieved
get
object.
B
It
is
allowed,
so
this
is
essentially
our
policy
for
public
reading
all
right.
I
agree.
It's
not
so
easy
for
beginners,
but
let's
hope
we
haven't
made
any
errors
here
and
that
it
will
work
as
expected.
I'm
gonna
click
here
on
save
changes
to
apply
this
policy.
You
will
see
here
warnings
all
over
the
place.
You
will
see
under
the
bucket
in
red,
publicly
accessible
access
public,
so
aws
is
really
trying
to
tell
you
hey
watch
out.
B
If
this
is
not
what
you
intended-
or
this
is
not
what
you
want,
this
bucket
is
publicly
accessible,
so
really
really
make
sure
that
you
know
what
you're
doing,
but
for
us
it's
fine.
This
is
what
we
wanted
to
have,
and
now
by
refreshing
this
page
we're
getting
the
website
that
we
have
created,
and
now
congratulations
really.
This
is
absolutely
amazing.
We
created
pipeline
that
now
takes
every
commit
that
we
make
and
deploys
it
in
the
aws
cloud.
B
We
take
it
through
all
the
stages,
but
we
only
have
to
make
the
change
and
the
entire
process
is
automated.
So
if
you
manage
to
follow
along
up
to
this
point,
wow,
I'm
sure
that
you
have
learned
so
much
and
trust
me
we're
just
getting
started.
There's
still
so
much
more
to
learn
and
I'm
super
excited
about
the
upcoming
steps.
B
Now,
if
you
think
about
it,
this
really
doesn't
make
a
lot
of
sense
and
what
doesn't
make
sense
is
to
deploy
to
s3
from
a
merge
request
or
from
a
branch.
Now,
if
we
think,
as
s3
being
our
let's
say,
our
production
server
or
production
environment,
then
it
means
that
anyone
who
opens
a
merge
request
and
tries
out
some
small
changes
if
the
build
and
the
test
pass,
this
will
automatically
get
deployed
to
production,
and
actually
this
is
not
what
we
want.
B
B
So
in
this
case,
you
want
to
check
if
the
branch
we're
currently
at
so
we
have
here
something
I
don't
know
where
we're
at
equals,
so
we're
gonna
make
two
equal
sign
the
main
branch
right.
So
if
we
are
on
the
main
branch,
only
then
run
this
right
now
we
don't
want
to
put
here
something
hard-coded,
so
we
cannot
know
in
advance
like
which
is
this
branch
name
where
we
are
currently
evaluating
this
condition.
So
in
my
case
I
mean
feature
deployed
to
s3
or
something
like
that.
B
So
it
doesn't
make
sense
to
add
that
there
to
to
check
this,
it
needs
to
be
dynamic.
So
in
order
to
have
something
dynamic,
we
need
to
use
some
variables
now.
Luckily,
gitlab
comes
with
some
predefined
variables
and
one
of
these
variables
is
ci
commit
ref
name.
So
I'm
going
to
search
here
for
ref
name,
you
will
see
here
so
see.
I
commit
ref
name.
This
will
give
us
dynamically
the
branch
or
tag
name
for
which
the
project
is
built.
B
So
we
can
use
this
as
a
variable
and
I'm
going
to
write
here.
Dollar
sign
this
one,
so
this
will
be
evaluated
to
our
current
branch
now
with
any
of
these
variables,
if
you're
not
sure
what
they
do,
how
they
look
like
simply
use
here
echo
and
just
keep
something
like
this
for
debugging
purposes
in
your
pipeline
until
you
get
familiar
with
the
values
that
you're
having
I'm
going
to
remove
it
because
I
don't
need
it,
but
for
you
definitely
recommend
use
echo
to
inspect
the
different
values
that
you're
using.
B
If
you
were
on
a
different
branch,
this
would
be
something
else.
So
if
this
equals
main,
then
we're
gonna
essentially
run
this
job.
Otherwise
it
will
be
excluded
from
the
pipeline
still
having
something
hard
coded
here
is
also
not
something
that
we
like
doing.
Yes,
we
could
keep
here
main,
but
there
are
also
variables
that
can
handle
this.
So
another
variable
that
we
can
use
is
default
branch.
B
It
should
be
ci
default
branch,
and
this
variable
will
give
us
dynamically,
give
us
the
name
of
the
default
branch.
So,
if
later
on,
for
whatever
reason
we
decide
to
switch
from
master
to
main
or
from
main
to
something
else,
then
we
don't
need
to
worry
about
these
pipelines,
because
the
default
branch
will
automatically
get
updated
in
this
variable
and
then
we
can
use
it
directly
here.
So
again,
I've
added
here,
another
variable,
which
is
the
ci
default
branch.
B
B
I
can
also
inspect
the
merge
request
and
take
a
look
at
what
is
going
on
here
and
also
I
see
that
this
pipeline
has
been
updated.
It
contains
only
build
and
test.
So
at
this
point
I
would
say:
okay,
I'm
pretty
confident
that
this
functionality
is
working
properly.
Gonna
click
here
on
merge
and
also
let
the
main
pipeline
run.
B
B
So
now
the
main
pipeline
is
also
working.
We
have
deployed
again
to
s3,
but
how
do
we
know
if
our
website
is
still
working
again?
We
could
go
to
the
address
again
hit
the
refresh
button
check
again
if
it's
working,
but
again,
that's
not
really
the
point
of
automation.
We
want
to
make
sure
that
the
entire
process
is
automated.
B
B
So
probably
the
next
stage
should
be:
let's
call
it
post
deployment,
so
this
will
be
after
the
deployment
and
then
it's
probably
time
to
also
add
another
job,
I'm
going
to
call
this
production
tests
and
I
want
to
make
sure
that
the
stage
is
the
right
one,
let's
post
deploy
and
what
I'm
proposing
is
to
simply
run
a
curl
command.
So
that's
pretty
similar
to
what
we
did
here
so
simply
going
to
go
ahead
and
copy
this.
Of
course,
this
has
to
be
under
the
script
block
and
there
are
a
few
things
that
we
need.
B
B
So
the
address
to
this
image
is
this
one.
So
this
is
what
we
need
to
do
without
docker
pull.
So
we
have
here
image
and
paste:
remove
this
docker
pull
that's
the
name
of
the
image
and
because
curl
is
such
a
generic
tool,
don't
need
to
specify
a
specific
version.
What
we're
doing
is
pretty
basic
and
I'm
pretty
sure
it's
not
going
to
change
very
soon.
B
B
B
That's
also
totally
fine
and
also
way
on
how
to
do
things.
I'm
gonna
define
here
variables
block
and
let's
call
this
variable
app
base,
url
of
course,
you're
free
to
name
it
as
you
wish
column,
and
then
I'm
gonna
paste
here
the
address
to
it.
So
this
is
now
the
full
address.
So
it's
all
I
need
is
this.
This
is
the
variable
name.
B
This
should
be
enough,
at
least
to
test
that
what
we
have
on
s3
is
still
reachable
that
at
least
this
text
is
still
available
there.
Additionally,
we
need
to
make
another
configuration,
because
otherwise,
as
it
is
right
now,
this
will
also
run
inside
the
branch.
So
I'm
going
to
copy
this
rule
that
we
have
here
on
deploy
to
s3
same
rule
is
valid
here.
B
We
want
to
run
these
jobs
only
in
the
main
pipeline,
so
I'm
going
to
go
ahead,
commit
these
changes
and
merge
them
into
the
main
branch,
and
I'm
a
pretty
confident
that
this
pipeline
will
work
without
any
issues.
So
there's
no
additional
review
that
I
need
at
this
point,
I'm
going
to
simply
merge
when
the
pipeline
succeeds
and
I'm
going
to
grab
a
coffee
until
this
is
merged.
B
B
We
have
to
build
and
the
test,
that's
it
after
we
have
merged
this,
then
the
pipeline
for
the
main
branch
has
started,
and
this
pipeline
then
has
four
stages:
build
test,
deploy
and
post
deploy.
So
essentially
the
stage
that
we
have
added
right
now
and
this
contains
the
production
tests.
Let's
take
a
look
at
them
to
see
what
has
happened
here
so
we
have
executed
this
command.
B
B
So
let's
take
a
minute
and
take
a
look
at
what
we
did
so
far,
so
this
is
our
main
pipeline
right.
This
is
the
pipeline
that
now
deploys
to
aws
s3
and
we
have
the
build
and
the
test.
This
is
what
we
essentially
call
continuous
integration
right.
This
happens
also
in
the
merge
request,
but
also
here
we
are
rechecking
that
our
build
is
still
working
and
let
those
tests
are
executed
here.
The
second
part:
this
is
the
cd
part
in
ci
cd,
now
cd
can
mean
continuous
deployment
or
continuous
delivery.
B
Now.
This
is
a
very
simplistic
view
on
cicd,
now,
quite
often,
pipelines
also
have
a
staging
environment
or
a
pre-production
environment.
Essentially,
if
we
make
changes
to
our
deployment
to
s3
and
something
doesn't
work
anymore-
we're
not
really
testing
this
before,
and
the
main
branch
may
still
produce
some
errors.
And
again
we
come
back
to
the
same
problems
we
had
when
we
did
ci
when
nobody
else
can
work
on
a
project
anymore.
B
So
for
that
reason
it
kind
of
makes
sense
also
to
add
another
environment,
at
least
if
the
environment,
if
there
are
some
issues
with
the
environment
before
production
and
the
main
pipeline
breaks,
at
least
we
haven't
affected
the
production
environment.
So
it's
still
good
right
now,
we're
just
deploying
anything
and
we're
testing
afterwards.
B
What
is
a
staging
environment,
so
a
staging
environment
is
essentially
a
non-production,
usually
non-public
environment
that
is
actually
very
close
to
the
actual
production
environment
right.
So
we
want
to
keep
things
as
similar
to
the
production
environment
as
possible.
Quite
often,
we
use
automation
to
create
these
environments
and
to
ensure
that
they're
really
identical.
We
haven't
done
that.
We
have
used
manual,
work
to
actually
create
the
s3
bucket
and
we
did
some
automation
afterwards,
but
ideally
we
would
create
this
entire
infrastructure
automatically.
B
B
Now,
with
continuous
deployment,
as
I
said,
every
commit
that
goes
through
the
pipeline
would
also
land
on
the
production
server
in
the
production
environment,
with
continuous
delivery,
we're
still
using
automation
and
every
successful
merge
request
again
triggers
the
main
pipeline,
which
leads
on
automatic
deployment
to
the
staging
environment.
However,
we
don't
go
directly
to
production.
B
There
is
like
a
button
that
you
click
in
order
to
promote
a
build
from
the
pre-production
environment
to
the
production
environment,
so
these
are
like
the
differences
between
continuous
delivery
and
continuous
deployment
in
upcoming
lectures.
We're
gonna
get
a
bit
more
into
them,
and
you're
gonna
better
understand
like
what
they
really
mean.
B
B
B
What
you'll
notice
here
is
that
we
already
have
an
s3
bucket,
of
course,
that's
kind
of
an
inconvenient
at
this
point,
so
we'll
need
to
figure
out
exactly
how
we
can
manage
this.
What
I'm
going
to
go
ahead
and
also
call
it
aws,
s3
bucket,
I'm
going
to
call
it
staging
I'm
going
to
add
this
thing
that
will
make
it
different.
B
Essentially
now
we
can
protect
this
variable
because
we
don't
want
to
deploy
from
a
branch
anymore,
so
it
definitely
makes
sense
to
have
this
protected
masking.
It
doesn't
make
any
sense
at
this
point
all
right.
So
at
least
now
I
have
this-
I'm
gonna
copy,
the
name
so
that
they
don't
forget
it
and
let's
go
inside
the
project,
open
the
web
ide
and
start
making
some
changes
to
the
pipeline.
B
Now,
first
of
all,
because
this
is
a
pre-production
environment,
we
need
to
define
another
stage
before
we
deploy
to
production.
Let's
call
this
deploy
staging
and,
of
course,
what
we
need
to
do
here
is
to
define
a
new
job
now
most
of
this
job
is
pretty
similar
to
what
we
already
have
here
in
terms
of
deploy
to
s3
and
also
in
terms
of
the
production
test
that
we
have
here.
So
it
kind
of
makes
sense
to
copy
everything
that
we
have.
B
Apart
from
this,
we
are
using
the
same
image.
We
still
want
to
run
this
on
the
main
branch,
and
the
only
thing
that
we
need
to
adapt
here
is
the
bucket.
So
it's
going
to
be
a
little
s3
bucket
staging
and
again
the
test
that
we
have
here.
They
can
be
called
staging
tests.
We'll
see
here
that
you
know
the
editor
is
complaining
about
the
duplicate
key.
B
B
B
B
So
we
have
here,
deploy
staging
and
then
we
have
deploy
production,
but
then
we
have
post
deploy.
Now
we
also
want
to
have
this
testing
after
the
staging,
so
we
need
something
like
test
staging,
for
example,
and
we
can
call
this
test
production
right,
so
we're
deploying
to
staging
we're
testing
the
staging.
B
So
let's
make
sure
that
we
have
the
right
stages,
otherwise
we're
going
to
get
some
issues
so
deploy
production,
yes,
test
production
test,
staging
deploy,
staging.
We
have
the
right
bucket
name
here.
We
don't
have
the
right
url.
We
need
to
grab
that
as
well
for
staging
all
right
and
all
of
a
sudden.
Our
pipeline
got
a
bit
bigger,
but
no
worries.
B
One
last
check
deploy
staging
test
staging
deploy,
production
test
production,
deploy
staging
is
the
stage
we're
using
the
staging
bucket
paging
tests,
using
the
staging
url
test
staging
deploy,
production
test
production.
All
right,
I'm
going
to
go
ahead,
commit
these
changes
and
we'll
see
how
they
work
in
the
main
branch,
and
a
few
minutes
later
after.
The
main
pipeline
has
also
completed
we'll
see
now
that
we
have
here
a
bunch
of
stages.
So
after
the
tests,
then
we're
deploying
to
staging
we're
testing
staging
deploying
to
production,
we're
also
testing
production.
B
Of
course
we
could
go
ahead
and
combine
the
staging
so,
for
example,
because
our
tests
are
very
simple,
there's
nothing
that
prohibits
us
from
just
putting
this
simple
test
inside
the
deployed
job
itself,
so
that
will
save
us
some
stages
here,
but
I
just
want
to
demonstrate
like
how
how
longer
pipeline
essentially
looks
like
and
what's
the
meaning
of
the
stages.
So,
most
importantly,
now,
if
something
happens
with
the
deploy
stage,
the
pipeline
breaks
here,
production
environment
is
unaffected.
B
B
Obviously
we
have
now
two
environments,
but
we
haven't
really
figured
out
a
way
on
how
to
properly
manage
this
environment.
Luckily,
there
is
a
functionality
that
gitlab
offers
for
managing
these
environments
going
inside
the
project
you
will
find
here,
on
the
left
hand,
side
deployments
and
inside
deployments,
there's
this
optional
environment.
B
What
is
an
environment
staging
is
an
environment.
Production
is
an
environment
wherever
we're
deploying
something
that
is
an
environment,
and
it
really
makes
sense
to
have
these
environments
defined
somewhere
and
to
work
with
the
concept
of
environment
instead
of
fiddling
around
with
so
many
variables.
That's
really
not
the
best
way
on
how
to
do
that.
B
So
what
I'm
going
to
do
here,
I'm
going
to
create
a
new
environment
and
I'm
going
to
call
this
environment
production,
I'm
also
going
to
get
the
environment
url
from
the
pipeline.
So
let's
remember
this
is
the
production
url?
So
let
me
get
that
and
I'll
save
it
here
and
going
back
to
environments,
I'm
going
to
create
a
new
environment,
and
this
will
be
staging
again
going
back
to
the
pipeline
copying
the
name
of
the
environment
and
putting
it
here.
B
What
gitlab
will
also
do
is
to
keep
track
of
deployments
on
different
environments.
Now.
Currently,
we
don't
have
any
deployments,
but
we
can
directly
open
the
environments
from
here.
So
in
case
we
forget
where
the
our
environments
are,
we
can
easily
click
on
this
open
environment
link,
especially
for
non-technical
people
that
are
also
working
with
gitlab,
it's
easier
for
them
to
see
exactly.
Where
is
the
staging
environment?
B
What's
the
url,
I
don't
have
to
ask
someone:
it
can
just
directly
go
to
their
respective
environment
and
see
that
respective
version
so
very,
very
useful
feature
in
terms
of
environments,
but
what
does
it
do
for
our
pipeline?
Well,
I'll
tell
you
what
this
will
do
we're
going
to
remove
this
from
here
right,
I'm
going
to
go
ahead!
First
of
all,
this
is
out
I'm
not
using
this
anymore.
B
Second
of
all,
I'm
gonna
go
back
to
settings
ci
cd
and
expand
here
the
variables
and
I'm
gonna
go
here
to
this
aws
s3
bucket.
I'm
gonna
click
here
on
edit,
and
this
is
essentially
our
production
environment.
This
is
for
production,
and
now
we
can
also
give
a
scope.
So
we
can
tell
gitlab
hey
this
variable
is
associated
with
production
and
not
with
something
else.
So
we
can
essentially
scope
it
and,
of
course,
in
this
case,
because
we're
using
it
in
main
only
we're
gonna,
also
protect
this
variable.
B
I'm
gonna
go
ahead
and
update
here,
and
the
same
goes
for
this
other
variable
right
now.
We
don't
need
this
staging
added.
At
the
end,
we
can
just
call
it
aws,
s3
bucket
and
we're
going
to
select
here
the
staging
environment,
scope
and
update
the
variable.
So
now
we
have
two
variables
that
share
the
same
name,
but
now
they
belong
to
different
environments.
B
Now
the
idea
is
to
do
the
following.
We
need
somehow
to
adapt
our
pipeline
and
let's
begin
here
by
deploying
to
staging
first
of
all,
we
have
this
aws
s3
bucket.
So
I'm
going
to
remove
here
staging
from
the
end
and
additionally,
we
need
to
tell
gitlab
hey
this
deployed
to
staging.
This
is
associated
with
the
staging
environment.
I'm
going
to
say
here,
environment
staging.
B
There
are
still
a
few
things
I
would
like
to
change.
First
of
all,
the
entire
pipeline
right
now
is
too
long.
We
still
have
this
staging
test
and
production
tests,
and
because
this
is
just
one
curl
command,
we
can
just
move
it
away
from
here.
I'm
gonna
remove
this
stage
all
together,
and
all
I
want
to
do
is
to
add
it
here
on
deploy
to
staging
so
essentially
right
after
you
have
deployed
we're
also
using
this
curl
command,
it's
pretty
similar
to
what
we're
also
going
to
do
on
production.
B
But,
as
you
probably
noticed
already,
this
app
base
url
doesn't
exist
anymore.
We
have
removed
those
variables
and
we
need
to
find
a
way
to
get
our
environment
url
and
luckily
again,
gitlab
to
the
rescue.
There
is
a
variable
I'm
going
to
go
ahead
and
search
for
environment,
and
I'm
going
to
have
here
the
ci
environment,
name,
environment,
slug,
environment
url.
So
this
is
what
we're
interested
in
the
environment.
Url
I'm
gonna
copy
this
and
I'm
gonna
put
it
here
in
the
curl
command,
so
I'm
gonna
send
the
curl
command
directly
to
the
ci
environment.
B
So
in
this
situation
the
production
tests-
they
also
don't
make
any
sense,
so
I'm
gonna
remove
them
and
all
these
extra
stages
that
we
have
here
test
production,
it's
not
going
to
be
needed
test
staging
it's
not
going
to
be
needed.
So
now
we
have
a
much
more
simpler
pipeline,
but
we're
still
achieving
the
same
thing.
B
B
Now,
if
we're
looking
at
the
main
pipeline,
you
will
notice
something
interesting.
Deploy.
Staging
has
passed.
It's
working
perfectly.
You
will
see
here,
curl,
ci,
environment
url,
it's
fetching
the
page.
It's
passing,
however,
if
you're
looking
here
at
deploy
to
production,
it's
all
of
the
sudden
complaining
it's
saying
here
that
aws
is
three
bucket
parameter.
Validation,
failed
invalid
bucket
name.
B
We
somehow
did
not
associate
this
with
an
environment
or
the
environment
is
not
correct,
so
we
need
to
go
back
and
see
why
this
job
does
not
have
access
to
this
environment.
Variable
I'm
going
to
go
ahead
here
and
take
a
look
again
at
the
configuration
to
make
sure
that
the
configuration
itself
of
the
job
is
correct.
B
What
do
we
have
here,
or
we
have
deployed
to
production,
but,
as
you
can
notice,
I
haven't
defined
an
environment
right,
so
I
have
defined
an
environment
for
deploy
to
staging,
but
I
haven't
defined
an
environment
for
deploy
to
production
by
looking
here
at
the
variables
you
will
see
that
this
aws
s3
bucket
is
now
scoped
only
for
production
and
because
this
job
doesn't
say
anything
about
production.
This
environment
is
not
exposed
in
the
production
job
so
to
be
able
to
solve
this.
B
We
also
have
to
add
here:
environment
production,
I'm
going
to
go
ahead
and
copy
this
and
the
environment
will
be
production
and,
of
course,
unfortunately,
this
time
we
have
to
go
again
through
all
the
stages.
The
merge
request
and
committing
this
in
the
main
branch,
and
just
a
few
minutes
later,
the
entire
pipeline
will
then
succeed.
So
we
have
deployed
the
staging.
We
have
deployed
to
production.
B
Everything
seems
to
be
working
fine.
We
can
take
a
look
at
the
jobs
to
see
what
they're
doing
and
we'll
see
here
that
everything
worked
out
without
any
issues
and
of
course
we
can
also
go
here
to
deployments
environments,
and
here
we
are
able
to
see
the
staging
environment
and
the
production
environment
and
we
can
easily
open
them
and
we
can
see
like
what
was
deployed
when
was
it
deployed.
So
it
really
keeps
track
here
of
the
different
environments
and
the
deployments
that
took
place.
B
B
B
Well,
essentially
at
this
point,
because
we
have
used
all
these
variables,
these
jobs
are
almost
identical.
The
only
thing
that
is
different
is
the
different
stage,
different
job
name
and
we're
specifying
the
environment,
but
the
rest
of
the
configuration
is
identical
and
yes,
the
answer
is
yes,
we
can
simplify
this
even
more.
B
B
B
B
B
B
B
Let's
commit
this,
give
it
a
try,
see
how
it
works,
and
it
should
essentially
work
the
same
as
before
and
after
a
few
minutes.
If
we
take
a
look
at
the
main
pipeline,
we'll
see
that
it
works
as
it
should
work.
It
looks
as
before,
and
this
is
exactly
what
we
expected.
We
didn't
want
to
see
anything
else,
but
the
pipeline
working,
but
now
we
have
a
much
simpler
pipeline
configuration.
B
And
now
feel
it
is
time
for
another
assignment.
Now,
let
me
tell
you
my
idea:
now
we
have
this
pipeline
and
we're
testing
with
the
curl
command
that
that
specific
text
is
on
the
website
and
that's
fine.
It
ensures
that
the
website
is
still
working.
We
currently,
we
haven't
really
made
any
changes
to
the
website
itself.
We
haven't
added
any
text
or
removed
anything.
How
can
we
make
sure
that
you
know
with
what
we
actually
built
here
actually
lands
on
the
staging
and
in
the
production
environment?
B
B
What
if
we
add
another
file
in
our
build,
let's
call
it
version.html,
for
example,
and
inside
there
we
put
a
build
number
something
that
is
all
the
time
different
with
each
build.
So,
for
example,
it
will
increment
from
one
two,
three,
four
and
so
on,
so
that
with
every
build
we
can
identify
to
build
number
and
we
can
check
which
version
has
been
deployed
to
staging
and
production.
B
How
about
this
idea
and
in
order
to
get
you
started,
I'm
going
to
show
you
how
to
get
this
information
inside
there
how
to
get
this
build
information
this
dynamic
part.
Maybe
this
is
something
that
right
now,
you
don't
know
exactly
how
to
do
it
so
no
worries,
I'm
going
to
get
you
started,
but
the
rest
of
the
assignment
will
have
to
figure
it
out
on
your
own
trust
me.
B
You
already
know
all
the
concept
needed
in
order
to
implement
something
very
simple,
so
I'm
going
to
go
ahead
here
and
define
a
variable
and
I'm
going
to
call
this
variable
app,
underscore
version.
So
essentially,
let's
say
that
this
is
our
application
version,
so
want
to
have
something
like
12,
13,
14
and
so
on.
B
B
So
if
we're
looking
for
pipeline
underscore
id
find
here
some
pipeline
ids
that
we
can
use
so
these
are
variables
that
of
course,
change
all
the
time
they
are
injected
by
gitlab,
so
we
can
use
them
in
our
jobs,
so
we
can
get
here
like
an
instance
level
id.
This
typically
includes
like
very
large
numbers,
because
there
are
a
lot
of
pipelines
on
a
gitlab
instance,
but
you
can
also
get
like
a
project
level
id.
So
this
will
be
something
we
can
easily
relate
to
it's
and
we're
going
to
see
it
increment
all
the
time.
B
B
B
Okay,
so
I
hope
that
you
have
managed
to
solve
this
on
your
own.
I
already
feel
I
gave
you
like
quite
a
lot
of
hints,
but
just
to
make
sure
this
is
how
I
would
solve
it.
So,
let's
go
here
to
the
build
website,
apart
from
all
these
things
that
we're
doing
here,
what
I
want
to
do,
additionally,
is
to
create
this
file.
So
again,
in
order
to
create
this
file,
we
have
to
first
think
about
the
name,
so
it's
going
to
be
inside
the
build
folder
right.
B
This
is
this
is
what
we're
deploying
and
the
name
will
be
version.html,
and
what
we're
doing
is
we're
taking
this
application
version.
So
in
order
to
get
the
application
version
inside
the
file,
gonna
use
echo,
I'm
gonna
print
the
application
version
and
then
eventually
again
redirect
it
to
the
file.
So
this
is
enough
to
create
this
file,
to
put
it
inside.
The
build
folder
which
already
exists,
build
yarn,
build,
has
created
that
and
because
this
is
dynamic,
it
will
be
available
there.
B
B
I'm
gonna
go
here
to
deployments
environments,
I'm
gonna
go
to
staging
click
on
edit,
I'm
noticing
here
I
don't
have
a
forward
slash.
So
that's
already
good
and
I
presume
that
the
production
environment
is
also
similar,
but
just
to
check
I
did.
I
don't
have
a
forward
slash
okay,
so
inside
our
configuration,
I'm
gonna
add
here
forward,
slash,
I'm
gonna
write
here
version
and
what
are
we
looking
for?
Well,
we're
looking
for
the
application
version
and
because
the
application
version
is
simple
number
we
don't
need
these
quotes
here.
B
So
I'm
able
to
see
it
here,
version.html
it
has
a
size
that
is
not
zero,
that's
a
good
thing
and
we
can
also
download
all
the
artifacts
or
just
look
at
a
single
file.
So
after
clicking
on
this
somewhere
here
on
the
screen,
it
will
open
up
this
web
page
essentially.
So
this
is
the
build
number
35.,
it's
pretty
small,
but
you
should
be
able
to
see
it
on
screen
as
well.
So
this
is
part
of
the
file.
So
it's
already
looking
good.
B
When
this
much
request
is
completed,
I
will
also
take
a
look
in
the
main
branch
now.
The
main
pipeline
is
also
working
makes
me
very
happy,
because
I
now
have
more
confidence
in
what
is
going
on
in
this
pipeline.
I
have
confidence
that
if
I'm
making
a
change
that
change
actually
gets
deployed
to
staging
and
production-
and
we
have
this
additional
check,
then
in
place
to
ensure
that.
B
All
right,
so,
let's
recap
a
bit
what
we
did.
The
first
part
is
the
ci
part
continuous
integration.
The
second
part
is
cd
continuous
deployment.
Now
we
have
a
more
realistic,
continuous
deployment
pipeline,
we're
testing
something
and
then
we're
first
deploying
to
staging
making
sure
that
on
staging
everything
works
and
after
that
we
deploy
to
production.
B
But
what
is
a
continuous
delivery
pipeline?
This
is
exactly
what
I
wanted
to
show
you.
Essentially,
a
continuous
delivery
pipeline
is
just
a
pipeline
where
we
don't
automatically
deploy
to
production.
Essentially,
what
we
want
to
do
is
add
here
a
button,
and
only
when
we
are
sure
that
we
really
want
to
make
that
change
to
production.
We
can
click
on
that
button
and
make
that
change.
So
let
me
show
you
how
to
do
this.
B
Now
this
is
the
final
pipeline
and
I
want
you
to
notice
something
for
deploy
production.
This
job
now
looks
a
bit
different
right.
If
you
look
at
deploy
staging
click
here
on
deploy
production,
we'll
say
here.
This
is
a
manual
action
and
we
have
here
an
additional
button
right
if
we
also
go
to
our
deployments-
and
we
take
a
look
at
environments,
we'll
be
able
to
see
here
like
what
we
have
on
each
environment.
B
B
B
B
You
cannot
always
deploy
everything
without
checking
a
few
things
in
advance.
Now,
if
we're
looking
here,
deploy
to
production
has
also
completed.
So
we
can
take
a
look
here
if
I'm
gonna
refresh
this
website,
I'm
gonna
get
here
version
40.
and
here
on
the
staging
also
version
40..
So
now
both
staging
and
production
have
the
same
version
now.
I
hope
that
the
difference
between
continuous
delivery,
what
we
did
right
now
and
continuous
deployment,
where
every
commit
that
lands
in
the
master
branch
gets
deployed
to
production,
makes
more
sense.
Now.
B
B
So
far,
we
have
worked
with
a
static
website
and
deployed
it
to
aws.
It's
probably
one
of
the
easiest
scenarios
involving
gitlab,
ci
and
aws.
However,
modern
applications
tend
to
be
more
complex
and
most
of
them
use
docker
nowadays.
So
in
this
section,
we'll
dockerize
our
website
and
instead
of
copying
some
files
to
aws
we'll
be
deploying
an
application
that
runs
in
a
docker
container
to
do
that.
We'll
build
a
docker
image
as
part
of
the
build
process,
store
it
in
the
gitlab
container
registry
and
deploy
to
a
service
on
aws
called
elastic
beanstalk.
B
But
this
also
means
that
we
are
in
charge
of
managing
that
machine.
We
need
to
ensure
that
it's
secure
and
that
all
software
running
is
updated.
This
is
often
too
much
overhead,
especially
for
some
types
of
applications,
but
there
is
a
way
to
take
away
this
complexity
and
focus
only
on
the
application
we
want
to
deploy.
B
Aws
elastic
beanstalk
is
a
service
that
allows
us
to
deploy
an
application
in
the
aws
cloud
without
us
having
to
worry
about
the
actual
virtual
server
that
runs
it.
This
is
a
great
way
to
reduce
complexity,
and
it's
probably
one
of
the
easiest
way
to
deploy
an
application
in
the
aws
cloud
by
default.
Elastic
bin
stock
can
run
python,
java,
node.js,
php
and
many
other
types
of
applications,
but
it
can
also
run
docker
containers,
which
really
gives
us
a
lot
of
flexibility,
we'll
be
running
a
web
server
application
that
serves
our
simple
website
files.
B
So
this
time,
instead
of
just
uploading
some
files
to
aws,
we
are
providing
the
entire
application,
which
is
self-contained
in
a
docker
container.
I'm
sure
you'll
be
amazed
by
how
easy
it
is
to
run
an
application
here.
In
the
background,
we
will
be
using
a
virtual
machine,
but
we
don't
need
to
worry
about
managing
it.
B
B
B
B
So
let's
call
this
application.
My
website,
you
don't
need
to
include
any
application
tags
and
here
on
the
platform,
there
are
different
platforms
that
are
supported,
but
what
you're
actually
interested
in
is
in
the
docker
platform
so
that
we
can
essentially
deploy
anything.
We
want
I'm
going
to
select
here,
docker
I'm
going
to
leave
the
defaults
as
they
are
and
the
first
step
would
be
to
start
with
a
sample
application,
so
we're
not
going
to
upload
any
code
we're
going
to
let
elastic
beanstalk,
create
this
instance.
B
B
So
what
has
happened
here?
Well,
we
have
created
an
application
and
we
have
initialized
a
sample
application
that
elastic
bean
stock
provides
in
order
to
actually
run
that
application.
This
wizard
that
we
have
used
is
set
up,
has
also
created
an
environment,
so
we
have
applications
which
is
like
an
umbrella
for
environment.
B
B
In
order
to
see
like
what
this
environment
is
doing,
we're
gonna
click
here
on
it
you'll
be
able
to
see
here
a
link.
So
if
you
click
on
this
link,
this
is
the
sample
application
that
was
deployed.
So
it's
just
an
idea,
tells
you
that
everything
is
working
properly,
that
we
have
nothing
to
worry
about.
This
entire
setup
has
worked
without
any
issues.
B
B
These
are
essentially
virtual
servers
that
we
can
create
here,
but
we
haven't
actually
created
one,
but
if
you're
looking
here
at
instances,
you'll
see
that
we
have
one
running
instance
and
this
instance
is
called
my
website
dash
and
you'll
see
here,
which
kind
of
an
instance.
This
is.
This
is
a
virtual
server,
that's
running
here,
and
this
is
the
server
that's
actually
running
our
application.
B
B
B
B
So
I'm
going
to
go
ahead
and
select
the
file,
and
I
can
also
write
here
a
version
label.
This
will
be
sample
application
version.
One.
That's
totally
fine
and
I'm
going
to
go
ahead
and
click
on
deploy
and
what
will
happen
is
elastic.
Beam
stock
will
take
this
file
and
then
we'll
start
a
deployment
we'll
start
here,
updating
the
environment.
B
Of
course
this
will
take
a
few
minutes,
but
in
the
end,
what
we
want
to
see
here
is
health
status.
Okay,
wanna
see
that
everything
is
working
properly
and
want
to
see
that
this
application
has
been
deployed
and
is
available
at
this
address,
and
now
we're
seeing
here,
status
is
okay,
so
health
is
okay,
everything
seems
to
be
working
properly.
You
can
also
go
ahead
and
refresh
this
page
just
to
see
here,
which
version
is
running.
B
B
So
this
is
the
welcome
page
from
the
nginx
server
which
we
have
deployed
by
having
this
json
file,
which
describes
which
container
we
want
to
use
with
elastic
bean
stock.
So
in
order
to
actually
deploy
our
website,
we
need
to
create
a
docker
image.
We
need
to
provide
this
json
file
and,
of
course,
we
also
want
to
automate
everything.
So
this
is
what
we
are
gonna
do
in
the
upcoming
lectures.
B
B
We
store
these
instructions
in
a
file
called
docker
file,
so
let's
go
ahead
and
create
one
so
here
from
the
web,
ide
I'm
gonna
go
ahead
and
create
a
new
file,
and
you
will
see
here
in
the
suggestions.
One
of
the
suggestions
is
docker
file
so
which
are
these
instructions
that
will
write
inside
the
docker
file.
B
First
of
all,
we
have
to
start
with
a
base
image,
essentially
an
image
that
we
want
to
add
something
on
top
of
it
in
our
case,
because
we
want
to
deploy
web
server
with
our
files,
we're
going
to
start
with
the
engine
x
image.
It
is
exactly
the
same
image
we
have
used
in
order
to
test
our
deployment
to
elastic
bean
stock.
So
I'm
gonna
write
here
from
nginx
and
additionally,
what
I
highly
recommend
is
writing
a
version.
So
writing
a
specific
tag.
B
B
So
what
I'm
searching
here
for
is
a
specific
tag,
so
this
here
would
be
a
very
good
tag
to
use,
just
as
an
example,
I'm
going
to
go
ahead
and
copy
that
and
here
in
the
editor
column
and
the
version,
so
you
have
to
be
very
careful
how
you're
writing
this
has
to
be
something
like
this,
so
we're
starting
from
this
base
image.
So
we
have
everything
that
is
in
the
base
image
we
have
there,
so
we
already
have
the
application.
Essentially,
the
application
is
the
web
server.
B
Now.
The
next
step
is
to
actually
add
our
files,
which
are
in
the
build
folder
and
to
put
them
on
this
web
server,
and
we
do
that
by
using
the
copy
command
and
right
here
copy.
So
what
are
we
copying?
We're
copying
the
build
folder.
Then
we
have
to
specify
where
we
are
copying
it
now
by
default.
There
is
a
folder
where
nginx
will
store
files
that
we
want
to
serve
and
that
folder
has
the
following
path:
forward:
slash
user,
usair,
share,
nginx
and
then
html,
so
we're
moving
this
folder
inside
html
folder.
B
So
this
is
everything
that
we
need
to
do
in
order
to
build
our
docker
image.
These
are
the
only
instructions
that
we
need
at
this
point
we're
getting
this
base
image
nginx
in
a
specific
version
because
we're
using
this
tag
and
then
the
next
instruction
is
copy
everything
that
is
in
the
build
folder
and
move
them
to
this
html
folder.
B
Just
because
we
have
created
this
docker
file
doesn't
mean
that
something
will
automatically
happen.
We
still
need
to
make
some
changes
to
our
pipeline
and
because
we're
already
making
changes
and
because
we
want
to
deploy
to
elastic
bean
stock,
we
don't
really
need
this
s3
deployment
anymore,
so
I'm
going
to
remove
essentially
all
the
jobs
that
are
related
to
s3.
B
This
includes
deploy
to
production,
deploy
to
staging
this
deploy
job,
which
is
just
a
template
and
also
test
website,
we're
going
to
introduce
a
better
way
of
testing,
so
I'm
going
to
remove
all
of
them
and
what
remains
is
the
build
website
and,
of
course,
also
the
stages
here
they
can
be
removed.
So
what
we're
gonna
do
is
we're
gonna
introduce
a
new
stage,
let's
call
it
package
and
we're
gonna
associate
this
stage
with
a
new
job.
Gonna
call
it
build
docker
image,
and
now
the
stage
will
be
packaged.
B
So
how
do
we
build
the
docker
image?
Well,
it's
relatively
simple:
the
command
is
docker,
build,
I'm
going
to
also
add
a
dot
here,
because
that's
going
to
make
a
reference
to
the
current
folder
and
the
current
folder
contains
the
docker
file
that
we
have
created
in
order
to
be
able
to
run
this
docker
command.
We
also
have
to
define
the
image
that
we'll
use
and
the
image
will
be
docker.
B
Just
using
this
docker
image
will
not
work.
We're
gonna
get
an
error.
The
reason
for
that
is,
the
docker
architecture
is
composed
of
a
client
and
a
server.
Essentially
what
we
have
here
docker
this
is
the
client
and
the
client
sends
some
instructions
to
a
server
actually
to
the
docker
demon,
which
is
the
one
who
builds
the
job
and
in
order
to
get
access
to
a
daemon
inside
gitlab
ci.
B
B
So
this
service
is
another
docker
image
that
can
build
docker
images
cannot
be
accessible
for
us
over
a
network
and
docker
here,
which
is
the
docker
client,
will
be
able
to
talk
with
the
docker
daemon,
which
is
here
inside
this
service.
I
know
that
now
at
the
beginning,
this
may
seem
all
bit
confusing,
but
this
is
like
the
minimum.
What
we
need
in
order
to
be
able
to
build
docker
images
from
gitlab.
B
What
I
also
like
to
do
is
to
set
some
tags,
so
I'm
going
to
go
ahead
and
write
a
fixed
stack
for
docker
and
for
docker
in
docker,
so
I'm
here
at
docker
hub-
and
this
is
the
docker
image
you
will
find
the
link
in
the
course
notes,
because
this
is
something
that's
not
so
easy
to
find.
Actually
not
so
many
people
are
actually
looking
for
docker
and
I'm
gonna
use
this
version
here.
B
I'm
gonna
go
ahead
and
copy
it,
and
I'm
gonna
add
it
here
to
my
job
image
and
additionally,
there's
another
tag
with
docker
in
docker.
This
is
the
tag
that
I'm
gonna
use
for
the
docker
daemon.
I'm
gonna
remove
here
dent
and
this
will
be
the
docker
in
docker
image.
You'll
see
both
of
them
have
the
same
version.
B
Additionally,
when
we're
building
images,
we
also
like
to
specify
tags
like
label.
This
will
help
us
identify
the
images
that
we
create,
because
we
can
create
multiple
images.
Of
course,
in
order
to
tag
images,
we
first
have
to
specify
an
image
name
and
also
the
tag.
So
we
can
use
here
dash
d,
you're
gonna,
keep
here
this
dot
at
the
end,
that's
very
important,
don't
forget
it,
and
what
we'll
use
here
is.
This
is
the
list
of
environment
variables
and
one
of
these
environment
variables.
Is
this
ci
registry
image
so
we're
going
to
use
here?
B
Ci
registry
image,
don't
forget
to
put
a
dollar
in
front
of
it.
This
will
build
the
latest
tag,
so
this
is
a
tag
that
always
points
to
the
latest
image
that
we
have
created
and
additionally,
I'm
going
to
create
another
tag
which
still
contains
cr
register
image.
I'm
going
to
add
here
a
dollar
in
front
to
make
it
a
variable,
I'm
going
to
add
here,
column
and
we're
going
to
use
the
app
version
that
we
are
still
having
here
in
our
job.
B
B
Additionally,
in
order
to
make
sure
that
we
have
indeed
built
this
docker
images,
we're
going
to
use
here,
docker
image
and
ls.
Actually,
we
are
building
only
one
image,
but
we
are
tagging
that
image
with
two
different
tags,
the
latest
and
the
app
version.
So
this
will
show
us
all
the
images
that
are
available
with
all
the
tags
that
are
available
in
this
instance.
B
I'm
not
gonna
run
this
job
only
on
the
main
branch-
I'm
just
gonna,
run
it
inside
the
branch.
I'm
still
here
in
the
branch
playing
around
so
we're
gonna
see
how
this
looks
like
after
we
execute
it
and
once
the
execution
is
done,
we're
gonna
jump
directly
into
the
build
docker
image
and
try
to
understand
what
has
happened
here
so
we'll
see
where
there
are
a
bunch
of
locks
that
have
been
generated.
B
But,
most
importantly,
what
we
want
to
see
here
is
which
docker
image
are
we
using
so
we'll
see
here?
This
is
the
docker
image
which
is
darker
and
then
we're
also.
This
is
new,
we're
starting
this
service
with
docker
in
docker,
so
the
service
will
be
available
over
the
network
inside
this
image
that
we
have
right
now.
This
will
give
us
the
docker
client,
and
there
are
a
lot
of
locks
here
and
they're,
not
really
so
relevant.
The
interesting
part
comes
when
we're
actually
building
the
image
and
you'll
be
able
to
see
here.
B
This
is
our
command.
There
are
some
steps
how
these
docker
images
are
being
built.
Docker
works
with
concept
of
layers,
but
we
won't
go
into
that,
but
this
is
exactly
what's
happening.
Here
is
every
essentially
every
command
that
we're
executing
will
create
an
additional
layer
on
that
image.
We
have
successfully
built
this,
so
this
is
what
you
want
to
see.
It
has
been
successfully
built,
and
then
we
have
also
the
two
tags
that
we
have
created.
B
You
will
see
here
the
latest
tag,
and
this
is
also
the
version
tag
now
they
both
point
to
the
same
image,
but
they
are
different
text
and
you
will
better
see
it
here
with
this
command.
That
is
listing
images.
So
this
is
here
the
essentially
the
name
of
the
image
we'll
see
here
the
tag,
and
you
will
see
that
internally,
the
image
id
is
the
same,
so
we
have
the
same
image
but
with
two
different
tags.
So
now
we
have
successfully
managed
to
build
and
tag
our
image.
B
We
need
to
save
it.
In
a
registry,
for
example,
docker
hub,
which
we've
been
using
to
find
out
tags
and
images
that
we
can
use,
is
a
public
registry
with
docker
images.
However,
typically
our
projects
are
not
public,
so
it
doesn't
really
make
sense
to
use
docker
hub.
So
for
that
reason
we
need
a
private
registry,
both
aws
and
gitlab,
offer
private
docker
registries
and
for
this
example,
we'll
be
using
the
docker
registry
offered
by
gitlab
and
you'll,
see
here
on
the
left,
hand,
side,
packages
and
registry
and
we're
going
to
use
here.
B
The
container
registry,
because
docker
is
all
about
working
with
containers
and,
of
course,
at
this
point
there
are
no
container
images
stored
for
this
project
so
alone.
Just
building
that
ochre
image
does
not
automatically
add
it
to
the
container
registry.
Actually,
this
is
called
pushing.
So
when
we
want
to
save
a
docker
image
in
a
registry,
we
need
to
push
it
to
the
registry,
so
let's
go
back
and
make
some
changes
to
our
pipeline.
B
So
let's
take
a
look.
How
do
we
push
so
the
command
in
order
to
push
something
is
docker
push
and
we
actually
want
to
push
all
tags,
so
we're
going
to
use
here,
parameter
dash,
dash
all
dash
tags
and
then
we're
going
to
specify
here
the
ci
registry
image.
So
this
is
in
term
of
pushing,
but
where
are
we
pushing,
and
especially,
if
it's
a
private
registry,
don't
we
need
to
log
in
somehow?
B
Yes,
that's
correct
so
alone
pushing
this
will
not
work
in
our
case.
We
need
to
do
something
before
we
push
and
we're
going
to
do
it
right
here
in
the
beginning,
because
in
case
there
are
some
issues
which
the
login
we
want
to
know
as
soon
as
possible,
and
not
only
at
the
end,
so
the
command
to
login
is
docker,
login
relatively
easy
and
we're
going
to
specify
username
and
password
for
this
service
we're
not
actually
using
our
username
and
password
that
we
used
to
log
into
gitlab,
we'll
use
some
variables
again.
B
B
First
of
all,
where
do
we
want
to
log
in?
This?
Is
the
cia
registry,
so
we
need
to
specify.
Where
do
we
want
to
log
in
and
additionally,
we
need
to
specify
our
username
and
password,
so
we
typically
specify
the
username
and
password
like
dash?
U
and
then
specify
the
username
and
we're
gonna
use
another
variable,
ci
registry
user,
with
the
dollar
sign
in
front
of
it
that's
very
important,
and
additionally,
we
can
specify
password,
p
and
we'll
see
here,
ci
registry
password.
B
So
these
are
all
the
credentials
that
we
need
in
order
to
log
in
in
more
recent
versions
of
docker,
just
specifying
your
password
like
this
is
not
really
the
best
way
to
log
in.
You
may
get
a
warning,
and
it's
possible
that
in
future
releases
this
argument,
this
dashb,
will
not
be
available
anymore.
B
So
what
I
like
to
do
is
the
following:
I'm
gonna
remove
it
from
here
just
gonna
copy
this
variable,
and
actually
what
we
can
do
here
is
we
can
say
to
docker
login
get
the
password
from
the
standard
input
and
I'll
explain
a
second.
What
the
standard
input
is
you
wanna
write
here
dash
dash
password
dash
std
in
this
is
the
standard
input,
so
the
standard
input
is
essentially
something
that
we
are
piping
from
another
command
and
that
other
command
in
our
case
will
be
echo.
B
So
we're
going
to
echo
this
ci
registry
password,
but
we're
not
going
to
display
it
in
the
logs
we're
going
to
use
this
pipe,
so
this
will
be
available
in
the
standard
input
for
the
docker,
login
and
docker.
Login
will
look
at
that
standard
input
and
we'll
see.
Oh
okay,
the
password
is
coming
from
there,
so
we're
going
to
grab
it
from
there
using
it
in
this
way
will
ensure
that
this
password
doesn't
get
exposed,
but
really
for
ci.
B
In
our
case,
it
will
not
get
exposed
anyway,
but
it's
any
good
to
know,
and
this
is
why
we
have
this
construct
here.
So
once
again,
we
are
echoing
this
password
and
we're
sending
it
to
docker
and
docker.
Login
will
know
that
this
password
is
coming
from
the
standard
input,
and
apart
from
that,
we
have
the
parameter
with
the
user
for
docker
login.
Where
are
we
logging
in
to
the
registry?
B
B
This
are
the
tags
that
are
available,
so
we
had
tag
46
and
latest,
and
this
is
pushing
the
tags
to
the
registry,
so
no
errors
here
and
what
we
can
do
next
is
to
go
here
inside
the
registry
inside
the
container
registry
and
we'll
see
here
this
root
image,
and
if
we
take
a
look
at
it
we'll
see.
Currently
we
have
two
tags,
we
have
tag
46
and
the
latest
tag
will
also
tell
us
the
size
of
our
image
because
we
are
using
alpine
as
a
base
image.
Also,
our
images
are
relatively
small.
B
So
now
we
have
successfully
built
this
container,
but
how
do
we
know
that
application
is
actually
working?
How
do
we
know
if
nginx
is
serving
our
files
if
we
have
the
right
files
and
if
everything
is
working,
as
we
think
is
working
before
we
actually
move
on
to
the
next
step,
which
is
deploying
to
aws?
B
Let's
call
this
job
test,
docker
image,
I'm
going
to
assign
the
stage
test
and,
let's
think
about
like
how
we
can
test
this
essentially
the
way
we're
testing
this
docker
image
is
not
much
different
than
the
way
we
have
tested,
for
example,
a
deployment
or
any
other
things
in
the
past.
We
can
still
use
curl
to
do
that.
B
So
what
do
we
need?
Okay,
we
need
curl,
so
we
need
a
simple
image
that
has
curl,
so
we're
going
to
use
curl
images,
slash
forward,
slash
curl,
so
that
should
be
enough
to
get
this.
But
the
question
is:
how
do
we
start
this
container
right?
This
is
where
the
part
that
we
have
learned
before
can
be
very
useful,
and
that
part
is
services.
B
B
B
And
the
tag
will
be
the
app
version
we
don't
want
to
use
the
latest.
I
want
to
go
exactly
like
what
is
a
current
tag
that
we
want
to
see,
so
this
will
help
us
start
the
image
and,
additionally,
what
we
can
do
is
to
specify
an
alias,
an
alias
allows
us
to
give
a
friendly
name
so
that
we
know
where
this
service
is
available
over
the
network.
B
B
B
B
So,
in
order
to
automate
this,
we
need
to
generate
essentially
this
json
file,
upload
it
to
s3
and
from
there
we'll
tell
elastic
bin
stock
to
start
a
new
deployment
so
going
back
to
the
pipeline.
What
we
need
to
do
is
to
re-enable
the
deploy
stage
and
the
deploy
to
production
job
this
time,
focusing
on
deploying
to
elastic
pinstock.
B
So
let's
go
ahead
and
add
a
new
stage
deploy
and,
of
course,
also
a
new
job
here
deployed
to
production
since
we'll
be
using
aws
cli.
I'm
just
gonna
add
the
basic
structure
that
we
need
to
this
job
in
order
to
be
able
to
use
aws
cli,
so
using
aws
cli
as
a
docker
image.
We're
overriding
the
entry
point.
B
B
The
format
of
the
file
is
very
important,
because
this
file
tells
aws
elastic
binstock
what
we
are
trying
to
deploy,
and
it
will
say
here
that
this
is
our
image,
and
this
is
our
tag,
so
we
have
them
here
as
variables,
but
additionally,
because
this
is
a
private
registry,
we
also
need
to
provide
some
authentication
information
and
that
authentication
information
is
another
file.
So
that
file
is
this
oauth
file
and
in
this
auth
file
we
will
need
to
add
a
token
that
gives
access
to
the
registry
and
essentially,
what
we
need
to
upload
to
s3.
B
Is
this
file
docker
run
and
this
auth
file,
which
is
actually
linked
from
here?
It's
mentioned
here
of
that
json.
So
let's
go
to
the
pipeline
and
quickly
add
these
files,
I'm
going
to
simply
paste
here.
The
configuration
required
so
now
I've
added
this
copy
configuration
to
the
script
so
we're
still
using
aws
s3
copy,
it's
pretty
similar
to
what
we
did
before
in
terms
of
copying
files
to
aws
s3.
B
B
It
is
env
so
from
environment
subs.
So
relatively
easy
to
tell
what
this
does.
It
replaces
environment
variables.
Then
we
need
to
specify
like
what
is
the
input
file
and
we
do
it
with
this
smaller
than
sign,
essentially,
and
then
we're
gonna
go
here
and
say
something
like
templates
and
give
here
the
name
of
the
file,
and
then
we
will
have
to
specify
the
output
file
that
will
be
generated
and
the
output
file
will
be
this
one.
So
the
name
of
the
file
will
stay
the
same.
B
The
location
will
change,
it
will
be
put
in
the
current
folder,
and
this
is
perfect
for
the
next
command
that
we'll
be
using
we're
doing
this
environment
substitution,
replacing
all
the
variables
here
for
the
auth
file
just
as
well,
so
I'm
just
gonna
replace
that
there
and
there
so
any
environment
variables
that
are
in
these
files
will
get
replaced
in
order
to
use
this
command,
we
need
to
install
an
utility
which
is
called
get
text
now.
This
doesn't
come
directly
in
this
amazon
image.
So
this
is
something
that
we
need
to
install.
B
Additionally,
I'm
going
to
use
this
package
manager
to
install
this
dependency,
which
is
called
get
text
and
get
text.
Has
this
tool
for
environment
substitution.
Gonna.
Also
add
this
flag
here.
This
will
essentially
answer
with
yes,
any
questions
that
this
installer
may
ask,
because
we
are
in
a
way
that
we
cannot
interact
with
an
installer,
we're
gonna,
specify
this
and
say:
okay,
just
install
it.
If
there
are
any
questions
answer
with
yes,
just
to
ensure
that
the
installation
process
works
without
any
issues.
B
Of
course,
it's
going
to
be
very
nice
to
actually
take
a
look
at
these
files,
so
we're
going
to
use
here
cat
just
to
make
sure
that
these
environments
were
substituted
as
we
expect
them
and
as
a
final
check,
we
should
also
go
in
these
files
and
make
sure
that
we
have
all
variables
here
so
see
a
registry
image,
app
version.
This
is
something
that
we
already
defined.
B
So
we
have
this
information
here,
aws
s3
bucket.
This
is
relevant
for
where
we
are
uploading
these
files.
Now
because
we
are
using
elastic
bean
stock,
an
elastic
beanstalk
has
already
created
an
s3
bucket.
Well,
maybe
we
should
use
that
one.
So
I'm
gonna
switch
here
to
the
s3
service
and
what
I'm
going
to
do
is
I'm
going
to
copy.
This
name
could
have
used
this
other
package
that
we
have
created
here,
but
I
don't
want
to
put
anything
any
credentials
in
a
public
folder.
So
with
that
being
said,
I
prefer
to
use
this
bucket.
B
B
So
at
least
at
this
point
we
have
everything.
Let's
see
this
other
file,
the
off
file
you'll,
see
here
in
the
auth
file
there
is
this
deploy
token
now?
What
is
the
thing?
Well,
we
have
pushed
our
docker
image
in
the
gitlab
repository,
but
aws
has
no
credentials
to
connect
to
it
and
again
we're
not
providing
username
and
passwords,
not
our
account
username
and
password.
B
We
will
generate
a
token
and
gitlab
allows
us
to
generate
a
deploy
token
that
can
be
used
by
aws
to
log
into
our
private
docker
container
repository
and
pull
that
image
so
now
to
do
that
from
settings.
We're
going
to
go
here
to
repository
and
we'll
see
here,
deploy
tokens
as
one
of
the
options,
and
here
we
can
create
a
deployed
token,
so
we're
gonna
name
it
aws,
so
that
we
know
why
we
have
created
it,
and
I
give
the
username
aws
and
the
permissions
that
we
need
is
read
repository
and
read
registry.
B
B
B
Now,
here
inside
the
pipeline,
we
still
need
to
do
a
small
change
to
the
pipeline
itself
to
the
script
itself,
and
the
thing
is:
we
need
to
convert
this
username
and
password
to
base64,
because
this
is
what
we
need
inside
this
configuration
json.
This
is
what
aws
expects
and
in
order
to
convert
something
to
base64,
it's
relatively
easy.
B
B
Now,
of
course,
we
don't
want
to
have
anything
hard
coded
here.
This
is
why
we
have
defined
this
variable,
so
we
are
going
to
use
here,
gitlab
deploy
token
right,
and
additionally,
we
want
to
make
sure
that
we
don't
have
any
new
lines
or
anything
like
that.
In
our
token,
so
we're
going
to
pipe
them
again
to
another
command
and
this
command
will
remove
any
new
lines
that
exist
here.
So
so
this
n
here
with
the
backslash.
B
Additionally,
we
need
to
set
this
into
a
new
variable
that
we
can
replace,
so
I'm
gonna
put
here
a
dollar
sign
at
the
beginning,
I'm
going
to
put
this
between
parentheses
and
what
I'm
going
to
do
here,
I'm
going
to
export,
so
this
is
a
way
to
create
an
environment
variable
but
from
a
script,
and
the
name
will
be
deploy
token
right
and
equals
this
expression.
So
what
we
have
here
this
part
is
an
expression.
B
B
Well,
so
what
I'm
gonna
do
is
I'm
gonna
simply
disable
all
the
previous
jobs,
I'm
gonna
put
a
dot
before
them
so
that
they
don't
run
and
after
that,
I'm
gonna
commit
this
pipeline
and
let's
see
it
in
action,
and
it
seems
that
I'm
in
luck,
no
errors
while
running
this
job.
Let's
take
a
look
at
the
logs
to
see
if
we
have
everything-
and
indeed
it
seems
here
that
something
is
missing
right,
some
information
has
been
replaced.
B
B
So
here's
the
pipeline,
let's
double
check,
if
we
have
everything
correct
if
we
have
used
the
right
variables
so
gitlab
deploy
token.
That
should
be
the
name
of
the
variable
that
we
have
already
find
in
gitlab
as
a
variable.
So
that
seems
to
be
fine.
Deploy.
Token
is
exactly
that
what
we
have
used
in
the
file.
We
can
double
check
again.
The
file
you
see
here,
it's
exactly
deploy
token,
so
that
seems
to
be
working
well.
B
B
You
know
again
here
we
don't
see
it,
but
let's
take
a
look
at
the
commands
that
we
have
executed
to
see
if
there's
anything
suspicious
in
there.
So
what
did
we
do?
Well?
First
of
all,
we
have
just
started
the
script
here.
We
have
aws
cli
great.
We
are
installing
here
get
text,
so
that
seems
to
be
working,
don't
see
any
errors
up
to
this
point
and
then
we're
exporting
this
variable
right.
We're
running
this
command
this
expression
and
then,
if
we're
looking
here
at
line,
77
we're
seeing
here
td
command
not
found.
B
B
All
the
variables
have
been
replaced,
including
this
time
in
the
auth
file,
and
we
can
also
jump
into
s3
and
take
a
look
at
this
bucket
here,
we'll
be
able
to
see
here,
the
docker
run
file
and
the
auth
file
they
are
now
inside.
S3
docker
run
tells
essentially
contains
information
about
what
are
we
trying
to
deploy,
links
and
mentions
this
auth
file,
which
contains
authentication
information
about
how
to
connect
to
our
private
registry.
B
Now,
let's
continue
with
the
actual
deployment,
so
we
have
copied
here
the
docker1.aws.json
and
the
auth.json
file
and
they
are
in
this
s3
bucket
and
now
we
can
initialize
the
deployment
and
the
deployment
happens
with
the
aws
cli,
but
this
time
we'll
use
a
different
service.
So
the
service
to
which
we're
trying
to
deploy
is
elastic
beanstalk.
So
I'm
going
to
use
aws
elastic
bean
stock,
and
this
is
something
that
is
done
in
two
steps.
B
First
of
all,
we
have
to
create
an
application
version,
so
the
command
that
I'm
going
to
use
here
is
create
application
version
with
dashes
the
next
command
that
we
need
to
run
is
update
environment.
So
I'm
going
to
copy
this
and
I'm
going
to
write
here,
update
environment.
So
why
are
these
two
steps
necessary?
In
the
first
step?
B
B
In
our
case,
we
have
a
single
environment,
but
theoretically,
it's
possible
to
take
one
version
to
create
it
once
and
to
take
it
through
different
environments,
but
in
this
case
we
only
have
one
environment,
so
maybe
this
is
why
it
may
look
a
bit
weird
in
the
beginning,
but
these
are
the
steps
that
are
required
in
order
to
get
this
to
run
now.
Just
saying,
create
application
version
and
update
environment
is
not
actually
sufficient.
B
In
order
to
get
this
to
run,
we
need
to
specify
some
additional
parameters
and
the
first
parameter
is:
we
need
to
identify
the
application
right,
so
this
is
done
by
writing
here,
dash
dash
application
dash
name
and
if
we're
looking
here
inside
elastic
bean
stock,
you
will
see
here.
This
is
the
application
name,
I'm
going
to
copy
this
as
it
is
here
and
of
course
I
have
the
possibility
of
putting
it
here
directly,
like
application
name
like
this,
but
I
don't
want
to
do
that.
I
want
to
take
advantage
of
variables.
B
There
are
multiple
places
where
we
can
store
this,
but
I'm
just
gonna
put
them
here
inside
the
job
itself.
So
we
can
add
here
variables
block
and,
for
example,
I'm
gonna
call
this
app
underscore
name
column,
and
then
this
will
be
the
value
my
website.
So
whenever
I
need
to
use
this,
I'm
going
to
put
it
here,
so
application
name,
dollar
sign
and
I'm
going
to
reference
the
variable
now,
there's
something
you
need
to
pay
attention
here,
because
my
website
is
composed
of
two
strings.
So
there's
this
space
here
in
between.
B
B
So
in
order
to
get
around
this,
we
need
to
put
this
between
codes,
so
we'll
have
this
string
between
codes,
because
this
is
why
it
will
know.
Okay,
it
is
my
and
website
it
contains
also
the
space
and
the
word
after
this.
So
again,
I'm
gonna
also
put
the
variable
here
between
quotes
and
this
application
name
is
also
needed
for
the
update
environment
command.
So
I'm
going
to
copy
that
there
as
well.
B
We
already
have
an
application
version
here,
so
it
does
make
sense
to
use
that,
so
I'm
going
to
go
ahead
and
right
here,
dash
dash
version
dash
label.
Don't
worry
if
this
goes
on
a
new
line.
It's
just
the
way
it's
edited,
but
actually
the
command
is
on
a
single
line,
and
I'm
gonna
use
here
app
version,
and
this
here
for
update
environment.
Yes,
it
does
also
make
sense
to
specify
the
application
version
and
I'm
gonna
add
the
same
command
here.
The
same
parameter
version
label
to
this
command.
B
Now
also,
when
we
creating
this,
we
need
to
specify
somehow
this
file
right,
so
elastic
bean
stock
will
not
know
which
bucket
is
this
file.
How
can
I
read
it
and
everything
so?
For
that
reason
we
also
have
to
specify
that
and
we're
going
to
use
this
additional
parameter
source
dash
bundle,
and
this
will
allow
us
to
specify
an
s3
bucket
and
the
s3
bucket
will
equal
this
time.
B
B
They
don't
understand
when
they
are
specifying
these
additional
parameters.
Here
is
not,
for
example,
it's
not
equal
application,
name
equals
app
name,
it's
just
a
space
and
then
comes
the
value
here.
This
is
a
bit
different,
because
this
entire
thing,
this
entire
configuration
here-
is
a
value
that
will
be
read
later
on.
B
So
for
that
reason
here,
it's
okay
to
have
this
equals,
but
otherwise
there
are
no
equals
in
these
commands
all
right
so
to
create
the
application
version.
We
have
specified
application
name,
we
have
specified
the
version
label
and
additionally,
we
have
specified
this
source
bundle.
So
essentially,
where
is
the
file
that
tells
us
what
we
should
deploy?
This
is
almost
the
same
as
when
we
have
uploaded
that
file
manually,
but
with
that
we
have
also
triggered
the
deployment
automatically.
B
So
we
have
done
two
steps
in
one
step
here
we
are
doing
it
in
two
separate
steps,
so
the
next
part
is
after
creating.
This
version
is
to
update
the
environment,
so
we
have
here
the
application
name.
We
have
here
the
version
for
which
application
are
we
deploying
this?
Which
version?
Are
we
deploying?
B
The
next
step
would
be
to
also
specify
which
environment
are
we
updating?
I'm
gonna
write
here,
environment
dash
name,
and
we
also
need
another
variable
for
the
environment.
I'm
gonna
call
it
here,
app
and
name
you're,
free
to
name
them
as
you
wish,
and
again
I'm
going
to
go
here
to
elastic
bean
stock
and
I'm
going
to
copy
this.
I
just
want
to
make
sure
that
I
have
everything
exactly
as
it
is
in
elastic
bean
stock.
B
If
I
specify
something
else,
then
it's
not
the
same,
so
the
environment
name
will
be
here
and,
as
you
can
notice
here,
this
doesn't
have
any
spaces.
So
we
don't
need
to
put
this
value
between
codes
and
also
all
the
other
values
that
we
had
here.
There
are
no
spaces,
so
we
don't
need
to
put
any
quotes
there,
but
if
any
of
these
parameters
would
have
a
space
that
value
would
need
to
be
between
quotes.
B
However,
when
we
take
a
look
at
the
pipeline,
we'll
see
that
the
deployed
production
job
has
failed.
So,
let's
jump
into
the
logs,
try
to
understand
what
has
happened
and
why
this
job
failed.
You
can
see
here
the
commands
that
we
have
executed
so
copying
these
files
to
s3
still
works
so
no
problems
there.
The
last
command
that
was
executed
is
this
one,
so
elastic
beanstalk
create
application
version.
So
there's
a
good
chance
that
this
command
is
responsible
for
whatever
error
we're
getting
here
and
then
we
need
to
look
into
the
logs
and
see.
B
What
is
the
error?
And
we
can
see
here
it
says
something
access
denied.
Essentially
it's
telling
that
our
user,
which
is
the
gitlab
user
that
we
have
created.
If
you
remember,
we
have
created
this
user
with
programmatic
access
is
not
authorized
to
perform
some
action,
so
create
application
version.
If
you
remember,
we
have
selected
that
the
user
is
allowed
to
work
with
s3
resources
right,
so
uploading
files
deleting
files-
things
like
that
with
s3
that
works,
but
we
haven't
authorized
our
user
to
work
with
elastic
bean
stock.
B
So
we
need
to
change
that
so
from
the
aws
console.
Let's
go
ahead
and
open
the
im
service
for
identity
management,
we'll
open
up
our
user.
You
see
here.
This
is
the
username
gitlab
and
what
we
can
do
here
is
essentially
to
attach
additional
policies.
So
we
have
here
this
amazon
s3
full
access,
so
that
works.
B
Now
I'm
not
going
to
go
into
this
policies
in
very
detail,
we're
just
interested
in
getting
this
to
run.
But,
of
course,
if
you
would
use
something
like
this
in
production,
you
would
need
to
be
very
careful
about
what
each
user
is
allowed
to
do.
So
just
keep
that
in
mind.
Just
using
this
very
generous
policies
in
production
is
typically
not
a
good
idea.
B
So
I'm
gonna
add
these
permissions,
then,
and
now
we'll
see
that
our
user
now
has
this
additional
permission
here.
So
we
can
now
work
with
elastic
beanstalk,
so
going
back
here
to
the
logs
instead
of
re-running
the
entire
pipeline.
We
can
just
go
to
this
job
and
hit
this
retry
button
and
it
will
retry
the
same
job.
We
haven't
changed
any
files
and
dynamically.
This
policy
should
now
be
applied
to
the
user,
and
hopefully
this
job
will
work.
B
B
So
it's
going
to
tell
us
again
like
the
application
name,
which
version
we
have
which
bucket
we're
using,
which
is
the
name
of
the
file
and
so
on.
It
also
starting
to
process
this
and
the
next
thing.
What
we're
getting
is
the
update
environment
so
that
work
without
any
issues.
It's
going
to
tell
us
again
what
is
the
environment
name,
so
we
can
take
a
look
at
that
application
named
version
and
also
some
technical
details
about
this.
B
We
can
take
a
look
back
into
the
aws
console
and
then
look
here
into
the
elastic
bin
stock
service
to
see
what's
going
on
and
we'll
be
able
to
see
here,
running
versions
is
60..
I
can
click
here
on
the
environment,
just
to
make
sure
that
we
indeed
have
everything
the
health
is
okay,
so
we
can
also
go
ahead
and
click
on
this
url,
and
this
will
open
up
our
website.
So
it
does
seem
to
work
very
well.
B
So
now
we
have
manually
tested
that
the
deployment
has
been
successful,
but
how
about
that?
We
check
in
our
pipeline
that
the
deployment
has
been
successful
and
we
can
use
the
exact
same
approach
that
we
have
used
so
far.
I'm
gonna
jump
back
into
the
pipeline
and
here
inside
the
deployed
production
job.
Essentially,
what
we
want
to
do
is
to
use
this
curl
command
so
should
be
pretty
similar
to
what
we
have
here
when
we're
testing
the
docker
image,
I'm
gonna
add
it
here
to
a
new
line.
Of
course.
B
We
also
need
to
get
the
address
itself
of
the
application
of
the
environment,
and,
if
you
remember,
we
had
something
for
that
already.
We
just
need
to
update
the
url
for
the
application,
so
I'm
going
to
simply
copy
this
url
here
and
from
gitlab
I'm
going
to
go
to
deployments
environments
and
for
the
production
environment,
I'm
going
to
go
ahead
and
change
some
settings
and
we're
no
longer
using
the
s3
url
we're
using
this
one
and
remove
here
the
forward
slash.
B
So
this
will
be
my
external
url
for
this
environment,
and
what
we
want
to
use
here
is,
of
course,
the
variable
that
will
get
us
this
environment
and
from
the
predefined
variables.
Probably
remember:
we
have
used
this
in
the
past
ci
environment,
name,
slug
url.
We
actually
want
the
url,
so
I'm
going
to
copy
this
get
here
into
the
pipeline
configuration
and
instead
of
website
can
also
replace
http,
because
I
don't
need
that
anymore.
B
B
Aws
needs
just
a
few
seconds
to
actually
do
this
deployment
to
put
the
new
version
on
the
environment.
This
is
not
instant,
but
the
connects
command
will
run
immediately
after
we
have
essentially
triggered
this
update
and
that
environment
may
not
be
ready
or
may
still
have
the
older
version.
So
for
that
reason,
this
curl
here
will
fail.
So
we'll
not
get
this
response.
The
deployment
cannot
be
verified
at
this
point
that
it
has
been
successful
or
not.
B
So
what
we
need
to
do
here
is
to
wait
a
bit,
so
what
we
can
do
is,
of
course,
to
use
something
like
sleep
and
wait
for
like
10
seconds
or
something
like
that,
but
in
aws
there's
a
better
way
to
do
that
when
we're
using
the
aws
cli,
we
have
a
tool
which
is
called
weight,
so
weight
is
an
option.
It
is
for
various
services
that
are
at
aws,
including
for
elastic
bean
stock.
So
we
can
right
here
elastic
bean
stock
weight
and
then
what
are
we
waiting
for?
B
We
are
waiting
for
this
environment
to
be
updated,
so
I'm
going
to
write
here,
environment
dash,
updated
and
then
we
need
to
specify
the
application
name,
the
environment
name
and
the
version
label
right.
So
essentially
everything
that
we
had
here
on
the
previous
command,
I'm
gonna
simply
copy,
and
I'm
gonna
add
it
here
to
the
new
line
and
this
command
will
do
the
following.
It
will
essentially
in
the
background
it
will
check
with
aws
hey.
Are
you
done
updating
that
environment?
B
No?
Not
yet.
I
need
some
time.
Okay,
wait
a
bit
and
then
we'll
try
again
hey.
Are
you
done
updating
that
environment?
Okay,
I'm
done
good
and
then
we
can
stop
waiting
and
then
the
next
command
the
curl
command
can
run,
and
then
we
can
check
if
indeed
the
correct
version
has
been
deployed
and
if
our
environment
is
working
properly,
so
I'm
going
to
go
ahead
and
commit
these
changes
and
we'll
let
the
entire
pipeline
run
and
see
how
this
goes
and
the
pipeline
is
still
successful.
B
So
we
can
take
a
look
into
the
deploy
to
production
job
and
see
what
exactly
happened
here
and
you'll
be
able
to
see
here
that
this
command
is
executed
and
after
this,
the
next
command
with
curl
is
also
executed
and
it
passes
without
any
issues
you
will
see
here,
version
61
has
been
deployed.
This
is
exactly
also
the
version
label
that
we
have
here
defined.
So
this
again
confirms
that
the
version
that
we
wanted
to
deploy
has
actually
landed
on
the
environment
where
we
wanted
to
have
it.
B
So
that's
about
it
in
terms
of
deploying
to
elastic
beanstalk.
So
just
to
recap,
we
have
gone
through
all
the
stages
and
we
have
started
by
initially
building
our
code,
whatever
we
have
here,
compiling
it
building
it
running
some
tests
and
then
publishing
this
as
artifacts,
and
then
we
have
created
a
docker
image.
Essentially,
we
have
created
an
application.
B
We
have
tested
that
application
and
then,
of
course
we
have
really
a
simple
pipeline
here.
We
didn't
went
through
any
other
stages.
We
deployed
directly
to
production,
but
the
principles
that
I've
shown
you
here
can
be
used
for
similar
projects
and,
of
course,
based
on
all
the
other
information
that
I've
shown
you
throughout
the
course.
B
Since
now
we
are
coming
towards
the
end
of
the
course,
I
thought
it
would
be
a
good
idea
for
a
final
assignment,
and
what
I
have
here
is
a
project
which
will
document
who
has
completed
this
course.
So
what
you
have
to
do
is
to
check
the
course
notes
and
in
the
course
notes,
you
will
find
the
link
to
this
repository
and
go
ahead
and
click
here
on
request
access
and
in
a
few
hours,
probably
you
receive
access
to
this
repository
and
you
will
be
able
to
make
changes
to
it.
B
B
So
once
you
have
access
to
this,
you
will
no
longer
see
this
part
with
requesting
access
and
you
can
open
the
web
id
and
you
will
be
not
asked
to
fork
this
project.
That's
the
main
difference,
and
then
you
can
go
ahead
and
change
the
files.
The
files
that
we
want
to
change
are
located
here
in
source
and
the
file
that
contains
the
code
is
this
app.js
and
here
there
will
be
a
table,
and
I
invite
you
to
add
your
name
and
other
information
to
this
table
so,
for
example,
I've
added
here
my
name.
B
I
had
it
here
my
username
for
gitlab,
but
also
my
country
of
origin
and
also
message
to
the
entire
world,
and
I'm
gonna
submit
this
as
a
merge
request,
and
I
invite
you
to
do
the
same.
So
I'm
going
to
go
ahead
here
commit
this,
and
I
cannot
commit
directly
into
the
main
branch.
So
I
have
to
go
through
the
path
of
creating
a
merge
request.
B
Once
you
have
access
to
this
project,
you
will
be
able
to
see
any
other
merge
requests,
and
I
invite
you
to
take
a
look
at
them
to
see
what
other
people
have
changed
to
make
sure
that
everything
is
working
properly
and
if
someone
breaks
the
pipeline
in
their
own
branch.
Maybe
you
can
give
people
some
tips
in
regards
to
what
they
did
wrong
and
what
didn't
work
so
well
essentially
be
part
of
this
review
process.
B
Try
to
understand
how
to
collaborate
on
this
project
and,
of
course,
once
your
merge
request
gets
reviewed,
it
will
be
merged
into
the
main
branch
and
then
you
will
be
able
to
see
your
name
appearing
on
a
web
page,
so
I
think
that's
kind
of
a
nice
and
an
interactive
way
of
essentially
concluding
this
course
almost
and
so
yeah.
I
hope
you
will
do
this
along
in
terms
of
editing.
B
What
I
highly
recommend
is
that
you
don't
just
add
your
name
at
the
end,
because
that's
the
highest
chance
that
you
will
run
into
complex
so
when
you're
trying
to
make
changes,
try
to
put
your
name
somewhere
in
the
middle
or
something
like
that
between
others,
try
to
keep
the
indentation
and
everything
so
that
it
looks
nice
but
yeah.
That's
my
advice
to
you
so
see
you
even
after
this
course,
I'm
gonna
collaborate
more
inside
the
merge
request.
Try
to
play
more
with
gitlab,
with
pipelines,
see
how
it
works
and
yeah.
B
All
right
you
did
it.
This
is
the
end
of
the
course,
but
don't
go
away
yet
I
still
have
some
valuable
tips
for
you.
First
of
all,
I
want
to
give
you
a
final
reminder
to
terminate
any
aws
services
you
have
created
so
that
you
don't
encounter
any
unexpected
costs.
We
have
accomplished
so
many
things
in
a
very
short
amount
of
time.
I
know
this
was
a
lot
to
take
in,
but
I
hope
it
was
useful
and
that
this
has
opened
your
appetite
for
learning
more
about
devops,
gitlab
and
aws.
B
If
you
enjoy
this
content,
you
could
support
me
in
creating
more
courses
like
this
one.
By
going
to
my
youtube,
channel
and
subscribing
link
in
the
video
description.
Thank
you
very
very
much,
but
there's
also
so
much
more
to
learn.
If
you
found
it
hard
to
work
with
cli
commands,
I
do
recommend
learning
about
unix
utility
commands
and
bash.
There
are
also
other
gitlab
features
worth
exploring.
B
If
you
like,
working
when
deploying
docker
containers,
you
may
also
want
to
learn
about
kubernetes
for
all
the
topics
mentioned
above
and
anything
else
I
forgot
to
mention,
you
will
find
links
in
the
course
notes.
If
you
enjoy
my
teaching
style,
and
you
want
to
take
a
more
advanced
gitlab
course
go
to
vdespa.com
and
check
out
the
courses
that
I'm
offering
if
you
are
unsure,
which
course
is
right
for
you
just
send
me
a
message
on
social
media,
I'm
more
than
happy
to
help.