►
From YouTube: Ops Cross-stage ThinkBIG! For January 2021
Description
A thriving conversation with design and product management within Ops to discuss and define how we as a group define and view Environments.
A
A
This
is
the
mirror
board.
That's
usually
that's
recommended
as
a
thing
big
template.
So
my
idea
was
that
we
go
for
this
one,
but
before
we
get
started,
I
would
like
to
give
a
bit
of
background,
which
is
actually
the
first
two
or
three
sections
of
this
mirror
board.
At
the
same
time,
there's
a
biggest
environment.
We
have
some
kind
of
environment
in
gitlab
today
and
or
it
knows
much
more
about
them
than
I
do.
A
A
Why
the
engine
manager
is
interested
in
specific
deployments
there
and
as
as
some
gitlab
service
pointed
out
in
the
in
the
gitlab
issue.
Environments
are
actually
a
central
element
of
the
ops
workflow
and
my
take
on
this
will
be
that
we
are
kind
of
like
the
ship,
the
fishing
of
water,
that
we
don't
realize
how
central
environments
are
like.
The
fish
does
not
realize
that
he's
in
the
water,
but
actually
environments
are
much
more
crucial
than
than
as
we
think
about
them
today
at
gitlab
and
what
just
to
be
done?
I
I've
added
a
few.
A
A
I
I
added
a
few
personas
there,
but
there
might
be
even
others
who
who
might
face
problems
with
our
environments,
because
they
just
have
different
work
views
of
it.
It's
not
always
the
problem,
because
I
think
that,
for
some,
our
solution
is
probably
great,
but
the
topic
of
the
environment
is
of
it
affects
all
these
people
and
to
get
started
discussion.
I
just
would
like
to
to
ask
your
opinion
about
environments,
whether
you
agree
with
this
claim
that
today
the
environment
might
not
fit
all
the
personas,
or
you
disagree
with
that.
B
What
is
the
problem
that
we're
currently
seeing
in
the
environment?
That's
kind
of
what
I'm
missing?
Yes,
there's
different
personas,
we
use
environments
for
different
things.
Some
environments
are
protected,
some
environments
are
not
protected.
Some
environments
are
long-lived.
Some
are
short-lived,
like
review
apps.
What's
the
problems
that
we
have
today
around
environments.
A
A
A
C
C
B
B
B
B
Yes,
I
definitely
agree
with
the
fact
that
the
playboards
needs
to
be
improved
a
bit
first
of
all,
there's
a
lot
of
content
that
we're
not
showing
there.
So
specifically,
if
we
like,
I
take
it
to
like
cloud
providers
and
such
there's
really
no
way
where
you
know
where
this
pot
is
landing
at
a
first
glance
without
so,
if
you
I'm
going
to
go
back
to
spinnaker
at
the
moment,
but
I'm
sure
there's
other
tools
that
do
this.
B
When
you
look
at
spinnaker,
for
example,
it
is
very
infrastructure
oriented
and
you
can
see
on
the
right
hand,
side
the
cluster
name
where
it's
going
to
be
deployed
to
with
the
url
you
can
see
like
different
health
checks.
We
do
have
some
health
checks
on
the
deploy
board
and
they're
pretty
they're,
okay,
but
there's
so
much
more
that
we're
missing
there
in
terms
of
pot,
health
and
so
on,
which
really
help
you
without
having
to
go
into
another
tool
and
check
really
what's
going
on
with
your
cluster
and
and
so
on.
A
Yeah,
what
I
really
would
like
to
to
discuss
with
you
here
is
that
do
we
think
environments
should
be
more
central
to
git
lab
or
they
are
at
the
right
level,
because
my
personal
opinion
that
they
should
be
more
centered.
As
I
told
you
to
me,
environments
seem
like
water
for
the
fur
fish,
it
doesn't
recognize.
It
operates
in
water,
but
it
does.
B
So
there
is
a
whole
conversation
about
the
fact
that
we
want
to
make
environments
and
also
deployments
by
the
way
into
more
things
that
are
easily
easily
found
like
if
you
look
for
deployments
now,
the
deployments
page
it's
like
impossible
to
find
and
like
the
deployment
is
the
most
important
aspect
of
the
of
your
pipeline,
but
it's
hidden
so
well
that
it's
really
you
need
to
have
all
these
different
shortcuts
and
saved.
So
we
definitely
need
to
make
this
more
of
a
first
class
citizen
approach.
B
We
had
talked
about
in
another
issue
where
we
were
just
talking
about
the
left:
pane
navigation,
to
bring
environments
to
be
more
visible
today,
it's
a
little
bit
hidden,
so
absolutely,
and
also
it's
very
noisy
today.
So
if
you
open
the
environments
page
today,
you'll
see
it
starts
with
review
apps
and
then
there's
a
ton
of
like
what
I
call
not
interesting
environments,
because
really
what
you're
interested
about
is
production?
B
B
So
now
we've
brought
the
pipeline
to
the
to
the
environment,
so
you
can
see
the
status
of
your
latest
pipeline,
which
wasn't
visible
before
we
connected
alerts
into
the
environment
page.
So
now
you
know
if
something's
wrong
and
we're
adding.
You
know
the
ability
to
do
a
rollback
from
there
instead
of
drilling
down
to
your
pipeline,
finding
the
last
pipeline
and
then
rolling
back.
So
there
really
is
a
lot
to
do
in
that
sense,
and
I
definitely
agree
that
the
experience
is
not
ideal
at
the
moment.
A
I
would
add
a
few
more
things
here
which
is
like
to
me
when
another
approach,
where
I
again
arrived
to
environment
is
when
I
started
thinking
about
secrets
management
that
to
me,
sickness
management
really
belong
under
environment,
and
I
know
right
now.
We
try
to
add
variables
to
environments
as
we
define
environments
in
gitlab,
but
just
the
hierarchy
seems
to
be
the
opposite.
So
is
that
the
that
it's
not
that
the
environment
belongs
to
sick?
The
secrets
management
is
a
consequence
that
I
have
environments,
but
just
that,
as
I
have
variables,
I
need
secrets,
managed.
B
A
B
B
We
have
a
lot
of
issues
to
bring
things
to
the
group
level,
but
really
what
we're
trying
to
do
is
get
it
to
the
environment
level
at
the
end
of
the
day,
because
if
you
have
a
set
of
permissions,
it's
a
set
of
permissions
for
my
environments,
whether
it's
for
variables,
whether
it's
for
maintainers,
whether
it's
for
deployments,
feature
flags,
you
you
name
it
really.
The
environment
is
the
real
real
starting
point
and
not
really
the
project.
C
Yeah
yeah,
I
think,
if
you
like,
drew
out
the
like
information
architecture
or
object.
Architecture
of
how
you
get
to,
I
think
secrets
is
a
great
one
like
how
you
get
to
a
secret
that
allows
you
to
deploy
to
a
aws
instance.
You
have
to
traverse
so
many
things
that
the
user
doesn't
actually
think
about.
They
think
about
environment
and
secrets
for
that
environment,
not
it's
a
project
that
might
define
the
infrastructure
that
holds
the
variables
for
ci.
That
also
contains
one
that
scopes
to
a
production
environment.
C
So
I
think,
like
that,
makes
sense
to
me
that
we
have
not
elevated
environments
to
the
right
place
for
these
use
cases.
I
do
want
to
sorry
to
call
on
you
sarah,
like.
I
would
imagine
that
this
also
impacts
monitor
in
that
it's
not
necessarily
the
project
that
users
are
setting
up
alerts
to
respond
to
incidents
for
that,
they
think
about
it
more
in
terms
of
the
environment
that
might
span
multiple
projects.
B
E
E
That
word
and
I
feel
that
sometimes
they're
also
talking
about
the
environment
in
which
that
service
runs,
and
so
in
conversations
I
haven't
dug
into
when
someone
has
talked
about
the
scope
within
the
which
they
want
to
alert
or
have
an
incident
kenny.
I'm
kind
of
talking
in
circles
around
what
you
just
said
so.
E
I'll
be
direct.
Yes,
we've
heard
that
no,
I
have
not
dug
into
that.
Typically,
if
someone
has
an
environment
they're
able
to
send
the
information
through
in
the
alert
payload,
and
we
have
the
opportunity
to
do
things
with
those
attributes
because
we're
a
single
platform
for
all
of
these
different
products.
C
E
B
That
was
that
we
did
recently
add
to
the
alerts
and
get
the
environment
itself,
so
you
so
people
can
click
into
it.
Once
you
see
a
problem
and
also
we
added
the
alerts
from
the
environment
page,
so
you
can
really
anywhere
you
look
at
it.
You
can
understand
that
this
is
specific
to
this
environment
and
not
necessarily
to
a
project.
E
A
A
Do
that
okay
yeah,
I
can
give
you
a
specific
example.
Is
that
if
I
am
an
infrastructure
person
for
me,
the
environment
is
a
cluster.
If
I
am
an
application
operator
or
devops
engineer,
then,
and
that
cluster
contains
hundreds
of
namespaces.
Why?
For
the
software
development
point
of
view,
I
have
rights
to
deploy
to
one
of
those
namespaces
and
that's
all.
A
A
A
C
Okay,
thank
you.
Namespace
is
not
a
messy
food
term.
Gitlab
uses
namespace
to
mean
top
level
group
we're
talking
about
a
kubernetes
namespace,
which
is
like
a
kind
of
isolated
set
of
pods
in
your
kubernetes
cluster.
I
have
a
question
for
the
design
team.
I
feel
like
when
we're
you're
listing
out
the
jobs
to
be
done.
The
the
same,
we're
talking
about
the
same
jobs
to
be
done.
C
We're
just
talking
about,
but
those
jobs
to
be
done
that
are
enabled
today,
with
our
environments
and
deploy
boards,
are
not
enabled
because
of
kind
of
like
structure
in
which
certain
users
structure
how
they
perform
that
job.
So
it
doesn't
feel
like
we're
talking
about
whole
new
jobs
to
be
done.
It
feels
like
we're
talking
about
supporting
people
who
might
have
different
ways
of
performing
that
job
to
be
done
than
what
exists
today.
Is
that
what
would
we
call
that,
if
it's
not
a
job
to
be
done,.
F
C
B
C
B
Well
so,
for
example,
what
victor
had
mentioned
about
about
secrets?
That's
something
really
nice
that
they
do
it's
environment-based,
it's
not
project-based,
and
they
let
you
like
expose
secrets
on
any
pipeline
in
the
environment
you
need
to
like.
You
need
to
get
specific
approval
from
someone
for
that
to
be
to
go
to
the
next
level
to
the
next
job.
So
there
are
some
really
elegant
things
that
they
do,
but
the,
but
it
seems
very
similar
to
our
solution.
In
other
aspects.
B
A
I'm
thinking
of
of
something
like
that
as
the
the
own,
I
mean
it's
hard
to
differentiate
from
github
because
they
they're
in
very
similar
fashion,
similar
place,
but
like
that,
for
example
with
spinnaker.
They
don't
own
your
code
base.
They
they
don't
own
multiple
projects,
so
they
don't
own
both
the
infrastructure
side
and
the
application
side
of
your
code.
That
is
there
any
do
we
see
any
big
value
propositions
around
around
this.
B
To
be
more
extreme
picture,
they
don't
even
own
ci,
they
do
only
deployments,
so
we
could
definitely
make
a
much
better
integrated
experience,
a
lot
of
customers
that
I
talked
to
that
chose
spinnaker.
They
chose
them
because
they
were
the
first
and
they're,
also
gitlab
users,
and
they
don't
like
when
I
talk
to
them
about
this
auto
roll
back
and
all
this
great
functionality
that
we've
been
adding
they're
like
well
you're
in
the
right,
you're
doing
the
right
things,
but
we
already
have
all
these
projects
that
are
we
already
have.
B
Instead
of
so
we're
not
gonna
move
over,
so
we
really
need
to
bring
some
some
something
killer
in
order
to
convince
people
that
are
all
are
already
doing
it.
The
good
news
is
it's
not
like
jenkins,
like
spinnaker
solution?
Isn't
that
wide
widely
adapted
as
jenkins?
So
even
for
a
new
piece
for
new
users,
it
should
be
easier
to
to
get
people
on
our
platform
as
a
single
tool
chain
as
a
tool,
single
tool
and
so
on.
B
B
A
A
What
I
see
as
as
a
is
where
we
are
mostly
with
origen.
It
means
that,
as
we
are
speaking
most
here,
is
that
that
we
agree
that
environments
should
have
a
more
should
you
see
more
focus
inside
gitlab,
probably
not
just
in
terms
of
navigation
but
in
terms
of
product
focus
that
we
build
features
around
the
environments.
We
understand
that
we
are
operating
within
environments
and
not
within
variables.
A
C
B
C
G
Ahead,
we
talked
about
kind
of
promoting
environments
throughout
gitlab.
Should
we
be
looking
at
kind
of
all
the
opportunities
we
can
to
show
environments
in
other
parts
of
the
code
so
like
in
package,
we
might
want
to
say
this
package
was
included
in
an
environment
and
just
kind
of
find
ways
to
sprinkle
little
details
everywhere.
G
The
reason
I
say
that
is
one
of
our
users
and
packages
favorite
feature
is
on
the
list
view
we
added
what
pipeline
it
came
from,
and
that
was
just
enough
to
sell
them
on
it
by
itself
because
it
kept
it
organized
and
all
their
commits
are
together.
Is
there
opportunities
like
that
that
we
could
explore
that?
Just
by
being
gitlab
and
like
we've
mentioned
owning
those
areas
that
we
could
just
promote
environments,
very
in
very
small
steps
everywhere,.
A
A
B
Well,
so
I
wanted
to
mention
that
I
don't
know
how
many
of
you
on
the
call
are
aware
that
we
have
this
awesome
feature
called
environments
dashboard,
and
it
took
me
moving
out
of
the
release
management
group
going
back
to
the
release
management
group
to
actually
figure
out
where
to
find
the
really
cool
dashboard
that
was
built
in
the
last
six
months
and
that's
like
a
shame.
It's
really
hidden.
You
need
to
like
go
to
more
and
then
look
for
it,
but
this
awesome
landing
page
that
shows
you
all.
B
The
environments
shows
you
green
and
red.
What's
going
on
shows
you,
you
know
the
alerts
that
are
going
on
there.
If
you
need
attention
where
when
was
the
last
commit,
when
was
the
last
appointment,
it's
so
cool,
but
it's
so
hidden
that
we
should
probably
make
that
so
much
more
visible
and
probably
get
a
bigger
win
from
using
the
existing
functionality,
without
even
adding
all
the
the
new
great
stuff
that
we
want
to
do,
for
infrastructure
for
multi-clusters
and
so
on,
and
just
make
that
a
better
experience.
B
H
Have
bookmarked
this
this
page
of
environment
dashboards,
so
that
I
can
find
it?
That
was
the
first
thing,
but
back
to
ian's
point
I
tried
to
use
environments
for
the
terraform
state
and
the
problem
I
found
in
defining
which
environment
the
terraform
code
actually
produces
the
infrastructure
for
was
that
it's
a
manual
process.
So
if
the
user
doesn't
really
provide
the
environment
within,
I
don't
know
their
terraform
or
whatever
other
interface.
H
C
I
was
gonna,
I
wonder
if
maria
that
is
part
of
what
we're
talking
about,
I
guess
ian
your
point
about
making
connections
to
environments
more
ubiquitous.
I
think
that
is
the
goal
as
a
single
app.
We
should
enable
you
to
like
make
these
connections
between
something
as
important
as
an
environment.
Like
victor
saying,
it's
kind
of
for
anything,
post
release
is
the
water
that
your
application
is
swimming
in,
so
it
should
be
very
critical,
but
I
still
feel
like
those
are
optimizations
without
tackling
the
problem
which,
I
guess
you
could
boil
down
to.
C
Users
are
finding
it
painful
to
get
started
and
utilize
our
environments
because
of
the
structure
in
which
we
created
them.
So
if
we
elevated
them
and
said,
oh,
you
can
create
these
environments
at
a
different
level
and
define
them,
and
then
then
there
would
be
more
usage
and
those
connections
between
all
different
parts
of
the
application
would
be
much
more
valuable
to
each
individual
user.
I
did
want
to
ask
I'm
not
super
familiar
with
what
the
process
I
would
do
to
create
an
environment.
B
C
I
wonder
if
like
and
so
that
this
was
actually
a
question
for
you,
maria,
like
now
that
we
have
these
this
support
and
capability
for
something
like
an
infrastructure
project
where
you
would
want
to
define
that
environment
and
then
make
the
connection
to
say
this
is
where
the
code
lives
for
the
environment,
I'm
defining
it
here
and
then
anytime.
I
look
at
an
environment.
I
could
reference
back
to
that
location
feels
like
we're
missing
that.
How
do
I
create
this
thing
and
connect
it
to
where
its
meaning
is.
H
In
my
mind,
it
would
sit
above
groups
which
is
a
massive
change,
but
multiple
groups
can
sit
under
one
environment
talking
about
permissions,
so
one
when
you
structure
your
gitlab,
what's
the
mental
model
of
the
users,
basically,
we
need
to
run
some
user
research
how
they
think
about
the
process.
Do
I
start
with
projects?
Do
I
start
with
groups
or
do
I
start
with
the
environments
and
then
what
each
of
them
includes.
A
A
That's
that's
the
current
situation
for
github.com,
because
we
have
ops.gitlab.com
that
defines
the
environment
for
gitlab.com
and
it's
right
yeah.
So
it's
like,
as
it
seems
like
the
environment,
is
more
that
somehow
I
have
to.
I
want
to
tie
my
environment
back
to
groups
and
projects,
but
it's
it's.
It's
a
separate
project
actually,
in
the
end.
C
I
didn't
follow
that
ops
example,
because
that
just
so
happens
because
we're
in
the
business
of
using
our
single
devops
platform
that
also
hosts
our
single
devops
platform.
But
if
you
were
siemens,
you
would
have
gitlab.siemens.net,
and
that
is
their
gitlab
instance
that
contains
all
the
definition
of
what
their
infrastructure
is
in
those
environments.
But
then
they
would
be
deploying
to
something.
That's
not
gitlab.siemens.com.
A
H
A
H
C
C
I'm
thinking
of
the
victor
we've
talked
about
this,
the
like
waypoint
example,
where
you
have
a
project
that
says:
hey:
here's
how
you
deploy
to
me,
I'm
the
definition
of
an
environment
in
this
project
and
then
other
projects
just
say:
hey,
I'm
I'm
deploying
to
this
environment
do
whatever
it
tells
you
to
do
to
deploy
to
it.
That
like
makes
a
separation
between
infrastructure
definition
and
application
definition,
but
does
require
the
user
to
make
that
connection
between
the
two.
A
A
It
said
that
environments
were
so
great
but
mario
had
to
bookmark
them.
So
it's
on
these
lines.
The
other
is
to
that
environments
should
be
configured
manually,
but
we
should
have
to
make
it
easy
to
to
add
it
into
traffic
templates
and
various
templates.
It's
used
much
more
often
and
we
make
it
clear
that
they
exist.
A
H
B
H
B
A
A
B
C
A
Action
items
out
with
not
just
ideas,
but
I
don't
know
who
can
who
can
take
up
any
of
this
work
or
if
I
know
or
it's
mostly
in
your
area,
I
don't
know
if
it's
just
helpful
to
you.
It
was
insightful
to
me.
I
can
tell
you
that,
but
but
I
don't,
I
don't
plan
any
work
on
this.
That's
the
that's!
The
situation
totally.
B
Honest
where
I
didn't
plan
to
do
too
much
around
this.
That's
the
honest
truth,
especially
with
the
realignment
of
the
team
kind
of
environments
which
is
part
of
release.
Orchestration
went
down
priority,
but
it's
really.
I
think
I
learned
a
lot
from
this
conversation
and
I
think
it's
really
interesting,
because
maybe
we
can
get
more
users
to
be
using
an
additional
stage,
especially
around
the
multi-cluster
use
case.
B
A
C
And
I
I
guess
I
didn't
think
this
conversation
other
think
bigs
are
kind
of
more
directed
for
a
specific
team.
In
my
mind,
this
was
about
highlighting
that
we
as
a
cross
stage
initiative.
This
is
impacting
a
lot
more
and
maybe
that
increases
or
it's
global
prioritization
of
it,
because
she's
now
informed
about
how
it's
impacting
other
groups.
A
A
Yeah,
I
don't
know
if
anybody
has
anything
else
to
say,
because
we
have
some
time
left.
If
not,
then
thank
you
very
much
for
your
inputs.
I
will
try
to
add
some
summary
in
the.
I
think
you
have
to
write
some
issue
about
it,
but
in
the
mural
it's
I
took
notes
of
everything.
Basically,
so
thank
you
very
much.