►
From YouTube: Preview Environments on GitLab with ⛅🌱 Cloud Seed
Description
⛅🌱 https://hello.cloudseed.app
Cloud Seed is an open-source program lead by GitLab Incubation Engineering in collaboration with Google Cloud.
Deploying web application (and related workloads) from GitLab to major cloud providers should be trivial.
Cloud Seed makes it ridiculously simple and intuitive to consume appropriate Google Cloud services within GitLab.
A
Hey
good
morning,
everybody,
my
name
is
shri,
and
I'm
going
to
talk
about
preview
environments
with
gitlab
using
cloud
seed.
Gitlab
is
the
one
devops
platform
teams
use
it
for
their
entire
devops
lifecycle.
That
is
right
from
project
planning
all
the
way
to
the
development,
the
ci
automation,
deployments,
security
and
so
much
more
cloud.
Seed
itself
enables
preview
environments
using
gitlab.
A
A
A
A
This
is
my
starting
point
so
assume
your
team
has
some
kind
of
web
application.
It
doesn't
matter
what,
in
this
example,
I'm
using
node
with
gitlab.
What
you
can
do
is
you
can
navigate
to
the
infrastructure,
google
cloud
page
and
you
can
set
up
the
deployment
credentials
by
generating
service
accounts.
A
A
A
What
is
cloud
run?
The
tagline
here
is
container
to
production
in
seconds
cloud
run.
Is
the
deployment
target
that
we're
going
to
use
for
this
example
and
all
the
preview
environments
that
we
create
are
going
to
get
created
as
cloud
run
services?
So
we
deploy
to
cloud
run
cloud
run.
Lets
you
deploy
containerized
applications,
so
here
are
some
examples
of
the
languages
they
support,
go
python,
java,
node,
etc,
and
it's
a
fully
managed
serverless
program.
So
my
team-
or
I
don't
have
to
set
up
a
cluster
connect,
the
cluster
maintain
the
cluster.
A
Nothing
of
that
sort.
Google
takes
care
of
it.
Another
key
feature
is
that
it's
they've
got
a
tremendous
free
tier
and
you
can
find
that
over
here.
I
believe,
if
you
follow
this
link,
you
can
figure
out
on
the
pricing
and
costs
and
how
that
works,
but
they
have
a
tremendous
free
tier
and
they
don't
charge
for
stale
environments.
A
So,
for
example,
you
have
a
service
that
is
no
longer
being
used.
You
won't
be
built
for
that
chances
are
if
it
is
a.
If
it
is
a
review
environment,
you
will
not
be
built
in
the
first
place,
because
you'll
be
well
within
the
free
tier
anyway.
That's
that
here's
what's
happened.
A
While
I
was
explaining
cloud
seat,
we
have
a
pipeline,
that's
running
with
one
job
that
says
deploy
to
cloud
run.
Let's
have
a
look
at
the
job.
A
It's
running.
Okay,
now
I'm
going
to
just
play
the
role
of
a
product
owner,
and
I
will
say
that
this
web
application
I'll
create
a
new
issue.
I
will
say
this:
application
should
say
the
words
hello
world.
A
A
Now
imagine
a
scenario
where
I'm
a
team
of
several
people
and
several
of
these
people
will
pick
up
different
issues.
So
here
we've
got
two
issues,
so
you
can
imagine
that
two
developers
will
pick
up
these
issues
and
work
on
them
in
parallel
right
when
that
happens,
let's
have
a
look
at
the
mr.
So
when
that
happens,
we
want
to.
We
want
to
spin
up
two
preview
environments
for
the
work
done
in
both
of
these
issues,
so
both
of
these
issues
should
have
preview
environments
of
their
own.
A
My
mr,
has
gotten
merged.
So
if
I
go
to
my
main
branch,
I
can
see
that
there's
a
gitlab
ci
aml
file
that
has
got
the
cloud
run
deployment
pipeline,
lovely,
okay.
What
I
will
do
now
is,
I
will
play
the
role
of
the
two
developers.
So
first
I'll
play
developer
number
one
who
should
make
the
web
application
say:
foobar
I'll,
follow
the
standard
gitlab
flow
I'll,
create
an
mr
which
creates
a
branch
for
me
and.
A
So
I
spin
up
this
web
ide
and
let's
have
a
look
at
this
application.
I've
got
a
view.
View
looks
good
welcome
to
title
lovely
public
bin.
All
right.
I
have
a
fair
idea
for
this
application
does.
So
if
I
go
to
routes,
I
will
see
it
says
express.
No,
no,
I
don't
want
it
to
say
express
my
product
owner
wants
me
to
say
foobar.
So
I
put
the
text
foobar
and
I
create
a
comment
that
says
say:
foobar.
A
We
have
developer
number
two
who
picks
up
another
issue
and
they
are
also
working
in
the
gitlab
flow,
so
they
create
an
mr,
where
it
spins
up
a
feature
branch
specifically
for
this
piece
of
work
and
within
that
feature
branch
they
also
open
the
web
ide
and
they
start
working
now.
Of
course,
I'm
using
the
web
ide
for
the
demo.
You
could
use
any
kind
of
ide
that
you
prefer
web
id
is
just
convenient
anyway.
This
is
developer
number
two
and
they
must
say
hello
world.
So
they
update
the
text
to
say
hello,
world.
A
A
Meanwhile,
what
we
have
right
now
is,
we
have
the
we
have
the
environment.
I
believe
we
have
no
environment
right
now
or
we
have
actually
three
environments.
That's
good
and
we've
got
pipelines
running
on
all
three
of
them.
A
So
this
was,
we
have
a
stopped
environment.
This
was
when
we
introduced
the
pipeline
in
the
first
place,
so
you
can
see
that
this
is
this
environment
has
got
a
web
application
running,
saying,
welcome
to
express
and
three
and
we've
got
three,
let's
say
available:
environments
which
have
got
let's
say,
which
represent
the
environments,
represent
each
branch,
so
the
master
branch,
which
is
which
is
not
modified.
The
main
branch
which
has
not
been
modified
that
will
say,
welcome
to
express
that's
expected.
A
That's
one
environment,
but
now
both
of
these
mrs,
have
got
pipelines
executing
so
the
first
one
was
where
developer
one
worked
upon
the
application
and
said
fubar
they've
got
a
pipeline
running,
and
the
second
is
where
the
developer
two
worked
on
the
web
application
and
made
another
change
where
they
said:
welcome
to
hello,
world
or
say
hello
world.
Something
like
that
and
that's
got
a
pipeline
running
as
well.
A
A
Seems
to
work
so
it
contains
the
specific
changes
made
in
the
fubar
branch
and
shows
them
to
me.
Let's
say
I'm
the
qa
person.
Now
I
want
to
review.
I
have
this
environment
right
here
and
another
place.
You
will
find
something
of
this
button.
Is
the
merge
request
view?
So
if
we
go
to
the
merge
request
view
and
if
I
go
to
foobar,
you
will
see
that
this
view
application
so
merge.
Request
view
is
important,
because
this
is
where
the
code
reviewers
and
the
team
will
be
working
on.
A
So
they
can
review
the
changes
they
can
leave
comments,
but
they
can
also
write
in
this
very
same
view,
check
out
the
preview
application
that
says
foobar.
So
we
have
a
fubar
preview
application.
We
have
another.
Oh
we
have
another
pipeline
that
has
succeeded.
So
if
I
go
to
merge,
request
number
three
that
says
hello
world,
it
also
has
a
view,
application,
lovely
and
if
I
refresh
the
environment,
so
I
don't
even
need
to
refresh
excellent-
and
I
already
see
the
environment
over
here
to
say
hello
world.
A
So
there
you
have
it
with
a
simple
pipeline.
We
are
spinning
up
environments
per
branch
so,
as
and
when
updates
are
pushed
onto
this
branch.
These
environments
get
updated
they're
available
in
the
merge
request,
view
for
team
members
to
review
and
pass
feedback
and
once
it's
merged
they
automatically
get
stopped.
A
And,
finally,
because
the
deployment
target
is
google
cloud
run,
it's
immensely
cost
effective
you're,
not
spending
any
money
in
having
these
low
low
traffic
or
low
volume
services
running
again,
I
cannot
speak
for
google
cloud
run,
but
based
on
what
they
know
what
I
know
they
have
incredible
pricing
with
a
free
tier
and
you
don't
have
to
delete
any
environment
if
it
is
not
being
used.
You
don't
get
built
for
it.
That
being
said,
I'm
going
to
give
a
disclaimer.
Please
check
out
the
google
cloud
run.
A
Pricing
yourself,
don't
take
my
word
for
it,
but
this
is
just
my
analysis
of
it
and
there
you
have
it.
We
have
preview
environments
running
with
cloud
seed,
get
lab
project.
Your
project
in
gitlab
gets
deployed
to
cloud
run
based
on
the
changes
that
you
make.
That's
all
for
this
talk.
Thank
you.
So
much.