►
From YouTube: Release Management Think Big #3
Description
Welcome to our Think Big #3 for Release Management!
We discussed:
1) Environments
2) Executable Runbooks
3) Deploy Freezes
A
A
A
B
C
Sure
so,
I
just
I
just
post
this
like
20
minutes
ago
so
I've
just
been
thinking
through
our
run
books,
feature
that
we're
hoping
to
implement
and
I'm
just
wondering
if
we've
considered
some
other
alternatives,
other
than
Jupiter
run
books
to
meet
the
business,
need
of
being
able
to
kind
of
execute
releases
and
like
manage
them
in
particular.
What
I
was
thinking
is
we
could
do
it
all
kind
of
in-house
if
we
augmented
our
like
our
markdown,
to
be
able
to
to
run
code
from
check
boxes
or
something
something
similar
to
that,
and
then.
A
First,
question
yeah,
so,
yes,
we
have
thought
about
that.
The
first
MVC
was
just
about
creating
a
connection
between
the
way
people
are
running,
run
books
today
and
from
the
customers
that
I've
spoken
to
Jupiter
was
kind
of
like
their
de
facto
standard.
Forget
lab,
but
really
this
link
could
be
a
blanket
URL
that
has
a
called
run
buck.
So
it's
like
another
asset
that
they're
just
adding
to
a
release
and
then,
as
we
get
more
information
about
what
people
are
linking
there,
we
would
be
able
to
then
distill
like
okay.
A
Well,
can
we
create
templates
in
the
ammo
file?
Can
we
look
at
other
ways
to
support
releases
more
fundamentally,
but
this
first
MVC
was.
It
was
twofold:
one
supporting
what
people
are
using
today
and
then
two.
Is
there
a
quick
way
to
generate
better
visibility
between
releases
and
run
books,
but
I
completely
agree
with
you
that
Jupiter
notebooks
will
not
be
the
only
way
that
we
support
run
books
in
the
future.
A
And
in
truth,
I
think
just
providing
a
link
and
the
ability
to
link
multiple
run
books
to
any
given
release
is
more
valuable
than
even
supporting
Jupiter
notebooks
at
first,
so
maybe
like
the
very
first
iteration
is
there's
a
design
for
multiple
links
to
assets
that
are
run
books.
Second,
design
is
more
in
a
Clarie
integrate
and
more
integration
with
Jupiter
notebooks.
Third,
is
you
know,
supporting
execution
of
running
code
from
check
boxes
in
the
ammo
file
or
whatever
file
would
make
whatever
file
make
sense?
A
C
Okay,
that's
cool
that
makes
sense.
I
was
thinking
that
it
feels
like
we're
kind
of
almost
abusing
Jupiter
notebooks
for
a
purpose
that
they
weren't
really
intended
like
we're,
trying
to
get
statuses
out
of
them,
and
that's
not
really
what
they're
intended
for,
but
that
kind
of
makes
sense
if
we're
just
supporting
existing
workflows,
rather
than
it's
not
so
much
that
we're
presenting
Jupiter
notebooks
as
like.
This
is
the
new
way
that
we're
going
to
recommend
everyone
do
releases
right.
A
It's
the
one
part
that
I'm
having
a
hard
time
with
is
collecting
data
on
the
types
of
notebooks
people
are
using
for
Jupiter.
Customers
haven't
provided
any
of
their
notebooks,
so
I
can't
really
see
like
how
are
they
breaking
up
their
notebooks
today?
What
kind
of
actions
are
they
taking
from
a
notebook
and
I've?
A
So
they
see
like
discrete
tasks
in
their
notebook
and
they
want
that
to
be
an
indicator
that
they're
able
to
deploy,
and
that's
kind
of
the
part
that
I
wanted
to
support
out
of
the
gate
and
kind
of
get
more
users,
giving
feedback
to
leveraging
run
books.
But
I
completely
agree
with
you
that
there's
probably
more
in-house
way
to
support
people
who
are
using
things
like
Excel
or
Word
documents
to
manage
their
workflows
and
Mike.
What
were
your
your
kind
of
thoughts
or
concepts
or
high
on
a
tooth
on
this
yeah.
B
It
was
more
like
I
think
that
thumbs
like
how
great
like
what
nathan
was
originally
suggesting,
you
know
kind
of
keeping
it
in
there
and
not
afternoon
you're
right
trending
towards
get
lab.
Is
the
solution
to
do
things
opposed
to,
like
you
know,
having
another
connection
to
this
outside
thing,
but
I
think
that
rises
and
falls
on
our
ability
to
that
execute
code?
How
hard
is
it
is
that
going
to
be?
Is
that
a
giant
leap
or
is
that
doable
was
was
really
what
my
questions
were
around
so
I?
Don't
I,
don't
know.
B
If
that's
an
answer
we
have
today,
but
definitely
like
you
know
the
approach
of
an
explanation
of
why
we're
going
down
the
path
we
do.
But
if
we
do
want
to,
you
know,
go
down
that
further
I
think
that
would
be
there.
That
would
be
the
research
spike.
Whatever
word
we're
using,
for
that
is
how
big?
How
big
is
that?
Because
if
it's
not
that
big,
it
would
be
fantastic.
A
Yeah
and
I
I
I
think
that
there's
two
risks
that
we
can
take.
We
can
say
that
we
prescribed
using
gitlab
to
manage
your
releases
with
our
get
lab,
run,
books
that
are
filed
as
a
part
of
your
release,
and
you
need
to
recreate
your
current
notebooks,
whatever
tool
you're
using
in
order
to
use
our
prescribed
way,
which
is
a
change
management
exercise
that
can
be
scary
for
people
that
are
having
to
uproot
the
teams
that
are
external
to
their
pipeline.
A
So
if
we
think
about
what
release
management
does
is
that
it
coordinates
a
bunch
of
activities
that
are
outside
of
the
direct
purview
of
the
engineering
team.
So
like
these
could
be
marketing
events.
These
could
be
update
a
separate
webpage.
These
could
be
release
your
press
conference
notes
and
then
there's
even
a
run
book
that
could
be
added
to
this
release
that
are
all
about
the
prep
before
like
make
sure
that
you
create
an
issue
or
you
send
an
email
to
all
the
product
managers
so
like.
A
When
we
look
at
everybody's
workflows,
we
can
see
that
the
adoption
of
a
gitlab
provided
solution
would
require
them
to
map
their
current
stuff
into
it
versus
just
allowing
them
to
add
whatever
they
wanted
to
to
the
gate.
Lab
releases
to
just
show
progress.
So
that's
the
other
kind
of
argument
is
incrementally.
How
can
we
beef
up
our
data
asset
on
how
people
want
to
see,
run
books
and
get
lap,
while
still
adding
value
for
execution
and
not
scaring
them,
because
the
scaring
part
will
cause
like
a
big
drop
in
our
adoption?.
B
B
And
then
one
other,
you
know
slight
drawback.
If
we're
gonna
go
kinda
more,
the
issue.
Kind
of
rally
is
one
thing:
that's
nice
about
Jupiter,
run
books,
and
just
this
idea
in
general
is
that
if
you
manage
it
as
code
that
goes
with
your
release
and
you
need
to
go
back
in
time.
There's
two
things
are
always
in
sync.
So
if
we
were
gonna,
go
the
whatever
other
route,
I
would
think
we
need
to
make
sure
it's
something
that
can
be
managed
as
code.
So
it's
always
in
sync,
with
the
release.
B
Does
that
run
book
is
only
valid
for
that
release.
Potential
I
mean
it
might
not
change
right.
Your
process
might
not
change,
but
it
might.
If
you,
you
know,
releases
one
through
three.
You
did
this
thing,
but
in
in
four,
you
made
this
giant
change.
No,
that
run
book
for
one
through
three
is
only
valid
for
one
point
three,
so
at
least
four
needs
to
be
synched
with
that
I
like.
A
A
Good
points
so
I
think
from
my
action
item
here
that
I
already
have
kind
of
like
as
it
to
do
our
to
create
more
issues
around
the
different
types
of
run,
books
that
we
want
to
support.
I
have
a
call
with
a
customer
today,
dan
Quist,
who
wants
to
use,
run
deck
to
support,
run
book
scripts.
So
he
might
be
a
good
candidate
to
understand
what
other
use
cases
for
run.
Books
are
there
that
we're
not
considering
as
a
part
of
the
release
architecture,
so
that'll
be
good.
A
As
a
note,
I
did
have
my
opportunity,
canvas
and
presentation
to
Scott
and
he
greenlit
it
and
approved
it
as
a
viable
investment
opportunity.
So
now
we're
good
to
just
dive
headfirst
into
making
it
a
priority
for
release
orchestration,
which
is
great
and
I'll
post.
The
video
in
our
release,
sock
channel
thanks
John
once
that
gets
posted.
D
D
A
A
B
A
C
If
we,
that
was
my
thought
to
kind
of,
is
that
if
we
attend
this,
generic
functionality
to
basically
run
run
code
inside
of
markdown,
and
we
would
we
could
use
it
for
releases,
but
we
really
could
use
it
for
for
anything
like
we
could
maybe
integrate
with
our
get
lab
API.
So
you
could,
you
could
create
buttons
that
could
automatically
close
issues
or
I,
don't
know.
Basically
anything
you
can
imagine
that
our
API
could
do.
You
could
somehow
build
it
into
an
issue
and
use
it
for
all
sorts
of
automation.
C
C
A
All
right,
I
think
that
would
really
help,
because
then
I
can
bring
it
to
also
the
other
product
managers
to
see
if
we
can
get
resources
for
other
teams
to
help
us
build
this,
because
I
think
this
could
be
a
really
big
benefit
to
our
relationship
with
milestones
and
releases.
So,
for
example,
hey
here's,
a
here's
executing
the
mass
assignment
or
mass
removal
of
certain
things
from
a
milestone.
If
it's
already
conducted
in
a
release
like
that
would
be,
you
know
something
that
we
could
help
bridge
the
gap
that
I
know.
A
D
Yeah,
this
is
a
quick
update
on
the
cells
of
the
release
user
interview,
so
this
is
related
to
the
UX
scorecard
at
the
jobs
to
be
done
with
it
last
year.
So
the
main
goal
is
to
understand
mostly
if
people
can
use
the
new
design
solutions.
So
a
lot
of
what
nathan
has
implemented
for
releases
over
the
last
I
don't
know
two
to
three
months
anymore
and
based
on
the
results.
D
We
want
to
evaluate
the
scorecards
so
great
that
we
assign
so
there's
a
great
firm
ranges
from
A
to
F
and
during
my
heuristic
analysis,
I
assign
an
F
because
well
we
cannot
create
a
release
from
the
UI,
so
that
was
the
main
to
be
done
and
there's
a
lot
of
water
boy.
It's
there
when
we
have
three
participants:
the
steam
one
user
interview
scheduled
for
this
weekend
in
Friday.
D
So
if
any
of
your
folks
want
to
watch,
Arden,
Jackie
and
Laura
died
right
in
there
feel
free
to
to
join
our
call
and
I
believe
that
many
of
our
assumptions
were
already
confirmed
already
correct
and
they
match
a
lot
of
the
UX
work.
Our
recommendations
that
I
made
last
year
for
the
releases
page
so
they're
moving
in
the
in
the
right
direction.
The
next
step
is
really
go
and
dive
into
the
the
opportunity,
canvas
and
see
together
with
the
with
Jackie.
How
do
you
want
to
tackle
this?
D
A
By
the
way,
I
really
like
those
user
interview,
experiences
I
think
it
is
a
really
cool
opportunity
for
us
to
learn
how
people
are
perceiving
what
we
filter.
What
we
thought
we
were
building
I,
love,
I
love,
a
town,
I
love
attending
those
I
would
say,
I
learned
just
so
much
from
how
other
people
perceive
these
things.
So
that's
really
cool
another
quick
update
before
I
dive
into
the
environments,
jobs
to
be
done.
A
I
do
have
the
blackout
periods
presentation
to
Scott
next
week,
the
biggest
of
and
it's
going
to
be
called
deploy
freezes
because
that's
what
our
survey
said
that
you
know
75%
of
people
call
them
deploy
freezes
and
the
reason
why
I
don't
want
to
start
diving
into
a
bunch
of
technical
implementation,
details
or
a
solution.
Validation
like
we
did
with
run
books
prior
to
presenting
this
problem
is
that
it
goes
against
potentially
what
we
would
want
to
support
at
get
lab.
A
It
kind
of
bifurcates
like
for
people
who
have
a
bunch
of
automation
and
are
all
about
their
CI
CD
pipeline.
Getting
more
automated
and
more
nimble
and
requiring
a
twirl
deployments
blackout
period
doesn't
make
sense,
but
for
these
enterprises
that
have
this
legacy,
workflow
blackout
periods
are
a
part
of
their
normal
life.
So
it
really
is
to
user
groups,
and
there
really
isn't
anybody
in
between
they
either
do
it
or
they
don't
do
it
it's
binary.
So
we
have
to
assess
if
well,
I've
already
assessed
it.
A
We
have
to
determine
if
implementing
something
like
the
ability
to
configure,
deploy,
freezes
or
windows
of
time,
where
you
can't
deploy
to
production
environments
goes
against
our
ethos
at
gate
lab
or
if
the
ability
to
support
these
kinds
of
actions
is
important
and
integral
for
transitioning
customers
to
deploying
all
the
time
whenever
they
want
in
a
high
available
way.
So
after
I
present
to
Scott
we'll
have
a
good
idea
of
if
it's
worth
investing
in
and
if
it
is
and
we'll
figure
out
what
it
makes.
A
Sense
and
I
think
Nathan,
you're
kind
of
on
the
front
end
for
it
kind
of
to
evaluate
and
think
well
with
it.
What
would
that
look
like
what?
How
would
me
what
would
we
need
from
back-end
to
make
that
happen,
but
it
would
be
interesting
to
to
make
that
story
in
the
market,
because
right
now,
that's
kind
of
killing
us
when
we
go
head-to-head
with
zbo
labs
or
other
tools
that
are
built
from
the
bottom
up
and
release
orchestrations
and
so
I'll.
Keep
you
guys
posted
on
that
and,
of
course,
to
share
it
with
you.
C
But
one
a
one
thought
I
had
when
I
was
looking
over.
That
issue
is
that
there's
some
way
we
could
solve
it?
I
don't
get
hijackings
me
too
much,
but
all
right
there
I
can
see
us
solving
it
really
simply
by
just
adding
like
a
new
keyword
in
a
in
a
get
get
lab.
Llamó
file
Mike
only
deploy
Monday
through
Friday
or
something
like
in
your
actual
Gil
a
file
yeah.
E
C
I
also
saw
somewhere
that
it
in
one
of
the
requirements
that
it
said
that
the
people
that
are
defining
these
kind
of
blackout
windows
aren't
necessarily
the
developers
and
aren't
necessarily
comfortable
with
editing
yeah
Mille.
So
in
my
head,
that's
kind
of
the
split
is
either
we
do
it
in
the
ammo
file
or
we
have
to
build
the
kind
of
separate
UI
where
this
would
be
managed
and
that
one
would
be
more
significantly
more
work.
I
think
do.
C
A
C
Down
like
we
already
have,
in
fact
we
could
make
it
I
can
almost
do
it
already
today
with
too
much
modification,
because
we
already
say
certain
pipelines
to
only
run
versus
on
certain
variables.
So
we
could
add
a
new
variable
like
day
of
week
or
something
you
could
say,
only
run
yeah
if
the
day
of
week
is
Monday
through
Friday
and
Abby,
I
would
think
that
would
be
very
minimal
in
terms
of
the
actual
work.
E
E
Example,
I
have
a
pipeline
scheduled
that
runs
it
that
runs
at
like
4:00
a.m.
every
day,
and
then
it
runs
through
my
gate
line,
yellow
file
and
there's
a
schedules.
Keyword
that
just
triggers
like
just
do
this
part
of
my
get
lab
yellow
file
during
this
block
of
time.
Is
that
kind
of
similar
to
what
what
we're
thinking
or
did
I
totally
miss
there.
So.
A
Deploy
windows
would
be,
we
don't
want
to
allow
a
push
to
production
and
I.
Think
pipeline
schedules
are
more
about
running
on
certain
conditions
being
satisfied,
but
I
just
saw
the
link
so
I'm
gonna
open
it
up
right
now
and
post
it
in
our
agenda,
so
yeah.
Here's
here's
an
example,
here's
a
use
case
and
tell
me
if
maybe
maybe
it
does
work
but,
for
example,
a
user
has
a
team
that
they
don't
want
to
deploy
to
production
on
Friday,
but
they
still
want
all
of
the
test
Suites
and
the
cia-run.
A
So
they
would
say
nobody
can
deploy
onto
production
environment,
but
everything
else
up
into
production
would
work.
Potentially
that
could
be
a
use
case.
This
is
where
I
don't
think
the
scheduling
pipelines
would
work
because
it's
like
all
or
nothing,
you
can't
run
your
pipeline
or
you
will
run
your
pipeline.
Whiskey.
E
E
I
think
is
what
how
you
can
kick
that
out,
but
I
think
to
Jackie
I
think
maybe
pipelines
the
scheduling
pipeline
doesn't
actually
solve
this
problem
because
that's
looking
at
it
from
hey
I
want
this
to
happen
at
a
certain
time
every
day
or
whatever
and
I
think
what
you're
saying
is
you
want
folks
to
be
able
just
run
things
as
normal,
but
you
want
to
kind
of
block.
You
know
deployments
to
production
on
Friday
right,
so
yeah.
A
Nobody
can
accidentally
deploy
to
production,
because
that's
a
risk
here
is
that
you
have
a
fully
automated
pipeline
developers
could
be
merging
back
to
master
whenever
we
could
say
that
you
always
want
to
deploy
for
a
master,
so
your
process
could
stay
the
same,
but
you
just
want
to
prevent
that
deployment.
Yeah.
E
A
What's
cool
is
we
can
paint
the
picture
of?
How
do
you
use
pipeline
scheduling
in
conjunction
with
a
deployment
freeze
to
facility
automated
deployments
so
like
there's
that
narrative
you
can
create
in
the
documentation,
but
I
I
feel
like.
There
are
two
sides
the
same
coin,
but
one
is
about
not
the
point
of
production
and
having
people
still
use
the
process.
It
just
doesn't
allow
you
to
make
changes
to
that
last
environment,
cool
thanks.
A
Good
thoughts
there,
okay
I'll,
add
a
comment
back
Nathan
on
the
black
cup
period,
MVC
that
kind
of
documents
what
we
just
talked
about-
and
you
can
let
me
know
if
I
repeat
that
back
correctly
and
then
we
can
get
somebody
on
the
backend
to
take
a
look
at
it
and
see
like
what
changes.
Would
we
potentially
want
to
make
from
this
side?
And
that
could
be
our
first
MVC
if
Scott
feels
like
we
want
to
support
this
as
a
product
vision?
A
A
Okay,
so
I
created
this
issue
in
the
UX
research.
The
whole
ethos
of
this
is
about
understanding
how
people
are
using
environments
so
that
we
could
even
establish
a
job
to
be
done,
because
we
have
a
couple
of
different
assumptions
and
a
hypothesis
that
people
aren't
using
environments
because
there's
certain
perceptions
of
security
or
other
issues
related
to
deploying
with
get
lab.
So
I
want
to
really
dig
into
why
people
aren't
using
environments
or,
if
they're,
using
environments,
how
they're
using
them
so
I've
gone
in
the
head
and
added
some
hypotheses
here.
A
We
can
discuss
them
right
now
and
kind
of
get
your
guys's
feedback
on
what
you
know
about
environments,
and
if
this
is
something
that
you
think
is
important
to
to
drill
into
so
the
first
part
of
it
is
I
suspect
that
people
aren't
using
environments
as
intended
or
as
much
as
we
would
expect
them
to
be
using
them.
So
our
expectation
is
if
you
can
deploy
anywhere.
A
A
The
second
one
is
that
environments
are
not
necessary,
so
there's
something
in
our
documentation
or
something
and
how
its
setup
that
people
are
not
feeling
compelled
to
use
environments,
and
then
users,
just
don't
really
get
the
value
of
it.
So
this
could
be
a
conversation
in
a
blog
post.
This
can
be
people
just
don't
know
all
the
feature,
functionality
that
we
have
available
in
environments,
but
either
way
they're
not
using
them
in
the
amount
that
we
thought
they
would
be.
B
They're,
potentially
the
forth
one
that
they
are
actually
using
environments
they're,
just
not
defining
them
right,
so
the
environment
can
live
outside
of
gitlab.
If
you're
deploying
to
AWS
or
something
like
that,
and
if
you're
not
sending
up
your
yeah
one
of
them
correctly,
then
we
might
just
not
be
aware
of
the
environments
when
they
actually
are
I.
C
Now,
although
some
hypothesis
points
kind
of
resonate
like
it,
intuitively
I
feel
like
those
are
all
correct,
I
know
for
me,
this
before
I
joined,
get
lab.
I
was
working
on
a
project
that
used
a
DevOps
and
they
that
piece
of
software
has
a
much
more
distinct
split
between
CI
and
CD.
It's
like
two
separate
tabs
like
one
is
build.
One
is
release
and
they're
completely
like
separate
concepts
which
obviously
has
its
disadvantages,
but
it
also
makes
it
more
obvious
that
you're,
like
doing
release
focused
things
rather
than
we
kind
of
mix.
C
A
That
makes
sense
so,
when
I
take
a
step
back,
the
biggest
goal
is
to
get
more
people
using
environments
and
allow
us
to
build
features
incrementally.
So
today
we
have
a
very
hard
time
identifying
even
what
jobs
people
are
trying
to
do
with
environments.
We
tried
to
like
spit
ball
that
in
our
last
UX
PM
meeting
and
I
was
hitting
a
wall.
A
It's
like
what
do
people
really
want
to
do
is
environments,
so
I
think
that
the
biggest
goal
here
is
to
really
gain
traction
with
environments,
and
that
gives
us
a
line
of
sight
to
then
increase
our
CD
suite
and
our
sweetie
use
CD
users.
Do
you
see
any
other
goals
that
we
might
want
to
add
to
this
survey.
A
Okay
on
the
objectives,
these
are
a
little
bit
more
tangible,
very
specific
to
what
we're
hoping
to
get
out
of
answering
specific
questions
and
identifying
the
hypotheses
with
environments.
The
ones
that
I
threw
on
here
were
about
the
perception
of
environments,
understanding.
What
are
the
bare
minimum
features
that
need
to
be
in
an
environment
page
and
then
what
are
the
roadblocks?
Are
there
other
objectives
that
we'd
want
to
get
from
the
survey
I
could
think
of
identify.
If
we
need
to
split
out
the
CICE
capability
of
environments,
we
could
whoa
yelling
at
me.
B
Okay,
I
think
we
just
like
the
management
of
it
right,
I'm,
not
sure
how
to
verbalize
it
properly
but
like
what
we
really
need
to
know.
I
think
is:
what
do
we
need
to
give
them
to
be
able
to
manage
them
right?
So
using
them
is
one
side
of
it,
but,
like
the
tool
we
provide
is
the
management
of
those.
B
A
We
talked
a
little
bit
about
this
in
our
CIC
DPM
group
call
today
where
we
were
looking
at
progressive
delivery
and
release
capabilities
as
an
offering
forget
lab
and
one
of
the
pieces
that
came
out
of
it
are.
Are
we
not
competing
with
custard
with
a
with
customers
who
are
using
spinnaker
or
interested
in
using
spinnaker,
or
have
you
spinnaker,
because
we
don't
support
things
like
blue
green
deployments
or
rollbacks
natively?
Are
there
other
issues
that
are
causing
environments
like
in
sepia
labs?
A
A
You
know
what
are
external
factors
that
we
need
to
keep
in
mind
with
environments
like
if
you're
using
specific
cloud
providers,
are
there
different
ways
that
we
have
to
configure
environments
and
is
that
a
limitation
I
also
have
the
question
on
why
I
mean
what
would
we
want
to
do
to
make
this
a
little
bit
more
desirable,
the
feature
set
and
the
baseline
of
how
difficult
is
it
to
use
it
today?
What
else
would
you
want
to
kind
of
answer?
A
D
A
So
it's
interesting
to
like
review
apps
can
be
considered
a
different
environment,
a
dynamic
environment,
and
when
we
look
at
how
we're
evaluating
environments,
we
could
potentially
make
this
very
focused
on
how
people
want
to
support
production
environments
rather
than
something
like
tester
other
environments
interested
in
kind
of
looking
at.
Do
we
want
to
subset
this
or
have
a
deep
focus
on
a
particular
type
of
environment
use
case
rather
than
environments
in
general,
I.
D
A
I've
heard
that
it's
challenging
to
manage
environments,
because
we
can
only
do
certain
things
in
the
front-end
like
you
can
create,
but
you
can't
delete
and
that's
something
that
people
have
cited
as
being
an
annoyance
I
mean
we
added
that
delete
a
UI
delete,
an
environment
in
the
UI
as
a
functionality
for
12.7
in
the
slipped
into
12.8.
But
that's
like
I
know.
That's
a
pain
point
today.
May
that
management
side
of
it.
B
A
Okay,
well,
this
was
a
good
thing.
Big
session
I
think
we're
actually
at
time
right
now,
but
I
think
from
an
action
item.
Next
steps:
Nathan.
If
you
can
create
that
one
issue
about
allowing
code
to
be
executed
from
the
markdown
I,
think
we'd
be
able
to
start
some
conversations
on
that
I'll
ping,
you
on
the
other
issue,
to
get
some
identification
on.
How
else
can
we
support
other
blackout
periods
with
either
specifying
anything,
a
mold
and
overlaying
a
UI
on
that?