►
From YouTube: Release:Release Governance - Deploy freeze MVC
Description
Discussion on Deploy Freeze MVC: https://gitlab.com/gitlab-org/gitlab/issues/24295
A
Okay,
so
out
of
our
think
big
conversation
that
we
had
yesterday,
we
talked
a
little
bit
about
the
blackout
periods,
which
is
now
deploy
freezes
MBC
and
we
actually
discover
there's
a
different
implementation
than
I
was
initially
thinking
about
it.
I
was
thinking
that
we
would
do
this
all
from
the
front
end
that
you
would
set
a
know,
deploy
on
an
environment,
but
then
Nathan
you
brought
up
that
we
could
possibly
start
with
the
first
iteration
of
a
Yama
file
and
then
the
front
end
could
then
update
the
animal
file.
A
So
I
just
wanted
to
kind
of
discuss.
If
that
would
be
our
preferred
approach,
and
then
we
can
start
planning
the
front
end
for
blackout
periods,
for
like
the
thirteen
and
I
think
that
that
would
give
us
three
milestones
in
advance
for
design
planning
and
then
the
animal
stuff
is
what
we
focus
on
for
this
milestone
like
as
far
as
creating
spec
for
it
and
the
next
milestone,
but
just
wanted
to
get
your
guys's
get
on
the
same
page
with
that
and
update
the
issue.
If
we
agree
that
that's
the
way
that
we
should
go.
B
B
A
From
a
UX
IDE,
hi
Anna,
how
do
you
feel
like
how
what
kind
of
acceptance
criteria
would
we
would
we
need
to
define
on
this?
So,
for
example,
do
you
want
to
know
the
the
windows
that
people
are
looking
for?
If
this
is
that
the
environment
or
group-level
like
what
kind
of
information
do
we
need
to
start
collecting
to
understand
what
the
front-end
experience
should
be?
Mm-Hmm.
C
C
So
as
I
use
or
how
do
I
want
to
configure
what
I
have
to
configure
blackout
period,
and
can
we
also
at
this
point,
think
about
like
if
something
is
configured
in
the
gate
lab
see
IMO
file?
How
would
that
impact
the
projects
that
these
are
the
group
sessions
right
with
automatically
activated
their?
How
can
they
you
hear
me
notified
or
to
know
that
the
configuration
needs
to
be
done
on
a
different
day
or
not.
A
That's
helpful
so
say
that
our
first
iteration
is
in
the
yeah
mph
aisle
and
someone
sets
it.
That's
that
the
the
deployment
freeze.
We
would
want
that
to
then
appear
on
the
relevant
environment
that
a
deployment
trees
is
set
on
this
and
that
could
be
like
that
could
be
a
part
of
the
second
iteration.
The
first
iteration
would
just
be
specifying
it,
and
then
I
mean
we
would
a
guest
need
to
to
show
that
this
is
under
deployment
freeze
in
the
pipeline
stage
or
something
like
that.
We
need
it.
How
do
we?
A
B
So
I
I
had
two
ideas
on
how
we
could
do
it
through
the
ammo
file.
One
would
be
we
in
the
ammo
file.
We
we
have
variables,
like
you
kind
of
say,
only
you
specify
the
the
blackout
periods
in
the
mo
aisle
itself
and
then
that
scenario,
I
I
think
it
would
be
a
little
more
difficult
to
show
a
thing
like
on
the
environments
page,
because
we'd
have
to
basically
from
a
technical
standpoint.
You
have
to
go
parse
the
the
ammo
file
and
kind
of
figure
out
I'm,
not
really
black
period.
B
B
Is
I'm
not
sure
what
the
best
approach
is,
but
that
second
approach
I
think
would
be
a
lot
easier
to
show
statuses
elsewhere,
like
on
the
environments
page.
The
disadvantage
is
that
if
we
go
that
route,
we
can't
really
do
its.
The
NBC
would
be
larger.
We
wouldn't
be
able
to
just
you
a
Hamel
file
solution.
A
B
A
Okay,
one
eventually
yeah,
but
we
would
the
the
long-term
path
would
be
that
we
only
support
deployment
freezes
in
one
way,
but
I
think
like
that's.
A
part
of
iteration
would
be
that
we
do
deprecated
deployment
freezes.
It
would
just
be
a
trade-off.
Do
we
feel
like
offering
something
immediately
in
the
ammo
file
where
there
may
not
be
as
much
visibility
within
the
application?
Is
that
here's
here's
the
experience
and
I'm
worried
about
a
user
set
set
name
the
file
as
a
maintainer
and
then
their
developers
that
are
working
on
their
project?
A
All
of
a
sudden
just
see
a
failing
pipeline
and
I?
Don't
realize
why
they're
failing
so
they're
wasting
a
bunch
of
time
trying
to
understand
why
their
pipelines
failing
and
really
it's
because
it's
been
blocked
like
there's
a
deployment
freeze,
so
do
we
feel
like
we
could
implement
something
in
the
a
mold
and
have
a
banner
that
says:
hey
a
deployment
freeze
has
been
implemented
in
your
project,
I
mean
I,
don't
know
how
to
then
redirect
them
to
the
animal
file.
A
C
Now,
yeah,
that's
sort
of
a
thinking,
though
I
think
regardless,
like
what
method
we
decide
to
go
like
for
the
embassy
are
the
how
far
away
the
users
have
to
figure.
It
is
I,
think
going
to
find
a
way
to
notify
people
regular
in
a
project
or
a
group
level
right
that
this
is
happening.
So
we
have
the
deployment
of
hearing.
So
many.
A
C
B
A
I
think
that
we
could
say
once
a
deployment
freeze
has
been
set
on
a
project
for
all
subscribers
to
that
project.
They
would
be
notified
that
a
deployment
freeze
is
been
set
and
then
they
would
understand
that
that
they
would
understand
that
the
deployment
freeze
means
that
their
pipelines
might
be
failing
at
the
deployment
stage.
A
But
then
we
would
need
to
prescribe
in
our
documentation
that
once
the
mo
files
subscription
is
updated
to
include
deployment
is
not
allowed
during
x,
y&z
or
deployment
is
only
allowed
during
x,
y&z,
which
we
could
support
both
in
the
Ambo
file,
which
is
a
cool
way
to
look
at.
It.
I
think
that
the
notifying
the
subscribers
would
be
great,
but
then
that
means
people
could
get
spammed,
but
I
would
rather
know
that
my
pipeline
is
gonna
fail,
then
not
know.
B
One
thing:
I:
don't
think
that
this
the
implementation
I
imagining
would
necessarily
make
the
pipeline's
fail
more
than
likely
it
would
just
skip
the
stage
altogether
and
we
already
kind
of
support
that
I
was
just
looking.
Let
me
show
you
what
that
looks
like,
and
this
might
be
enough
that
we
maybe
don't
have
to
build
anything
special.
So
you
can
see
on
this
merge
request
here.
This
review
stage
was
skipped.
It's
okay!
B
You
can
see
that
so
like
this
test,
the
test
stage
was
passed,
but
the
review
stage
was
skipped
and
I'd
have
to
look
into
this
a
little
more,
but
I
think
we
could
do
something
similar
where
we
could
just
skip
the
stage.
We'd
skip
the
deployment
stage
if
we're
in
a
blackout,
window
and
I
think
that
is
a
pretty
natural
user
experience.
B
A
I
love
that
idea
I.
Think,
though,
I
love
that
idea
this
this
makes
perfect
sense.
It's
very
natural
experience.
We
may
want
to
know,
though,
if
people
can't
see
their
changes
in
production
so
say
that
I
am
a
maintainer
on
a
project
with
somebody
else.
The
maintainer,
the
other
maintainer,
sets
the
animal
file
to
say
that
we
have
a
deployment
freeze
and
all
of
a
sudden,
I'm,
deploying
and
I
say
I
want
to
merge
something,
and
then
it
skips
the
deployment
to
production.
A
D
A
B
A
little
bit
tricky
because
the
way
I'm
envisioning
the
the
deployment
blackout
windows
to
be
implemented
would
be
kind
of
on
a
per
job
basis.
So
one
job
might
have
a
different
deployment
window.
Then
another
one
I
think
it
wouldn't
necessarily
be
a
project
wide
deployment
blackout
window,
but
I
guess
maybe
it
could
be
yeah.
A
C
B
A
Should
build
it
yeah,
because
I
could
see
that
there
might
be
a
project
that
has
multiple
production
environments
or
multiple
protected
environments
and,
as
a
result
they
may
say
I
only
want
people
using
this
environment
during
these
days.
Is
that
could
see
that
use
case
being
a
thing
there
which
might
make
it
harder
to
implement
or
I
guess
and
they
Alafia
would
still
work
the
same.
They
would
just
specify
that
variable
right,
like
skip
this
during
this
window,.
B
B
So
yeah
I
feel
like
they're,
definitely
be
some
some
way
to
like
we
could
parse
the
whole
file.
If,
if
it's
a
kind
of
attached
to
the
environment,
I
don't
think
it'd
be
a
huge
problem
to
pull
that
out
of
the
whole
file
display,
that's
somewhere
in
the
UI
I.
Don't
know
if
we
do
that
now,
so
it
might
be
a
little
bit
bigger
of
an
undertaking
to
show
that
kind
of
status
message.
C
A
Now,
I'm
curious
a
little
bit
more
about
how
we
would
go
about
like
specifying
to
users
to
update
their
EML
files
if
they
want
to
include
a
deployment
window.
Would
this
just
be
like
a
sample
template
for
them
to
leverage,
and
then
they
bring
it
into
their
project
or
how
do
we?
How
do
we
support
that.
B
My
thought
was
to
start
with
I
think
we
would
just
need
to
document
it.
Probably
in
the
I
can
close
this
little
section
in
the
environment.
Yamo
reference
like
this
is
kind
of
the
go-to
spot.
Everyone
would
look
for,
look
to
and
developing
the
ammo
file,
so
if
they're
working
in
environment
as
long
as
it's
documented
there
they'll
be
aware
of
it,
that's
probably
be
a
first
step.
Okay,.
A
B
A
A
B
A
If
it's
like
a
reoccurring
deployment
freeze,
so,
for
example,
someone
specifies
in
their
animal
files,
they
only
want
deployments
to
occur
Monday
through
Friday,
or
you
can't
deploy
to
production
and
Saturday
and
Sunday,
because
those
would
be
the
same
thing
right
that
people
know.
People
are
aware
that
that
is
set.
So
how
do
we?
Let
people
know
that
that
reoccurring
window
is
set.
B
A
A
We
would
want
this
to
be
a
setting,
so
people
can
turn
it
on
or
off
because
they
may
not
care,
they
may
only
work
Monday
through
Friday
and
therefore
the
deployment
is
irrelevant
for
them.
Unless,
if
it's
an
ad-hoc
deployment
window,
then
we
could
just
I,
don't
know
how
we
would
again
I'm
worried
about
the
the
dinner
ability
and
people
who
are
sharing
projects.
Yeah,
there's
like
one
maintainer,
there's
500
people
working
on
a
project
like
does
that
maintainer
make
sure
that
their
people
are
aware
that
this
is
happening.
A
D
Because
I
think,
if
you're
gonna
do
that,
we
should
also
make
an
update
in
the
project
settings
just
to
add
that
this
is
a
option
or
one
of
the
default
options
in
the
when
you
decide
to
subscribe.
So
we
could
be
like
by
default.
Active
right,
so
we'll
always
receive
notification.
One
of
the
like
a
period
is
a
is
such,
but
then
you
can
decide.
You'll
subscribe.
A
I'll
think
about,
if
that's
necessary,
for
this
first
iteration
or
if
that's
a
fast,
follow
because
I
think
like
we
could
say
yeah.
We
support
deployment
freezes
now,
but
you
are
responsible
for
building
people
know
that
you're
doing
that
or
we
say
notifications
are
a
premium
and
ultimate
offering.
Given
that
that's
a
larger
organization,
unless
one
man
projects
one
person,
projects,
sorry
that
was
really
gendered,
so
I
think
I
could
we
could
schedule
those.
A
B
A
Okay
I
like
that,
and
then
we
can
learn
high
on
once
we
go
into
our
environment
survey
and
jobs
to
be
done.
If
that's
an
experience
that
people
are
really
hating
like
that,
I
don't
know
in
a
deployment
like
I.
Don't
know
why
my
deployment
skips
when
somebody
else
like
so
that
would
be
the
experience
of
someone
a
developer
on
a
project.
When
a
maintainer
set
the
deployment
freeze
in
the
CIA
yellow
file,
they
would
show
they
would
just
see
that
they
skipped
deployment,
yeah
and
and
if
it's
automatically
set.
A
So
this
could
be
a
set
and
forget
thing
to
write
like
it
should
be
designed
that
if
you
want
to
support
a
reoccurring
window
that
you
could
just
say,
I
only
want
these
pipelines
to
deploy
or
I
want
them
to
not
skip
Monday
through
Friday
like
I'm,
not
sure
how
how
we
want
to
like
say
that
in
the
front
end
there
does
need
to
be
some
realization
that
things
are
not
going
through
right,
whether
that's
reusing.
What
we
have
today,
they're
just
skips
or
a
deployment
fails
or
whatever
I'm
not.
A
D
D
At
7:00,
do
we
need
to
consider
time
zones
for
that
or
what's
the
base
timezone
like
I,
said
something
at
1:00
p.m.
my
time
will
would
that
have
an
impact?
Of
course
it
has
an
effect
on
how
people
see,
but
for
the
system
understand
that
as
the
starting
time
just
kind
of
trying
to
understand.
If
this
is
I
said.
B
That's
a
super
tricky
issue,
because
sometimes
you
want
it
one
way.
Sometimes
you
want
it.
The
other,
like
you
might
say,
I,
don't
want
this
to
be
deployed
on
15
and
then
that
kind
of
sounds
like
it's
15th
and
whatever
time
zone
you're
in
other
times,
you
might
say,
I
don't
want
this
to
play
at
2:00
p.m.
which
is
more
specific
to
my
time
zone.
B
A
Will
expect
if
they're
used
to
using
things
like
z-bo
labs
or
another
orchestration
tool
that
they
can,
that
has
the
system
has
the
awareness
of
their
time
zones?
You
know,
but
then
it's
implemented
across
everybody
else's
time
zone.
So
if
I
set
5
p.m.
here,
Ayana
that'll
be
10
a.m.
over
where
you're
at
or
you
know,
crowds
it'll
be
4
in
the
morning
like.
B
Yeah
I
think
that
that
makes
the
most
sense
is
that
you
would
set
it
in
your
local
time
and
then
it's
yeah
it'll
appear
it'll
be
rendered
in
whatever
time
when
you
look
at
it,
it'll
show,
whatever
time
you
saw
you're
in,
but
it
is
like
actually
pinned
down
to
a
specific
moment
in
time
yeah
and
it's
especially
important
because
if
you're
using
get
lab
comm
like
the
get,
the
actual
server
might
be
in
San
Francisco,
but
you're
in
China
or
something
so.
It
does
really
make
sense
to
use
like
the
server's
time.
A
The
context
of
the
user
will
be
important.
Okay,
I
got
to
get
to
another
meeting.
I'll
update.
This
call
out
of
comment
to
the
MVC
issue,
based
on
what
we
just
said
to
document
what
we
exchanged
here
and
then
we
can
iterate
on
those
comments
and
kind
of
get
this
MVC
buttoned
up
and
then
I'll
create
sub
issues
for
notifications
and
and
any
other
items
that
we
feel
like
you're
outside
of
the
scope
of
the
animal
creation.