►
From YouTube: 16.1 Environments group milestone kick-off
A
Foreign,
this
is
the
environments
group
kickoff
for
Milestone
16.1.
My
name
is
Emily
Bowman
and
I'm
the
product
designer
on
the
environments,
team
and
I'm
here
with
Victor,
who
is
a
product
manager
who
will
be
going
over
the
delivery
portion
of
this
kickoff
and
I'll
be
covering
the
ux
and
what
we're
focusing
on
with
ux.
A
So
this
Milestone
we're
really
kicking
off
strong
with
the
environment's
design
Sprint.
So
16.0
was
spent
kind
of
planning
the
Sprint
to
getting
everything
organized
and
we're
hoping
to
run
it
the
second
or
third
week
of
the
Milestone
so
excited
to
get
the
team
together.
We're
going
to
be
focusing
on
positioning
environments
as
a
central
place
together,
delivery,
related
information
and
just
ideating
on
how
to
improve
our
current
environments.
Experience
so
looking
forward
to
that.
The
other
thing
we'll
be
kind
of
wrapping
up
is
continue.
A
Recruiting
and
Gathering
users
for
our
solution:
validation
for
group
level,
production
environments,
we've
had
some
good
interviews
so
far,
looking
forward
to
have
a
few
more
synthesize,
some
of
that
data
and
update
our
concept
for
something
that
really
works
for
our
users.
So
this
is
really
looking
at
production
environments
at
the
group
level
and
being
able
to
Monitor
and
manage
those
environments
at
the
higher
level.
So
you
don't
have
to
dig
down
into
the
project.
A
The
next
one
is
just
continued
support
of
the
built-in
kubernetes
dashboard.
This
will
be
really
the
landing
page
figuring
out
what
visualizations
we
can
show
there
what's
most
useful
to
the
user,
getting
those
designs
into
High,
Fidelity
and
something
that
engineering
can
work
with.
So
this
is
another
thing
we'll
be
focusing
on
during
the
Milestone.
That's
like
a
bigger
effort
and
then
the
final
two
are
just
some
impacting
issues.
One
is
adding
a
loading
state
to
the
environments
page,
currently
the
environments
page.
When
it
loads
just
says
you
don't
have
any
environments.
A
We
thought
it
would
be
nice
to
add
in
some
sort
of
loading
state,
so
you're
aware
that
your
environments
are
loading
and
nothing
has
gone
wrong
there.
So
just
a
small
usability
issue
we're
going
to
tackle
and
similarly
I
know,
we've
had
this
theme
going
on
with
the
sus
impacting
and
giving
users
better
feedback,
but
this
is
just
a
smaller
issue
around
adding
better
feedback
when
you're
starting
a
manual
deployment.
So
users
are
more
aware
that
they've
taken
that
action
so
yeah.
B
B
The
next
item
is
this:
kubernetes
dashboard
that
we
are
speaking
about
for
many
many
months
now.
The
front
end
is
almost
ready.
We
are
still
working
on
the
back
end
part
to
make
it
in
a
releasable
state,
and
then
we
want
to
release
in
a
beta
version
First.
It
will
be
beta
because
there
might
be
some
performance
issues,
but
from
the
UI
point
of
view,
we
consider
it
pretty.
B
In
terms
of
the
designs
and
the
ux-
and
we
want
to
have
it
documented
as
well-
I
added
the
design
Sprint
into
the
at
least
of
delivery
as
well,
because
it
will
take
a
week
for
hopefully
two
of
our
Engineers,
the
designer
and
myself
as
well.
So
it's
a
big
big
initiative,
but
everybody
spoke
about
it.
So
I
don't
want
to
spend
more
time
on
that,
and
then
we
have
two
very
interesting
items
that
are
almost
ready
to
be
released
in
16.0
and
I.
B
A
B
One
is
around
notifying
flux
about
new
commits
without
any
extra
configuration.
The
issue
with
all
the
GitHub
stores
are
the
city,
flux
or
anything
else
as
well,
except
for
the
previous
gitlab.
Built-In
solution
is
that
the
GitHub
stool
runs
independently
of
the
source
code
management
or
the
github's
repository
actually,
and
why
these
GitHub
stores
regularly
check
the
source
for
new
versions
in
order
to
get
a
faster
feedback.
Web
hooked
web
hooks
need
to
be
set
up
and
likely.
Your
GitHub
still
needs
to
be
exposed
over
an
Ingress
to
consume.
B
B
B
On
the
long
run,
we
imagine
flux
to
be
part
of
the
gitlab
pipeline
visualization.
It
will
never
happen
in
the
pipeline
in
the
sense
that
there
is
no
job
to
be
run
by
gitlab
Runners,
but
there's
a
job
to
be
done
by
flux.
It
would
be
nice
to
have
some
pre
and
post
deployment
jobs
so
that
you
can
build
the
container.
You
can
trigger
flux
to
sync
and
once
the
sync
is
done,
you
can
follow
on
with
some
post
deployment
jobs
like
testing,
for
example,
in
1601.
B
We
would
like
to
release
the
first
version
of
of
this
functionality.
It
will
be
experimental
very
much,
which
means
we
don't
introduce
any
new
CI
syntax,
as
you
can
see
in
this
issue.
Instead,
we
create
a
separate
script
that
we
can
already
give
to
our
customers
that
they
can
play
with.
They
can
use
it
and
give
us
feedback
on
the
approach
we
already
uncovered.
Quite
a
few
difficulties
actually
with
doing
it
right
so,
together
with
the
Discovery
section
that
I
may
talk
to.
These
are
our
plans
for
the
next
Milestone.