►
From YouTube: GitLab 16.3 Kickoff - Deploy:Environments
A
I
am
the
product
manager
of
the
environments
group,
and
this
is
our
16.3
kickoff
video
first
I'm,
going
to
present
our
delivery
goals
and
after
that
Emily
Bowman,
we
present
the
discovery
plan
for
the
coming
milestone
at
the
top
of
the
of
our
planning
issue,
you
can
see
a
little
clarification
in
our
Direction,
the
studio
level
for
direction
page
update,
but
too
high
level
to
be
included
in
a
single
issue.
If
you
are
interested,
please
check
it
out
now,
let's
turn
to
our
goals
for
becoming
milestone.
A
First
of
all,
we
want
to
continue
our
work
on
the
cluster
UI
integration
that
we
shipped
in
16-1.
We
are
very,
very
close
to
provide
namespace
level
support
for
the
cluster.
This
means
that
today,
in
a
single
environment
we
visualize
the
whole
cluster
State
and
all
the
cluster
resources.
This
is
not
the
best
for
most
of
our
customers,
because
very
likely
there
are
multiple
teams,
multiple
environments,
multiple
applications
actually
running
on
a
single
cluster
and
the
GitHub
environment
likely
corresponds
to
either
single
teams
or
to
single
application
of
a
team
and
the
namespace
selection.
A
The
team
will
be
able
to
filter
only
that
namespace,
where
the
resources
are
relevant.
The
other
item
in
the
in
the
same
area
is
to
provide
watch
API
support.
Today
we
load
the
cluster
state
a
single
time
when
the
UI
loads,
for
the
first
time
with
the
watch
API,
they
get
new,
real-time
updates
of
the
cluster
state
in
the
gitlab
UI.
We
have
two
strategories
in
this
domain.
One
is
to
show
the
flux
sync
status
in
the
environment
page.
A
This
basically
means
here
you
can
see
this
cluster
UI
integration
on
a
live
cluster
and
we
have
this
environment
health
healthy
badge
already,
which
shows
that
all
these
ports
that
are
running
are
actually
healthy
and
there
are
no
fail
inputs
at
the
same
time.
We
don't
know
out
of
this
better
our
github's
installations
up
to
date,
but
it's
currently
trying
to
sync
or
it's
out
of
sync.
A
For
some
reason,
the
flux
thing
sync
badge
will
provide
one
more
badge
besides
the
healthy
one,
showing
the
status
of
our
GitHub
synchronization
with
flux,
and
the
other
item
is
again
related
to
very
similar
to
namespace
selection.
That's
to
provide
a
convention
on
further
filtering
resources
in
an
environment
by
labels.
This
will
make
the
previous
certificate-based
applications
automatically
be
filtered
as
they
were
previously,
as
that
integration
use
the
same
labels
that
we
intend
to
introduce.
A
The
second
item,
which
is
kubernetes
office
hours,
actually
is
something
that
we
think
is
very
important
for
us
to
build
the
community
to
support
the
community
and
we're
going
to
write
on
the
24th
of
July
in
the
Early
Mornings
in
Europe
early
evenings
in
apak
and
likely
at
night
in
the
Americas.
A
A
This
is
something
that's
actually
needed
for
the
runway
project
as
well.
The
other
item
that's
needed
for
the
runway
project
is
to
support
the
environment.
Keyword
with
the
trigger
keyword.
The
trigger
keyword
allows
to
construct
parent
chart
Pipelines,
and
these
are
often
used
in
deployment.
For
example,
there
might
be
an
application
code
owned
by
a
development
team
that
triggers
a
child
pipeline
for
the
actual
deployment,
and
today
it's
not
possible
to
set
up
an
environment
with
that
triggering
job.
As
a
result,
it's
very
easy
to
it's
very
hard
to
track
across
pipeline
deployments.
A
The
following
items
we
want
to
work
on
is
improve
our
kubernetes
version
support.
We
have
a
versioning
policy
that
wants
to
add
version
supports
to
recent
release,
kubernetes
versions,
three
months
after
the
initial
release-
and
this
is
time
to
add
support
for
commanders
1.27.
We
did
the
evaluation
work
a
couple
of
months
ago,
thanks
to
Pam
artiaga
and
in
the
next
Milestone.
We
actually
want
to
do
the
actual
delivery
of
the
necessary
adjustments.
A
At
the
same
time,
we
have
a
72
bug,
namely
kubernetes
beta
iepi
was
deprecating
version
126
that
was
reported
recently
and
we
don't
support
the
V2
stable
apis.
Yet,
as
a
result,
I'll
Auto
deploy,
hem
charts
might
pay
for
some
of
our
customers.
A
We
want
to
fix
that
as
well.
Together,
we
do
127
support.
The
last
item.
Here
is
not
a
feature
derivative.
It's
more
lack
of
Maintenance
work.
We
realized
that
our
core
metrics
are
miscalculating
the
agents.
The
metric
always
wanted
to
calculate
the
number
of
active
agents
that
were
used
in
a
given
month,
but
actually
it
calculates
the
number
of
agents
that
have
an
active
token,
no
matter
whether
that
agent
was
used
in
that
month
or
not.
A
We
want
to
fix
that
metric
to
make
sure
that
we
have
better
understanding
of
the
usage
of
our
features,
and
then
we
have
quite
a
few
minor
one-weight
issues
listed
here.
We
consider
all
of
them
stretch
to
fill
up
the
time
that
our
Engineers
have
in
the
mile
Milestone
and
we
have
a
few
future.
Looking
stretch
goes
as
well.
That
likely
we
won't
be
able
to
finish
in
the
coming
milestone,
and
this
is
our
delivery
plan.
B
Hey
everyone:
this
is
Emily
Bowen,
the
senior
product
designer
on
the
environments,
team
and
I'm
here
to
kick
off
the
ux
plan
for
16
3.,
so
16
3
with
ux.
We
have
quite
a
few
things
going
on
some
spanning
multiple
milestones
and
some
smaller
initiatives.
We
want
to
get
done
in
this
Milestone
and
the
first
thing
kicking
us
off
is
kind
of
continuing
with
our
outcome
of
the
environment's
design
Sprint.
So
now
we
have
an
idea
of
where
we're
going
with
a
service
orientated
operations.
B
We
still
have
to
validate
that
with
customers,
understand
and
clear
up
this
concept,
a
bit
more,
so
1603
is
really
going
to
be
focused
around
doing
some
solution.
Validation
on
this
concept,
building
out
some
of
the
technical
proposals
for
this
and
just
validating,
is
what
our
customers
want.
So
this
will
be
anything
from
interviews
with
sres
within
gitlab
to
interviews
with
customers
outside.
B
So
this
is
a
multi-mile
Milestone
project.
We
probably
won't
finish
this
in
163,
but
we'll
get
a
good
chunk
of
work
done.
B
The
next
one
is
just
a
design
issue
around
now
that
we
have
external
jobs.
We
want
to
get
the
visuals
in
for
that.
So
what
do
external
jobs
look
like
on
the
job?
Details
page
job
list,
page
pipeline,
Details
page?
So
what
call
to
action?
Should
they
be
there?
How
should
these
kind
of
pages
be
designed?
B
The
third
thing
will
be
continued
support
of
the
gitlab
built-in
kubernetes
dashboard
design,
so
this
will
be
in
close
collaboration
with
front
end,
as
they
start
working
through
this
seeing
what
parts
of
this
dashboard
need
to
be
put
into
High
Fidelity
in
16
3
to
be
ready
to
work
on
in
16-4.
So
again,
this
is
another
multi-milestone
effort
that
design
is
just
helping
with
as
we
move
through
the
development
of
this
dashboard.
B
Another
smaller
one
to
look
at
is
add
an
icon
to
the
terraform
plan
widget.
So
this
is
within
the
Mr,
adding
an
icon
in
to
let
users
know
when
something
needs
attention
in
regards
to
that.
So
this
is
a
smaller
issue.
That's
been
open
for
quite
a
while,
so
investigating.
Is
this
still
a
problem,
and
if
it's
so,
how
do
we
solve
it?
B
And
then
the
final
one
is
a
very
small
issue,
sauce
impacting
issue
around
the
help
text
with
historical
releases
right
now.
The
help
text
is
like
a
little
bit
hard
to
understand,
so
taking
a
look
back,
how
we're
communicating
historical
releases
to
our
users
and
working
with
content
and
technical
writing
to
make
sure
these
popovers
and
just
how
we're
showing
this
makes
sense,
and
that
is
the
ux
kickoff
for
16-3.
Thanks
for
listening.