►
From YouTube: Feature Flags Deep Dive
A
So
today
we
want
to
talk
about
feature
flags
and
I'm
going
to
do
something
similar
like
we
did
in
the
cd
we're
going
to
go
through
the
direction
page,
and
you
know
stop
me
at
any
point.
If
you
have
any
questions
so
so,
let's
start
so
really
basic.
I'm
going
to
skip
all
this,
and
just
say
this
in
in
the
tl
dr
fashion,
we
have
feature
flags
which
either
enable
or
disable
features
to
be
active
for
specific
users
on
a
specific
environment.
A
So
that's
just
really
simple
way
of
thinking
about
feature
flags,
though
the
really
nice
thing
about
feature
flags
is
that
it's
on
there's
a
few
really
nice
advantages.
One
of
them
is
that
it's
in
a
logical
view,
and
since
you
basically
create
feature,
flies
inside
your
code,
they're
very
closely
tied
to
your
application.
So
the
rules
that
you
can
set
for
audience
to
see
feature
flags
can
be
based
on
your
application
and
it
doesn't
have
to
be
based
on
you
know
like
ip
addresses
or
some
subnet
or
traffic
routing
like
in
different
deployment
strategies.
A
Here,
let's
say
that
you
are
you
created
an
application
that
lets
you
create
playlists
for
songs,
and
you
want
to
identify
specific
users
that
have
over
200
songs
in
their
playlist.
As
I
don't
know,
like
heavy
users,
you
can
enable
specific
features
just
for
that
kind
of
user
based
on
your
application
logic.
So
that's
really
really
cool
and
another
really
neat
feature
that
feature
flags
has
is
that
it
is
done
in
runtime.
So
you
can
change
the
rules
at
any
given
time
on
the
fly
without
the
need
to
redeploy
your
entire
pipeline.
A
So
that's
really
powerful
and
it
gives
you,
the
users
developers
a
lot
of
flexibility,
so
that
was
just
a
tl,
dr
for
everything
that
was
written
here
and
we
have
a
bunch
of
links
on
the
direction
page.
So
you
can
see
the
maturity
plan,
the
issue
list,
the
ux
research
documentation
and
there's
even
a
deep
dive.
Video
which
is
similar
to
what
we're
doing
now,
but
it
was
recorded
back
in
july,
so
it's
always
good
to
update,
but
whoever
wants
can
go
back
and
and
take
a
look.
A
So
future
flags
was
a
super
critical
pillar
in
progressive
delivery.
It's
one
of
the
main
functionalities,
because
when
you
think
about
progressive
delivery,
the
idea
is
that
you
want
to
make
small
increments
of
changes
to
your
code.
Visualize
them
get
some
feedback
and
then
decide
whether
or
not
you
want
to
expand
the
audience
that
gets
it.
So
featureflex
is
a
really
neat
way
to
do
it,
because
you
really
can
control
the
audience,
get
the
feedback
and
decide
whether
or
not
you
want
to
continue
rolling.
B
A
The
feature
so
this
was
super
critical
when
we
were
just
the
progressive
delivery
team.
Now
that
we're
the
combined
release
team,
I
think
the
priority
is
going
to
go
down
a
little
bit
because
we
mentioned
that
cd
is
going
to
be
top
priority
of
the
team,
but
we're
not
going
to
like
completely
ignore
feature
flags,
so
feature
flags.
I
think,
will
take
a
second
chair
and
compared.
A
Up
until
today,
but
I
still
see
us
consistently
delivering
a
big
feature:
every
quarter,
okay,
so
what's
next
and
why
it's
funny?
This
was
actually
de-prioritized
due
to
the
latest
realignment,
but
we
recently
added
a
functionality
to
create
user
lists,
which
is
a
fancy
way
to
create
user
id.
So
we
have
a
strategy
and
we'll
talk
about
strategies
in
a
minute
what
it
means,
but
we
have
a
strategy
called
user
id
which
lets
you
for
specific
users
enable
that
specific
feature.
A
So
we
could
have
a
feature
that's
only
enabled
for
nicole
and
reid
and
then
for
everyone
else
is
disabled,
but
when
which
is
really
nice,
when
you
have
a
small
set
of
users,
but
when
you
have
a
ton
of
users,
adding
individual
users
is
a
pain
and
you
may
want
to
reuse
that
list.
So
let's
say
you
enable
something
for
your
qa
team.
A
You
don't
want
to
keep
copying
the
same
names
you
can
you
want
to
have
a
list
that
you
can
reuse,
so
we
introduced
the
concept
of
reusing
user
lists,
but
sometimes
when
you
create
a
new
user
list,
it
may
be
a
subset
or
minor
changes
between
lists,
so
you
want
to
copy
and
paste
users
from
one
place
to
another.
So
this
feature
was
what
what
we
were
intended
to
do,
which
was
allowed
to
copy
the
list.
So
you
can
duplicate
user
lists
and
then
make
fine-tuned
changes.
A
Our
current
maturity
plan
isn't
viable,
so
it's
pretty
early.
We
may
be
at
a
point
where
we
can
advance
this,
but
this
definitely
needs
some
user
research.
In
order
to
to
decide
that
I
have
a
maturity
plan
here
listed
out
in
a
similar
way
that
I
did
continuous
delivery.
So
on
the
top
here
you
can
see
epics,
and
here
you
can
see
a
bunch
of
issues
that
are
related
to
that
specific
epic.
A
The
way
that
I
think
of
epics
here
is
like
a
bucket,
so
the
first
bucket
is
feature
flag
strategies,
and
so
a
strategy
is
different.
Rules
like
we
mentioned
that
you
can
enable
the
feature
for
so
we
had
a
really
big
refactoring
that
we
worked
on
this
year,
which
allowed
to
support
multiple
strategies
for
flag
and
also
multiple
strategies
per
environment,
but
also
separating
different
strategies
for
different
environments,
they're,
really
giving
you
a
lot
of
flexibility.
A
A
We
also
enhanced
on
that.
So
percent
robot
in
the
past
would
only
work
for
users
that
are
logged
into
your
application
because
it
was
based
on
the
user
id
and
it
didn't
really
work
for
anonymous
users.
Now
that's
a
really
big
limitation,
especially
when
you
want
to
do
a
b
testing
and
a
b
testing
is
more
around
volume
of
users
and
not
necessarily
specific
users.
So
we
introduced
this
flexible,
rollout
strategy
that
allows
you
to
set
not
only
the
percent
of
users,
but
also
what
you
want
to
base
your
stickiness
on
or
consistency.
A
A
Okay,
so
this
basically
lets
the
user
do
whatever
they
want.
You
can
do
it
based
on
tiers
or
based
on
domain
or
based
on
geolocation.
Anything
that
your
application
knows.
You
can
create
your
own
custom
rule
and
then
have
the
flag
enabled
by
that
ability
to
exclude
feature
flags
for
specific
users.
There's
actually
a
way
to
do
that
today.
It's
kind
of
a
hacky
way,
but
this
is
just
nicer
so
similar
to
the
fact
that
you
have
user
lists
that
you
can
able.
A
You
can
just
use
that
same
user
list
and
disable
that
feature
with
them,
so
it's
it'll
be
enabled
for
anyone,
but-
and
there
is
a
way
to
do
that
today
and
this
one
is
really
interesting-
it's
called
constraint
based-
and
this
allows
you
to
combine
several
strategies
together.
So
you
can
see.
This
is
what
unleash
has
and
we
have
kind
of
a
mock-up
that
I
created,
which
is
pretty
ugly,
but
it
kind
of
conveys
the
magic
message
where
you
can.
A
A
And
this
one
already
andrew
weighed
and
and
this
is
ready
to
go,
but
I
think
it's
going
to
be
a
while,
because
I'll
talk
about
priorities
in
a
minute,
then
we
have
feature
flag
context
with
git
lab,
and
this
is
actually
going
to
be
a
main
focus
in
the
next
coming
year.
I
had
an
analyst
review
last
week,
I'm
not
going
to
mention
which
one,
but
it
was
around
feature
flags
and
a
b
testing,
and
one
of
the
main
points
when
I
described
the
vision
and
what
we
have
supported
today.
A
So
one
of
the
main
points
that
he
had
mentioned
was
that
the
biggest
benefit
of
using
feature
flies
within
gitlab
is
the
context,
because
we
can
build
everything
into
the
pipelines.
We
can
bring
all
this
information
from
different
areas
from
the
source
code
from
the
issues
from
the
mars,
and
it
brings
a
lot
of
benefit
for
the
users,
so
we
recently
moved
featureflex
to
core.
A
This
is
going
to
be
the
context.
It's
still
going
to
be
a
paid
feature,
but,
besides
being
a
paid
feature,
it's
also
something
that
is
really
great
for
gitlab
and
it
really
shows
the
benefit
of
a
single
tool
application.
So
this
is
the
epic
now
and
underneath
it
you
can
see.
I
have
currently
five
different
issues.
One
of
them
is
semi-complete
ad
ability
to
associate
feature
flags
with
contextual
issues.
A
So
today,
if
you
added
a
feature
file,
there's
an
area
where
you
can
link
issues,
so
you
get
the
link,
then
we
have
add
ability
to
associate
feature
flag
with
connectual
and
mars.
So
that's
similar.
You
can
similar
to
how
you
link
today
to
nmr.
You
can
link
the
feature
flag
itself
and
then
epics.
It
will
be
the
next
one.
A
A
You
need
to
kind
of
copy
this
down
somewhere
open
another
tab
to
the
code
and
work
side
by
side,
but
it
would
be
really
convenient
if
we
could
just
show
you
exactly
where
the
code
is
directly
from
gitlab
or
from
the
feature
flag
itself,
and
that
would
let
you
make
any
changes
that
you
want
to
do
so.
Let's
say:
let's
say
you
want
you're
doing
you
have
a
feature
flag
and
the
feature
flag
has
to
do
with
something
with
the
ui
and
it
changes
the
the
background
color
to
green.
A
But
then
you
decided
that's,
not
the
color.
You
want
I'm
just
making
this
super
simple.
This
can
be
like
a
thousand
different
examples,
but
then
you
decided
you
wanted
to
change
the
color
from
green
to
red.
So
so
you
could
just
go
into
the
code
and
just
change
it,
whether
it's
a
hex
value
or
or
you
know,
just
text,
you
could
just
go
to
the
code
and
change
it
in
launch
darkly.
A
You
have
the
snippet,
but
launch
darkly
doesn't
have
the
source
code,
so
you
have
to
go
back
to
the
other
tool,
find
this
code
and
then
change
it.
So
it's
still
inconvenient
we
can
just
make
it
so
much
more
accessible
to
the
user
and
the
way
that
I
was
envisioning
with
this
was
very
similar
to
the
way
that
we
see
code
diff
today.
A
A
So
I'm
really
really
excited
about
this
one
in
case
you
didn't
tell
you
can't
tell,
and
then
we
have
get
feature
flex
to
enterprise
grade.
This
has
a
bunch
of
different
areas.
This
is
actually
very
similar
to
everything
that
we're
dealing
with
with
release
orchestration
and
segregation
of
duties
and
everything,
so
basically
there's
protected
environments
and
unprotected
environments,
and
we
kind
of
need
to
figure
out
how
we
can
protect
those
environments
also
from
someone
toggling
flags.
A
A
So
realistically,
I
think
we'll
get
around
to
this
in
q2
if
we
don't
start
working
on
this
in
q1,
but
this
is
definitely
something
coming
up
very
soon
move
feature
flex
decor.
This
is
actually
complete,
so
I
need
to
update
the
page
and
the
next
two.
I
couldn't
really
find
a
good
bucket
for
them,
so
they're
on
their.
B
A
The
first
one
is
a
b
testing
based
on
feature
flags,
and
this
is
a
whole
topic,
and
it's
it's
one
that
we've
done
extensive
research
about.
We
created
this
as
an
epic
and
there's
a
lot
that
we
want
to
do
recently.
Shinya
created
an
poc
for
a
b
testing
and
since
it's
not
such
a
large
effort,
I
think
we'll
also
pursue
this.
A
First
of
all,
it's
not
very
intuitive
to
look
for
feature
flags
under
operations,
so
we're
pretty
sure
it's
not
in
the
right
place.
We're
not
sure
where
the
right
place
is.
Maybe
it's
the
icd,
maybe
somewhere
else,
but
there's
also
a
lot
of
things
that
are
missing
from
feature
flags
today,
I'm
going
to
point
out
some,
but
there's
a
lot
more,
that
you
can
read
up
on.
A
First
of
all,
there's
no
area
to
collaborate.
So
if
your
team
creates
a
feature
flag,
there's
no
way
for
you
to
write.
I
did
this.
I
chained
this
whatever
there's
really
no
place
for
discussion
that
we
have
today,
which
makes
it
really
difficult,
and
especially
when
we're
talking
about
a
b
testing
collaboration
is
key
and
a
lot
of
people
are
involved
in
those
a
b
tests.
I
think
a
lot
of
people
are
also
involved
in
feature
flags,
but
it
didn't
come
up
as
a
as
much
as
it
did
in
the
research
for
a
b
testing.
A
Like
there's
a
bunch
of
missing
metadata
that
we
don't
have
existing
today,
I
created
a
competitor
analysis.
I
know
I'm
jumping
a
little
bit
linked
in
this
epic,
so
there's
a
bunch
of
features
that
that
launch
darkly
has
and
we
either
have
or
don't
have
them,
but
some
of
them
seemed
like
very
basic.
A
I
talked
about
this
today
and
I
found
everything:
okay
feature:
flag,
maintainer.
So,
for
example,
let's
say
I'm
an
sre
and
I'm
in
charge
of
production,
but
I
have
nothing
to
do
with
this
feature
flag.
Someone
on
some
team
created
a
feature
flag
that
they
saw
their
specific
flat
feature,
and
I
don't
know
the
feature
flag
is
giving
me
problems
and
I
don't
know
what
to
do
with
it.
Can
I
turn
it
off?
A
Do
I
need
to
talk
to
someone
before
there's
really
no
way
for
me
to
know
that
today,
so
charlie
has
something
very
similar
where
you
have
like
someone
as
an
owner
of
the
flag,
so
an
sre
can
know
who
to
contact
in
case
there's
something
wrong,
but
that
really
looks
like
the
signee
to
me,
which
is
very
similar
and
then
another
one
was
tags.
So
if
you
can
tag
different
feature
flags
in
different
ways,
it
just
makes
it
really
really
easy
to
to
know.
A
Either
you
can
tag
an
environment
or
you
can
tag,
I
don't
know,
let's
say
it's
a
let's
say
it's
feature
flag,
that's
enabled
for
premium
users,
or
I
don't
know
different
scenarios.
Also,
once
you
have
many
many
feature
flags
in
your
system,
it's
a
nightmare
to
manage.
So
this
is
like
a
pre
work
to
one
day
when
we
can
do
sorting
and
filtering
and
other
stuff.
A
But
what
would
you
sort
and
filter
by
so
this
is
one
of
the
options
is
doing
it
by
labels
and
that's
kind
of
how
we
do
sorting
and
filtering
today
and
issues,
and
I'm
sure
that
you
do
that
on
your
day-to-day
basis.
So
I
thought
it
would
be
really
cool
if
we
could
import
labels
into
feature
flags
and
when
I
started
creating
this
list
I
was
like.
Oh
man.
This
sounds
like
an
issue.
A
Why
can't
we
just
reuse
what
we
have
in
the
issue
and
just
have
feature
flags
as
an
issue.
So
that's
what
this
specific
issue
is
talking
about
and
that's
creating
feature
flags
is
an
issue.
The
the
monitor
team
recently
added
incident
as
an
issue
type
and
the
release
management
team
was
talking
about
doing
this
something
similar
for
run
books.
So
this
is
kind
of
along
that
same
line
where
I
think
more
and
more
things
are
going
to
become
issue
types
on
their
own
first-class
citizens,
and
so
that
was
what
I
was
envisioning.
A
A
I
think
it's
going
to
be
a
lot
of
work,
there's
a
question
whether
we
need
to
start
top
down
so
just
copy
an
issue
and
then-
and
then
you
know
hide
it
behind
the
feature
flag
start,
adding
all
our
stuff
wait
for
it
to
be
mature
and
then
start
rolling
it
out
or
the
other
way
around.
Add
labels
adjust
the
the
create
date.
A
So
if
I
have
an
issue
type
of
feature
flag-
and
I
have
a
code
that
links
the
mr
to
the
feature
flag,
everything
just
becomes
so
much
simpler.
I
don't
want
to
say
free
because
andrew
doesn't
like
me
to
say
free,
but
you
get
all
this
great
value
that
we
don't
need
to
create
from
scratch
like
even
filtering
and
sorting
and
everything
that
we
have
today
and
get
that
we
can.
You
know,
make
use
with
this
new
issue
type,
so
I
think
it's
the
right
way
to
go.
B
No
no
questions
I
this
was
awesome
by
the
way
I
I
love
the
the
table
for
the
comparison
with
the
launch.
Darkly
features.
That's
really
really
helpful
when
looking
at,
like
our
progress
there
and
also,
I
think
that
the
top
two
that
that
you
mentioned
for
me
was
the
contextual
code
with
gitlab's
ability
to
edit
as
well
in
the
web.
B
Ide,
I
think,
is
a
powerful
combo,
so
I
can
see
why
you
were
excited
about
that
one
and
then
also
the
a
b
testing
based
on
feature
flags,
I
think,
is
a
huge
win
in
terms
of
how
people
deploy,
deploy,
features
and
and
test
their
usage.
So
I
this
is
really.
This
is
really
great.
Thank
you
for
this,
and
hopefully,
hopefully
we'll
get
to
the
future
flags
as
an
issue
type
sooner
so.
A
One
more
thing
about
a
b
testing
and
why
I
think
it's
really
great
to
work
on,
besides
it
being
like
super,
valuable
and
and
and
great
there's
two
things
that
that
will
add
value
to
us.
So
one
is
a
b
testing.
The
persona
is
very
different
from
the
persona
from
feature
flags
feature.
Flags
is
usually
developer.
Sre
role
and
av
testing
brings
a
bunch
more
personas
into
the
release
stage:
product
managers,
product
designers,
marketing
sales-
it
brings
all
these
new
personas.
B
A
And
the
other
thing
that
I
want
to
say
is
that
it
ties
in
very
nicely
to
other
stages
in
gitlab,
so
when
you
think
about
a
b
testing,
it's
very
similar
to
post
deployment,
which
we
talked
a
little
bit
about
in
the
cd
direction,
because
basically,
what
you're
doing
is
you're
rolling
out
a
feature,
you're
getting
feedback
and
based
on
that
feedback,
you're
doing
something
so
you're,
either
increasing
the
rollout
or
or
you're
rolling
back.
So
in
that
sense,
it's
super
similar.
We
need
to
connect
to
metrics.
A
A
A
A
I
don't
know
if
you've
seen
there's
a
lot
of
interest,
also
internally
in
gitlab
and
even
on
a
b
testing.
We
have
a
lot
of
opportunities
to
dog
food,
so
this
is
really
in
a
focus
in
the
analyst
landscape
and
that's
why
I
think
that's
why
we
cannot
de-prioritize
this
completely
cd
has
to
be
the
main
focus,
but
we
cannot
lose
track
of
future
flags
as
well
yeah,
so
top
customer
issues.
A
A
We
were
very
focused
on
the
refactor,
so
we
kind
of
lost
some
of
the
audit
capabilities
along
the
way,
and
so
we
need
to
make
that
up.
This
is
super
critical
for
enterprises,
but
not
only
so,
it's
important
together
that
too
top
internal
customer
is
really
great,
because
we
just
got
a
community
contribution
that
did
this,
which
added
a
web
hook
for
future
flags
which
sends
a
web
help.
Every
time
a
feature
is
toggled
on
or
off.
So
you
get
chat
notifications.
A
And
dog
fooding
effort,
so
we
have
some
teams
using
future
flags.
Now
that
a
bunch
of
our
team
members
moved
to
fulfillment,
I
I
I
had
them
commit
to
using
feature
flags
and
be
our
ambassadors
there
in
terms
of
dog
fooding,
but
it
really
depends
on
how
much
we
capabilities
we
can
bring
to
the
table.
A
B
B
A
A
Flipper
is
ruby
based
and
that's
why
it
was,
and
it's
performing,
which
is
why
it
was
selected
in
the
first
place
for
our
internal
use.
Unleash,
was
used
as
a
as
was
selected
as
a
product
one,
because
it
supports
more
languages
than
just
grooming
and
we
kind
of
need
to
nail
down
the
performance
issue
when
you
think
about
what
gitlab
can
do
at
scale.
A
A
So
we
need
to
figure
out
the
pain
of
the
engineers
and
work
on
that.
I
did
get
a
commitment
from
our
team
that
we
will
use
for
our
own
features
the
unleashed
ones.
I
don't
know
if
that
happened,
that
has
happened,
but
I'm
gonna
trust.
You
to
enforce
that
because
I
think
we
can
be
our
own
ambassadors
here
and
fix
it
up.
While
we
come
up
great.
A
I'm
going
to
post
this
on
our
channel
and
anytime.
You
want
to
that
deep
dive
into
any
of
these
issues.
You
know
feel
free.
We've
made
so
much
progress.
The
team
has
done
a
wonderful
job
this
year.
I've
also
we've
also
recently
instrumented.
They
use
the
feature
flag.
So
this
is
interesting.
I
was
just
working
on
a
graph
for
this
now,
not
this
one.
A
So
now
you
can
see
feature
flag,
toggles
on
a
monthly
basis,
so
you
can
see
that
we're
increasing.
This
is
where
we're
not
done
yet.
So
I
think
this
is
okay,
so
we
have
this
instrument.
We
definitely
see
people
using
this
andrew
actually
created
a
daily
one.
If
that's
more
interesting
for
you,
I
I
just
made
it
monthly.
A
A
Is
this
no
yeah?
I
don't
remember,
but
one
of
them
is
when
you
edit
a
flag,
and
one
of
them
is
an
analytics
page
and
we've
had
a
lot
of
discussions,
whether
we
need
to
change
the
the
way
that
people
like
the
upper
toggle,
but
it
seems
like
a
majority
vast
majority
of
people
are
actually
using
the
index
page
and
not
using
the
editors,
so
we
definitely
can't
get
rid
of
it.
We
need
to
figure
out
who's
around
it.
So
there's
a
lot
of
interesting
insights
here,
cool.