►
From YouTube: Ops Cross Stage ThinkBig - 2021-06-10
Description
Our teams discuss Environments
A
A
Environments
is
a
topic
that
has,
at
least
for
me
previously
been
somewhat
confusing,
because
at
gitlab
we
often
use
the
word
environment
and
specifically
deployment
interchangeably,
and
we
have
several
pages,
that's
related
to
the
environment.
We
have
the
environment
dashboard,
we
have
a
environments
page
and
within
environments.
There's
also
deployments-
and
I
figured
this
would
be
a
great
topic
to
talk
about
and
to
try
to
collectively
get
everyone's
thoughts
on
what
environments
could
possibly
be
for
our
customers
and
my
that
one.
A
Some
of
the
outcomes
I'm
specifically
looking
forward
to
today
is
to
get
a
good
understanding
of
what
environments
at
gitlab
today
is
all
about,
and
then
also
sorry,
my
headphones
tell
me
I'm
out
of
battery
also
that
what
what
environments
could
potentially
become
going
forward,
and
so
with
that,
I
love
to
kick
it
off
to
the
entire
group.
Let's
first
talk
about
what
environment
is
today
at
gitlab.
A
B
Yeah,
so
what
they
are
today,
you
know,
I
think
that
we
rightfully
like
the,
if
I
think
about
there's
a
little
bit
of
like
we
built
environments
based
on
the
way
that
our
product
evolved
and
our
product
evolved
from
being
a
ci
cd
tool
or
ci
tool.
That
became
used
for
useful
for
cicd,
so
we've
kind
of
built
the
constructs
for
how
to
think
about
environments
into
that
deployment
process
itself,
as
defined
in
your
ci
demo.
B
So
they're
like
the
representation
lots
of
the
representation
of
the
environment,
is
you
define
it
as
part
of
a
job,
a
specific
deployment
job,
and
that
has
huge
benefits,
because
it
gave
developers
immediate
control
for
being
able
to
create
deployments
and
environments
on
their
own
in
their
specific
project?
And
what
else
so?
And
then
we
represent
those
environments
in
various
places,
whether
that's
in
the
the
environments
page,
where
we
surface
different
types
of
environments,
including
production
or
staging
or
ephemeral
environments.
B
And
then
we
even
like
with
our
kubernetes
integration,
extend
that
to
show
what's
going
on
with
that
environment,
whether
that's
like
click
outs
to
the
metrics
or
you
can
look
into
the
logs.
I
think
at
some
point
we
also
had
the
like.
You
can
coupe
ctl
into
that
namespace
on
your
kubernetes
cluster.
You
can
see
how
the
pods
are
are
deploying
and
in
my
mind
that
view
of
like
here's,
an
environment
I
can
understand.
What's
going
on
with
it,
I
can
look
at
the
environment.
B
C
D
And
another
thing
that
I
like
to
add
is
that
when
jackie
and
I
did
research
for
the
now
defunct
release
management
team,
we
learned
that
people
don't
really
know
what
environments
are
about
like,
even
when
you
call
environments
with
git
lab
right.
It's
it's
this
construct.
As
can
you
say
that
it's
so
yeah
related
to
deployments
that,
because
you
don't
really
have
that
centralized
place,
and
you
don't
think
of
your
deployments,
your
environments
as
an
application.
D
D
So
there
was,
there
were
different
issues,
so,
for
example,
of
course,
we
can
talk
about
the
findability
right
or
when
you
are
in
the
context
of
a
merger
class.
For
example,
you
only
look
at
that
specific
deployment
or
environment,
but
mostly
what
we
learned
is
that
for
customers
that
they,
I
don't
know
they
have
multiple
groups
or
hundreds
of
projects
within
a
group.
D
So
that
was,
I
think
that
was
the
biggest
learning
for
us
and
it
started
relating
to
bigger
things,
for
example
the
door
for
metrics
right
and
getting
all
the
data
getting
everything
connected
to
one
place
when
we
started
talking
about
enterprise
management,
but
people
had
that
desire
to
manage
their
applications
and
not
one
isolated
deployment.
For
that
one
specific
target
branch,
they
want
to
look
at
everything
that
is
in
production
that
goes
to
to
to
a
higher
level
and
because
they
don't
know
how
to
do
that.
D
With
gitlab
they
just
don't
use
environments
and
they
don't
deploy
with
gitlab.
Of
course,
there's
more
to
it.
So
I'm
going
to
add
here
there's
a
recording
of
a
jackie
explaining
the
opportunity
canvas,
but
that
that
was
the
the
the
next
big
thing
for
us
in
release
management
that
was
supposed
to
be
environments
and
deployments
at
the
group
level.
B
B
B
So
this
is
running
on
a
kubernetes
cluster,
so
it
gives
us
the
pods.
You
can
like
jump
out.
So
you
navigated
to
this.
By
going
to
ops,
and
then
environments
chose
the
environments
it
folded
in
all
the
review,
which
are
like
the
ephemeral
environments
that
are
running
for
review,
apps
here
and
then
yeah.
You
can
see
how
many
pods
are
deployed
for
each
environment,
production
and
staging,
and
then
you
can
like
run
certain
deploy
jobs.
B
If
you
want,
like
oh
there's,
a
deploy
job
that
you
might
want
to
regularly
manually
run,
you
can
kind
of
store
those
here.
There's
some
way
to
annotate
that
in
your
yaml
you
can
jump
to
the
live
reference
url.
You
can
open
the
terminal
for
cube
ctl.
You
can
also
like
redeploy
the
most
recent
stable
branch
commit
or
stop
the
environment
entirely,
but
the
interesting
thing,
especially
when
we
were
talking
about
group
level
environments,
is
that
these
are
all
under
a
gitlab
services
project
that
only
runs
one
kubernetes
cluster
for
all
the
services.
I
don't.
B
Maybe
I
don't
have
access
to
the
subgroups,
but
maybe
they
don't
have
them,
but
I
think
there
are
some
other
projects
like
license
and
customer
dot
that
are
in
here
that
I
just
don't
have
access
to,
but
this
is
the
only
way
that
you
can
see
like.
Oh
this
is
one
production
cluster.
That's
serving
those
multiple
projects
underneath
and
all
I
get
is
this
cluster
saying
service
prod,
and
I
can
probably
click
into
this
and
see
some
view
of
the
different
environments
underneath.
B
D
Yeah,
which
is
another
thing
that
we
learned,
that
people
don't
use
this
environment
dashboard
at
all.
It
doesn't
give
you
any
information.
You
cannot
act
on
anything,
and
that
was
also
part
of
our
next
next
big
thing
is
to
instead
of
using
this
environment
dashboards,
make
that
I
think
danielle
is
daniel.
Here,
the
newfound
school
yeah
daniel.
A
So
you
can
add
any
any
any
projects
that
you
have
access
to
and
these
projects
will
show
the
environment
that
they
they
have,
and
so,
if
the
projects
are
indeed
related,
you'll
see
that
oh
yeah,
these
are
all
in
production.
But
you
have
to
manually
work
that
out
in
your
brain
that
they're
connected
in
this
way,
but
if
they're
completely
disparate
projects-
and
they
all
are
in
production
environments,
these
production
environments
are
not
the
same
environments.
C
Actually,
environments
are
pretty
tricky
because,
like
from
from
an
sre
perspective,
for
example,
production
could
mean
three
different
clusters
in
three
geo
zones
and
staging
are
another
three
clusters
in
in
a
single
geo
zone.
Why,
from
the
developer's
point
of
view,
production
is
actually
the
version
of
your
app
that
was
deployed
into
those
three
clusters
and
and
to
show
this
that
that's
actually,
I
think
it's
it's
pretty
complicated
to
to
figure
out,
which
is
the
light
right
level
of
abstraction
right
right
level
of
what?
What
do
we
call
production
in
this
regard?.
B
There
are
also
now,
as
we
have
as
people
more
people
are
adopting
infrastructure
as
code
there's,
this
connection
between
where
the
infrastructure
for
that
environment
is
defined
and
where
the
application
state
for
what
applications
are
running
in
that
are
defined,
and
it's
really
hard
to
make
a
connection
between
those
two
think
about
if
you're
running
a
kubernetes
cluster
that
has
four
different
services
they're
all
running
in
their
own
name,
spaces
in
production.
But
you
kind
of
want
to
be
able
to
quickly
see
as
the
operator
what
version
of
those
are
running.
B
What
was
the
recent
commit
for
each
one
of
those?
It's
really
hard
to
distill,
that
down
and
as
a
developer,
you
want
to
know
what
type
of
infrastructure
is
being
run
in
order
for
me
to
make
sure
that,
like
if
I'm
troubleshooting
a
code
problem,
I
understand
what
the
configuration
of
that
infrastructure
is.
So
there's
this
connection
missing
between
where
the
infrastructure
is
defined.
D
And
nathan,
maybe
you
remember
some
of
the
things
that
we
were,
I'm
not
sure
if
you
worked
on
it
with
audits
around
sharing
the
environments
across
projects.
I
remember
at
least
that
we
work
a
few
months
ago
on
cleaning
up
that
view
or
yeah
building
that
connection,
of
course,
not
an
infrastructure
sense,
but
improving
what
we
have
today
for
environments.
Do
you
remember
or
what
we've
done
then
or
a
few.
E
Yeah,
I
think
our
initial
idea
was
to
create
a
a
group
level
environments
page.
That
would
then
group
them
based
on
either
the
url
or
maybe
we
were
thinking
a
separate
grouping
field.
We
were
going
to
add,
because
our
assumption
was
that
if
you
have
different
environments
that
all
point
to
the
same
url
really
those
are
all
part
of
the
same
environment.
So
that's
how
we
were
going
to
group
it
just
for
an
mvc
and
that
would
at
least
give
you
that
kind
of
group
level
grouping.
C
D
You
could
go
into
your
project
level
and
just
dig
for
the
information
other
review,
the
testing
et
cetera,
et
cetera.
But
that
was
a
much
bigger
problem
that
we
had
to
solve
and
we
didn't
move
that
much
further.
But
we
have
we
had
three
teams.
There
was
visibility
into
deployments
and
environments
across
projects
that
are
shared
within
groups
in
project
groups
in
different
projects,
administration
of
those.
So
managing
permissions
variables
and
everything
so,
for
example,
deploy
freezes.
D
D
We
have
research,
we
have
prototypes
to
have
issues
and
I
think
with
environments,
I'm
talking
a
lot,
because
the
environment
is
it's
deconstruct,
like
kenny
said
in
the
beginning
that
it's
not
just
that
one
url
and
that
one
thing
that
you
see
at
the
end,
we
have
to
put
a,
I
think,
break
the
problem
down,
but
also
looking
to
the
existing
research
because
yeah
we
talked
to,
I
think,
40
something
customers
last
year
about
this
and
that's
and
that's
what
the
vision
of
release
management
was.
Part
of
the
division
was
related
to.
G
What
do
you
mean?
I
like
that
sorry
go
ahead,
so
we
have,
and
this
kind
of
goes
for
the
kubernetes
clusters
as
well
right.
You
can
share
a
kubernetes
cluster
from
a
group
level
or
or
even
like
an
instance
instance-wide
level
and
the
cluster
itself
kind
of
defines
what
the
environment
is
not
not
entirely
or
specifically,
because
I
think
a
cluster
can
run
several
several
different
kind
of
sets
of
environments
at
once,
but
we
have
these
runners
and
the
runners
can
be
tagged
and
organized
and
shared
between
between
groups.
G
They
don't
have
quite
as
much
observability,
because
they
don't
really
need
the
same
level
of
observability,
but
at
the
same
time
you
can,
as
a
project,
opt
into
using
shared
resources
or
shared
runners
across
groups
and
shared
runners
across
instances
as
well.
So
that
kind
of
is
my
inspiration
for
looking
at
environments.
This
way,
I'm.
C
Just
trying
to
understand
so
you
say
something
like
that
that
there
is,
you
would
add
the
way
to
define
environment
at
the
instance
or
group
level,
and
then
the
project
just
says
that
I'm
I'm
using
this
environment
or
because
now
it's
the
other
way
around
that
you
just
defined
the
project.
That's
what
you
mean
yeah.
B
B
Like
the
project
could
say,
oh
deploy
to
an
environment
with
some
other
runner
like
these
tags,
and
then
it
finds
the
right
environment
to
deploy
to
the
interesting
thing
to
me
is
that,
unlike
runners,
runners
are
like
their
own
constructs,
but
I'm
going
to
go
back
to
environments
are
typically
defined.
As
a
project
I
mean
even
our
kubernetes
management
is
starting
to
say
this.
Is
the
kubernetes
cluster
configuration
project
that
you're
going
to
use?
So
you
could
almost
say
you
don't
have
to
create
a
new
construct,
you're,
just
drawing
a
connection
between
two
different
projects.
B
I
don't
know
if
we
have
yes,
an
example
of
how
we
like
designate
a
project
as
a
special
project
within
a
group,
for
example,
is
the
there's
some
like
trickle-down
things,
I'm
trying
to
think?
Maybe
insights
is
one
of
these,
where
in
insights,
when
you
want
to
create
dashboards,
if
you
want
group
level
insights,
you
say
which
project
is
the
designated
group
level
insights
right
and
that
project
then,
is
the
source
for
displaying
the
insights
dashboards
at
a
group
level.
You
could
think
of
a
similar
construct
here.
We're
like
you
need
to
designate.
H
So
one
thing:
that's
not
clear
for
me
in
terms
of
group
group
level,
environments
is,
let's
say
you
have
in
case
like
we
have.
Let's
say
we
have
this
feature
today
right
we
have
a
group
level
environment
called
production.
Does
that
mean
that
every
project
within
that
group
deploys
to
that
environment
in
terms
of
like?
Is
this
huge
box
and
a
bunch
of
different
applications
are
are
deploying
to
that
box
or
it's
something
else.
B
I
really
liked
what
andrew
was
saying,
which
is,
if
you
think,
of
the
runner
construct
you
can
attach
as
many
different
runner
types
as
you
want
to
the
group,
and
then
the
individual
project
is
determining
which
using
tags,
which
runner
do.
I
want
to
run
this
job
on.
You
could
think
of
something
similar
at
the
group
level
for
environments
where
it's
not.
Every
project
has
to
deploy
to
this
environment,
but
the
projects
choose.
C
I
think
the
question
is
more
tricky
than
that,
because
just
what
you
mentioned
as
well,
that
it
might
be
that
at
the
group
level
there
is
a
production
cluster
defined,
and
actually
I
want
to
deploy
in
a
specific
namespace
of
that
cluster
then
do
I
deploy.
Do
I
target
that
environment?
That
is
the
cluster,
or
do
I
say
that
there
is
that
that
my
environment,
my
production,
is
part
of
that
environment,
but
to
never
just
give
an
answer
to
the
question
itself,
I
would
say
they
would
we
would
target
that
environment
in
a
sense.
H
C
D
So
that's
why
people
are
very
unlikely
to
adopt
it.
Since
you
know
they
want
to
control
it,
they
want
to
just
have
that
visibility
without
thinking
too
much
about
it.
All
these
different
things
setting
up
at
the
group
level,
project
level,
different
names,
tags,
etc,
etc,
but
yeah,
it's
no
daniel,
it's
more
complicated
than
what
it
says
and
it's
a
different
thing
too.
C
So
does
this
involve
as
well
something
like
that?
That
would
be
that
sasha
is
not
the
right
person
to
set
up
the
environment
and
then,
like
our
sres,
they
don't
mind
speaking
about
g-pro,
then
g-staging.
So
they
are.
That's!
That's
what
you
mean
that
that's
why
we
are
kind
of
mis-targeted
environments,
because
sasha
doesn't
want
to
set
up
an
environment
while
there
would
be
other
people
like
devon.
C
A
C
Yeah
they
don't
care
about
environments
that
came
out
from
my
interviews
as
well,
like
my
favorite
quote
around
these
lines
is
that
the
engineers
come
to
us
just.
I
spoke
with
the
platform
engineer
the
engineers
come
to
us
to
ask
questions
about
the
the
infrastructure
they
deployed
to
only
when
there's
an
error
yeah.
Otherwise
they
don't
don't
even
know
about
it.
B
Cool
kenny,
you
were
gonna
yeah
go
ahead.
I
actually
want
to
go
back
to
something
ayanna
said,
which
was
when
the
research
was
pointing
to
like
some
confusion
on
setup,
but
then
also
a
compliance
concern
and
shinya.
I
don't
want
to
call
on
you
and
your
video's
not
on
so
maybe
that
I
shouldn't,
but
I
know
I
reference
shinya's
like
deployment
safety
documentation
a
lot.
I
don't
know
if
you
know
you
have
a
perspective
on
or
we
know
what
those
limitations
are.
B
The
question
was
about
the:
what
were
the
compliance
implications,
because
I
know
we
talk
and
document
a
lot
about
deployment
safety
and
how
to
make
sure
you
have
like
appropriate
segregation
of
duties
between
those
who
set
up
and
manage
the
environments
and
those
who
deploy
to
them.
But
I
don't
know
if
that
that
feels
like
something
that
we
can't
just
say:
oh
well,
if
we
fix
the
the
ease
of
understanding
the
construct
and
setting
it
up
that
they'll
they'll
use
it.
If
there's
a
big
compliance
blocker
from
using
it
in
the
first
place,.
D
A
So
what
I've
heard
from
customers
like
at
the
top
level
is
when,
if
there's
an
audit,
they
want
to
be
able
to
say
definitively
what
is
in
an
environment,
so
so
the
concept
of
like
going
to
an
environment
and
seeing
what's
deployed
and
the
history
of
that
deployment
is
somewhat
useful.
But
deployment
is
also
potentially
like
a
step
removed
from
having
that
clear
audit
trail.
A
B
And
I
I
would,
I
would
posit
that
we
have
a
path
for
solving
that
job
to
like,
let
me
get
the
artifacts
for
or
a
tagged
release
the
one
that
I
seem
to
always
hear,
and
I
remember
or
working
pretty
heavily
on
this-
was
the
the
I'm
going
to
allow
my
developers
to
continually
deploy,
but
there
needs
to
be
some
kind
of
like
safety
controls
for
approval
of
that
deployment
or
who
can
adjust.
Who
can
view
environment
variables,
those
kinds
of
things
it
was
more
around,
maybe
com.
B
I
So
I
think
our
segregation
of
duties
future
are
not
well
implemented,
like
we
have
a
bunch
of
group
level
or
project
level,
protected
environments
or
protected.
Something,
but
basically
what's
missing
is
rock
solution.
Rule-Based
access
control,
something
like
aws,
has
actually
there's
an
issue
somewhere.
I
I
B
B
B
A
B
Well,
I
think
yeah
from
the
like
sasha
developer
perspective,
there's
what
victor
was
saying.
I
want
to
know
that
my
application
will
go
to
a
production
environment
and
I
don't
really
want
to
think
about
what
that
environment
is
or
how
it
happens.
I
just
want
to
know
that
I
have
easy
ability
to
create
code,
know
that
that
passed
appropriate
tests
and
when
merged
gets
to
production.
B
However,
that
process
might
be,
but
I
think
the
thing
we're
suggesting
is
that
there's
a
different
persona,
which
is
who's
the
person
who
operates
that
environment,
is
that
devin
or
priyanka
and
are
those
their
workflows
are
different.
They
need
to
like
set
up
and
enable
developers
to
easily
do
what
we
want
sasha
to
be
able
to
do,
and
they
need
to
be
able
to
have
insights
about
what
projects
are
deploying
to
that
environment
and
troubleshoot.
When
there
are
environment
issues
that
arise.
C
C
B
B
C
And
I
think
that
this
promotion
is
is,
is
a
is
the
the
core
of
this
job
that
it's?
It's
not
a
new
release.
The
release
was
built
already,
but
there
are
conditions
to
that
and
so
on.
So
that's
why
it's
tricky
one
another
one
that
came
back
from
from
marshall
from
nasa
is
that
it's
really
related
to
compliance
and
probably
are
many
many
jobs
related
to
compliance,
but
he
would
like
to
be
able
to
create
the
release
artifacts
in
each
each
of
the
environments,
and
this
is
something
that
some
recent
u.s.
A
C
A
C
Around
the
country's,
I
think,
slis
and
slos
are
are
a
topic
here
as
well,
which
might
be
related
to
what
what
you
meant.
What
you
said
first
around,
I
want
to
see
what
I
have
in
a
specific
environment,
but
it's
more
than
that,
because
I
want
to
see
the
status
of
that
deployment
in
that
environment.
C
H
Yeah,
on
top
of
that,
I
think
there's,
there's
some
overlap
with
observability
in
in
the
sense
of
the
environment
is
broken.
Is
it
the
infrastructure,
that's
broken,
or
my
application
code
right
being
able
to
have
visibility
on
that,
like
especially
as
a
developer
like
I
want
to
know
if
my
code
is
breaking
the
application
or
if
it's
something
that's
outside
of
my
control,.
D
Exactly
and
that's
the
environment
dashboard
right,
that's
where
it's
supposed
to
go
and
how?
How
is
my
my
application
doing?
Nothing,
not
just
in
sense
of
adding
projects
but
the
status
of
the
deployment,
for
example
over
time
and
I'm
gonna
highlight
here
for
you
danielle,
you
know
version
of
deployments
and
getting
this
type
of
data
rather
than
just
a
list
in
a
different
format
of
what
you
can
do,
but
those
were
the
other
things
that
we
did
not
validate.
D
C
It's
a
bit
far-fetched
but
continuing
on
on
kevin's
idea
around
user
data.
I
could
imagine
that
environments
are
related
to
product
metrics
and
by
product
metrics.
I
really
mean
not
the
not
the
ops,
metrics
but
but
usage
that
are
within
the
product,
because
if
I
think
about
a
feature
in
a
sense
that
we
build
this
in
order
to
move
the
needle
here
and
then
we
deploy
that
feature
to
production,
then
I
would
like
to
see
the
needle
in
that
in
the
production
environment
moving.
B
Yeah,
I
love
that
I
do
think
if
you
take
that
to
just
what's
the
what's,
the
kind
of
like
end
construct
for
value
stream
management.
It
is
a
production
environment
and
the
kind
of
collection
of
applications.
However,
many
there
are
that
make
up
that
singular
production
environment
is
typically
the
thing
that
is.
J
I
mean
you
could
probably
do
estimates
for
sure.
But
let's
just
say
the
customer
is
deploying
to
aws.
You
could
definitely
do
an
estimate,
but
then,
if
it's
a
large
organization
on
aws,
they
have
their
own
agreements,
and
so
typically
you
have
to
do
this
sort
of
like
cross-referencing.
So
you
could
probably
do
like
a
really
light.
Mvc
and
they
say
hey
the
estimated
cost
is
x,
but
translation
might
be
harder
in
terms
of
the
actual
cost.
A
I'm
definitely
going
to
rewatch
this
video
because
we
discuss
a
lot
of
things
and
clearly
there's
a
follow-up
I'll
I'll
take
with
jackie
to
get
her
brain
dump
and-
and
I
believe
we
have
a
lot
of
these
things
written
down
in
issues
and
so
forth
already.
So
there
is
work
to
be
done
around
organization
and
there,
as
I
cross
reference
these
things
together,
and
there
are
things
that
we
haven't
captured
I'll.