►
From YouTube: Feature Flags Vision Deep Dive
Description
Orit & Mike talk about feature flags
A
A
A
A
A
A
We
have
the
overall
vision
of
CI
CD
and
how
it
ties
in
everything
that
related
to
UX
research
issues
and
our
documentation
that
leads
to
the
current
feature:
flag
implementation,
and
then
we
have
what's
what's
the
next
thing?
Why
and
this
basically
changes.
This
is
a
patient
that
I
update
every
release
and
it
talks
about
what
we're
going
to
release
the
next,
and
you
can
see
that
we
we
release
the
two
strategies
which
is
percent
rollout
and
user
ID.
Our
next
thing
that
we're
focusing
on
is
internally
testing
and
sub
dogfooding.
A
The
way
that
it's
currently
implemented,
which
is
that
you
actually
have
to
for
every
flag,
create
enter
the
IDS
of
everyone
that
you
want
this
to
be
turned
on
or
off,
for
it's
not
scalable
at
the
moment.
But
it
is
usable
for
specific
use
cases
for
someone
who
has
a
small
customer
base,
for
example.
So
it
does
address
a
specific
target
audience,
but
not
our
main
audience,
and
we
will
address
that
in
different
issues
and
ability
that
associated
feature
filings
with
contextual
issue,
which
is
what
we're
working
on
at
the
moment.
A
A
certain
percent
of
users-
and
we
have
quite
a
few
customers-
are
interested
in
this
specific
capability
and
are
willing
to
leave
other
competitors
such
as
JIRA,
just
because
they
have
no
way
to
tie
issues
planned
with
their
CI
CG
pipeline
because
they
used,
let's
say
jeer
of
her
wedding
and
they
use
github
for
CI
CD,
and
just
this
way
of
tying
in
the
issues
may
be
a
differentiator
for
them
to
move,
to
get
lab
as
a
single
tool
in
terms
of
also
planning.
So
it's
very
important
to
see
how
everything
ties
together.
A
Next,
we
have
permissions
for
feature
flags.
This
is
a
really
really
big
topic
and
in
terms
of
who
isn't
a
who
can
turn
on
or
off
a
feature
flag,
and
this
generated
a
lot
of
discussion
internally
and
get
lab
because
internally
and
get
lab
the
developers
have
access
to
turn
this
on
in
production.
So
this
started
the
whole
discussion
about
what
we
should
do
and
at
the
moment
we
decided
leave
it,
as
is,
which
means
the
developers
can
still
turn
off
the
feature
flag
per
the
project
permission
that
they
got.
A
Next,
we
have
cookie
based
access
and
actually
anything
that
you
can
call
stickiness.
So
basically,
we
could
have
different
strategies
for
future
flags,
and
each
strategy
may
turn
a
different
behavior
for
a
specific
user,
and
we
need
to
make
sure
that
every
time
they
open
the
application,
they
have
the
same
experience
so
that
one
is
an
important
one
API
and
seeing
caching
for
feature
files
also
really
important,
because
it
may
have
an
impact
on
performance
on
every
time.
A
You
you
open
that
application,
how
we
pull,
which
feature
slides
are
enabled
and
what
behavior
the
user
will
get
the
more
feature.
Flags
we
have,
the
more
clothing
is
going
to
be
done
and
in
effect
it
will
have
eventually
and
more
explicit
logging
for
accesses
is
basically
auditing.
We
can
meet
auditing
capabilities
for
everything
so
also
for
feature
flags.
Let
me
just
say
that
we're
that
I'm
being
honest
to
what
it
says
here.
A
Yeah,
so
this
is
both
auditing
and
also
the
visualization
of
what
to
expect
for
a
specific
target
in
terms
of
feature
flags
and
basically
that's
what
we
mentioned
at
the
moment
as
part
of
the
maturity
plan.
But
I
definitely
think
that
I
need
to
work
on
this
page
to
extend
the
vision
and
talk
in
a
minute
about
about
what
would
I
see
in
the
future.
A
In
terms
of
priority,
as
I
mentioned,
our
number
one
priority
at
the
moment
is
dog.
Fooding
dog
fooding
is
not
labeled
as
a
direction
item
in
our
issues
and
get
that.
So
that's
why
it's
not
appearing
this
list
because,
basically,
in
the
vision
page,
we
only
had
Direction
items
but
in
my
personal
opinion
and
the
second
setting
priority
now,
we
need
to
figure
out
how
we're
using
this
internally
before
we
expose
it
to
mass
production.
I
mean
current
users
can
use
it
potentially
for
specific
use
cases
at
the
moment.
A
But
when
I
look
at
the
market
and
how
I
want
people
to
use
feature
flags,
we
need
to
be
ready
for
it.
We
need
to
be
ready
in
terms
of
big
companies
that
are
gonna
use
it
for
many
developers
across
the
globe
and
on
multiple
projects,
and
until
we
know
how
we're
going
to
use
this
internally,
I,
don't
think,
there's
any
point
in
continuing
developing
other
features,
because
we
we
got
a
lot
of
pushback
regarding
the
current
implementation
and
until
we
know
how
to
address
them
internally,
I.
B
A
There
are
currently
two
things:
I,
don't
remember
them
my
heart,
but
I
can
send
them
later,
but
I
remember
their
topic.
One
of
them
is
exposing
the
API
to
public
API,
because
people
want
to
be
using
this
as
scripting
or
through
chat
acts
mechanism
and
necessarily
through
the
UI,
which
slows
them
down.
So
that's
one
pushback
that
we
got
and
that's
supposed
to
be
dissolved
into
all
that
for
and
another
project
that
we
got
is
actually
connecting
our
code
base
to
our
feature
flags,
because
at
the
moment
it's
not
connected.
A
So
those
are
the
two
big
milestones
that
we
need
to
overcome:
they're
both
scheduled
for
this
current
release,
all
that
for
and
then
people
would
could
potentially
start
working
with
it.
We
have
gotten
small
feedbacks
like
the
UI
was
a
little
bit
confusing
and
it's
something
that
we
handle
together.
You
and
I
both
regarding
toggles
that
are
didn't
a
purely
an
environment
view
or
the
dashboard
view.
Rather
so
that's
something
small,
but
other
teams,
such
as
growth,
don't
actually
have
at
the
moment
and
answer
to
their
problem.
A
They
want
to
use
feature
flags
for
a
be
testing,
so
basically
they
just
want
the
application
to
work
differently
for
different
targeted
groups.
For
example.
They
are
working
right
now
in
people
who
joined
gitlab
and
have
been
using
it
for
under
30
days.
They
targeted
that
list
as
a
group,
and
they
want
to
monitor,
give
features
to
that
specific
subset.
Now,
at
the
moment,
we
don't
even
have
entity,
that's
called
groups,
and
we
do
have
an
issue
on
that
and
then
you're
pinged
on
it
and
you
you
know
that
you
know
about
this
issue.
Your.
B
A
So
that's
one
thing
that
they
don't
have
capability,
but
also
we
currently
have
only
the
option
to
turn
something
on
or
offer
a
percent
usage,
but
not
like
multiple
behaviors
for
multiple.
So,
for
example,
I
have
early
like
beginner
users,
which
is
people
who
started
using
for
30
days.
That
group
and
then
I
have
a
group
for
someone
who's
been
using
it
for
six
months
and
then
for
a
month.
So
potentially
has
three
different
groups
and
I'd
like
to
give
three
different
behaviors
of
the
same
feature
just
to
make
it
sound,
really
really
simple.
A
That's
why
I
decide
to
have
someone
get
a
blue
interface
of
green
interface,
a
yellow
interface
and
then
I
want
to
check
feedback
on
who
has
been
using
like
to
decide
which
color
is
the
best
based
on
the
feedback
that
I
got
from.
He
said
of
the
group
really
simple
example,
not
something
that
someone
would
actually
use,
but
following
the
same
lines,
and
so
those
are
currently
not
supported
and
are
currently
not
in
the
plan,
definitely
not
for
this
year.
A
So
this
year
is
all
focused
for
dogfooding
and
the
feedback
that
we
get
there
and
I
think
2020
will
be
a
big
year
for
future
flags,
where
we
can
actually
address
all
the
pain
that
we
have,
such
as
groups.
Copy-Paste
are
importing
CSV
that
we've
discussed
before
for
user
IDs
additional
strategies.
So
now
we
have
for
some
rollout
and
we
have
user
ID,
but
additional
strategies
could
be
custom
strategies
which
are
supported
by
the
way--by
unleash.
We
have
the
non
strategy,
which
means
anyone
that
doesn't
appear
in
the
group.
I.
B
A
B
So
are
we
seeing
like
we're
going
to
continue
that
trend
and
these
user
bases
will
probably
live
outside
of
our
product
and
we're
just
going
to
allow
you
to
set
up
rules
that
you
can
hook
into
in
your
system?
I
guess
that's
my
question
right.
If
it
lives
outside
of
us,
the
parameter
based
ones
might
be
interesting
because
we
don't
have
access
into
these
code
bases
so
yeah
just
a
thought
on
that
one.
So.
A
B
A
A
A
B
A
So
that's
something
I
would
like
to
the
users
to
have
some
kind
of
notification,
or
maybe
colored
in
red
or
something
something
to
notify
they
use
and
that
they
need
to
get
rid
of
this
code
is
dickham
at
some
point.
Anything
we
could
do
automatic
would
be
even
better
and
then
have
you
know
it's
just
the
pipeline.
Remove
it
once
it
hits
a
hundred
percent,
for
example.
A
So
that
would
be
great,
but
that's
an
easy
one,
but
I'm
also
talking
about
something
that
has
been
in
the
code
for
like
six
months
for
a
year,
maybe
some
kind
of
notification.
This
has
been
inactive,
let's
delete
it.
You
know
some
kind
of
whole
vision
that
a
developer
that
pops
engineer-
that's
men,
that's
working
with
these
future
flies
can
know
whether
or
not
it's
needed,
because
sometimes
even
for
a
bee
testing.
A
Let's
say
you
decided
to
deliver,
I,
don't
know
30
percent,
70
percent
or
whatever,
and
at
some
point
you
just
forgot
about
it,
left
it
in
the
code
and
the
majority
of
the
people
have
one
instance
and
the
other
other
and
have
a
different
behavior,
which
is
bad
practice
in
the
long
run.
So
we
really
should
be.
You
know,
notifying
users
if
something
like
that
happens
over
time.
A
A
It
also
adds
to
the
amount
of
complexity
that
a
testing
group
would
need
to
do
because
there's
different
paths
that
the
code
goes
to.
So
all
this
complexity
needs
to
stop
at
a
specific
point
in
time,
whether
it's
the
maturity
of
the
feature
or
once
you
got
enough
feedback,
but
we
definitely
don't
want
this
code
lying
around
for
it.
B
A
B
Maybe
just
a
thought
since
we're
doing
this
in
other
places,
just
on
I
mean
maybe
setting
up
rules
at
the
beginning.
You
know
like
we
did
with
the
environments
that
expire.
You
know.
Maybe
there
are
predefined
things
that
if
these
criteria
are
met
then
do
this
with
the
feature
flag,
like
you,
said,
100
percent,
maybe
it
automatically
deletes
once
a
week
so
yeah.
A
A
A
Again
with
the
dashboard,
I
think
automatic,
awesome,
notification
less
awesome,
but
still
would
be
like
a
good
step
in
the
way,
some
kind
of
trying
to
know
whether
it's
an
email
or
something
red
or
some
way
to
notify
the
user
that
some
kind
of
action
is
needed,
even
if
they
press
ignore
and
then
it's
like
snooze
for
another
month.
Maybe
that's
also
something
like
I
would
want
it
to
be
automatically
deleted.
Unless
someone
did
something
active.
A
A
And
retiring,
we
talked
about
something
really
interesting,
that
I
think
that
we
could
do
way
way
way
down.
The
road
is
breadcrumbs
so
kind
of
following
the
user
path
of
how
they
got
to
whatever
in
scenario
they
got
to,
and
what
is
the
right
path
that
we
want
them
to
go
to
and
kind
of
visualizing
that
in
the
desperate
would
also
be
awesome.
A
That
we
can
think
about
for
future
funds
is
not
only
like
a
developer
developed,
something
that's
not
ready
yet,
and
we
want
to
give
you
a
or
some
early
adapter
access
to
the
future
would
be
to
actually
segment
groups
like
better
customers
who
have
like,
let's
I,
get
that
we
release
every
on
the
22nd
of
every
month.
If
we
had
a
group
called
better
users,
I
could
get
this
from
the
beginning
of
the
month
until
the
22nd
and
get
feedback
from
them.
A
That
would
be
really
valuable,
so
actually
using
feature
flags
for
signification
for
early
adapters
could
be
a
really
good
use
case.
Another
interesting
use
case
could
be:
let's
say
that
your
support
manager
and
you
have
a
customer-
that's
complaining
about
some
kind
of
behavior
specific
for
that
customer
man.
You
don't
want
to
wait
another
month
for
the
release,
so
you
send
them
the
food.
The
thing
behind
that
the
feature
flag
that
could
be
like
targeting
specific
customers.
So
there
are
a
lot
of
use
cases
here
that
we
can
think
about.
B
No
I
don't
know
now
is
a
good
time
to
bring
it
up,
but
one
thing
I've
noticed
in
looking
at
and
this
probably
maybe
he's
better
once
we
talked
through
the
competitors
but
I
feel
like
our
current
solution
is
very
environment
based
right.
That's
the
top-level
thing
that
you
do
and
then
your
rules
are
kind
of
based
off
of
that
environment
and
in
looking
at
other
competitors
a
lot
of
them,
don't
even
address
environments
or
it's
definitely
not
the
top
level
thing.
A
So,
in
my
mind,
feature
flags
should
only
exist
in
two
environments
and
that's
production
and
staging
that's
an
or
pre-production
you
wanna
cause,
there's
no
point
to
have
future
flags
in
a
QA
environment.
Since
there
are
the
people
testing
anyway
in
them,
and
if
they
don't
give
the
okay,
then
you
hide
it
behind
the
future
flag
in
the
production
right.
B
B
A
B
Seen
it
used
in
QA
in
other
places
where
it
was
basically
turned
off
for
everybody,
except
for
the
person
queuing
that
particular
feature
to
not
cause
problems.
Right
like
this
is
a
developers
are
confused
by
this
new
thing.
Right,
I'd,
say
here's
this
button
and
it's
like
wait.
What
is
this
whole
thing
right?
So
it's
just
a
QA
thing.
A
B
Yeah
that
makes
sense
I,
just
I'd
ever
thought
to
bring
that
up
as
I
feel
like
we
are
the
way
our
UI
color
will
currently
works
and
the
way
our
really
the
tone
structure
really
works.
It
is
I
think
that
sooner
or
later
we
break
away
from
this
environment.
First
idea
the
better
off
we're
going
to
be.
A
A
Anyway,
I
I
definitely
see
a
use
case
for
multiple
production,
but
I
don't
know
if
we
need
to
enable
it
for
more
than
pre-production
and
production,
because
pre-production
basically
needs
to
be
exactly
the
same
as
production.
So
I
would
definitely
allow
that
environment
as
well,
but
for
Devin
test
I
think
the
use
case
is
too
weak
for
us
to
create
a
whole
dashboard
around
it.
B
Production
is
whatever
you
deem
it
to
be
right
in
our
in
our
system.
You
can
name
production,
green
deployment
right,
so
it
it
almost
seems
like
we'd,
have
to
take
extra
steps
to
limit
it
to
only
production.
Here's
what
I'm
trying
to
say
we're!
You
know
the
way
you
have
your
environment
set
up.
You,
you
name
them
what
they
want.
You
use
them,
as,
as
you
deem
it
seems,
like
we'd,
have
to
take
extra
steps
to
limit
it
to
just
production,
so.
A
A
So
I
know
DevOps
doesn't
really
have
their
own
approach.
They
have
something.
That's
kind
of
an
integration
was
launched,
darkling
if
I
understood
correctly,
and
basically
they
explained
in
a
coding
language
that
the
feature
fellows.
If
there's
a
flag,
then
do
this,
and
if
there's
no
flag
do
something
else
right
and
and
I
complexity
that
how
do
you
use
it
for
AV
testing
is
basically
something
taco,
but
you
tell
them.
A
A
So
you
have
your
feature:
flags
configuration
right,
and
then
you
have
the
flag
that
the
toggle
itself
on
or
off
and
then
target
individual
users.
You
see
it's
very
similar
to
ours
and
then
you
have
rule-based,
which
we
don't
have
at
the
moment.
But
we
do
have
some
issues
in
the
roadmap
regarding
rule-based,
which
is
kind
of
what
we
talked
about.
Anyone
who
has
a
domain
or
anyone
who
follows
for
the
next
project
syndicate
or
someone
who
is
under
30
days
use.
So
that's
rules.
A
A
So,
basically,
the
feature
flag
is
decided
if
it's
on
or
off
on
the
client-side.
Okay,
it's
not
on
the
server
side.
So,
basically,
if
I
can
configure
a
flag
in
gitlab
there's
some
kind
of
configuration
file
that
goes
down
to
the
client
and
of
them
the
feature
flag
is
on
or
off,
and
this
has
polled
every
X
amount
of
time.
But
if
gitlab
server
is
unavailable
at
some
point
in
time
it
doesn't
mean
that
nothing
works.
It
means
that
the
last
configuration
that
the
client
has
that's
what's
used.
A
Okay,
that's
the
the
optimal
behavior
here
that
you
can
decide
to
have
a
different
kind
of
configuration,
but
I,
don't
think
we're
gonna
go
down
this
route.
I
think
we're.
We
want
to
use
the
last
no
configuration
and
worst
cases
if,
in
the
last
I,
don't
know
20
minutes,
you
turn
the
flag
on
and
the
server,
so
the
user
will
still
have
the
previous
behavior.
A
A
A
It
actually
needs
to
be
one
of
the
first
features
after
we
complete
the
dog
food
because
we're
working
towards
evidence,
collection,
which
is
not
related
to
feature
flags
but
in
evidence
collection.
Any
action
that
you
do
throughout
the
pipeline
or
development
needs
to
be
locked
and
therefore
also
toggling
a
feature
flag
on
or
off
needs
to
be
logged
when
it
was
done
by
whom
and
in
which
environment
I
mean
Natura
created
an
issue
for
that,
but
it
definitely
needs
you
and.
A
Something
else
that
I
think
would
be
beneficial
and
I'm,
not
sure
exactly
how
to
describe
this.
An
issue
is
imagine
that
you're
a
support
manager
and
you
get
a
call
from
a
user,
and
he
says:
oh,
my
god.
Where
did
my
settings
go
and
it
turns
out
someone
turned
on
a
feature
flag
for
them
and
the
setting
is
just
in
a
different
location.
A
So
some
we
need
some
kind
of
configuration
to
enable
customer
support
or
support
engineers
to
know
instinctively
like
what
kind
of
configuration
a
user
has
in
order
to
help
them
out
with
a
problem.
So
I'm
not
sure
how
to
define
that
exactly,
but
that's
something
that
we
wouldn't
probably
need
to
address
going
forward.
B
A
Which
means
you
would
probably
need
to
know
like
what
groups
are
in
if
we
had
the
breadcrumbs
functionality
that
I
mentioned
before
that
would
be
definitely
cover
the
scenario
where
you
would
just
see
the
user
flow
right,
so
you'd
know
exactly
what
they
got,
but
I
think
this
is
a
little
bit
complex
and
probably
further
down
the
road
in
terms
of
the
roadmap,
but
also
could
be
a
really
really
good.
Differentiator
formula
yep.
A
A
Actually,
I
think
that
if
we
do
do
some
kind
of
LDAP
integration,
we
could
probably
overcome
mine
because
most
of
the
user
management
systems
do
connect
to
LDAP.
That's
some
some
kind
of
LDAP
or
system,
and
they
don't
make
up
their
own.
So
if
we
do
that,
we
could
definitely
overcome
it.
All
so
I
have
created
I
have
been
part
of
different
configuration
management
systems
that
exposed
via
API
kind
of
CSV
file,
just
the
usernames
from
one
system
to
another
in
order
to
enable
this
integration.
A
B
A
A
Okay,
so
basically
what
they
had
here
was
audience,
and
this
is
what
we
were
discussing
about
the
like
rule-based,
which
means
that,
like
all
versions,
all
users,
you
could
like
player
a
bunch
of
things
here
and
also
do
like
complex
feature
flags
like
if
and
and
then
add
another
logic.
So
you
can
have
multiple
rules
for
one
feature
flag.
Okay,
so
it
could
be
like
all
the
users
from
get
lab
domain
that
have
been
using
the
product
further
a
month
right.
A
B
A
B
B
A
A
Okay,
so
I
don't
remember
what
this
one
was:
production,
experiments
I,
don't
remember
what
this
one
was
doing
well,
this
is
also
needs
okay.
So
this
is
blue,
green
and
red.
So
this
is
mainly
focus
for
AP
testing.
It's
not
our
core
future
flex
functionality,
but
definitely
one
that's
very
interesting
and
maybe
something
interesting
to
look
up
for
the
roadmap.
A
A
This
is
the
rule
base,
but
they
do
it
on
a
code
base
environment.
So
you
had
rules
for
email,
so
domain
like
get
get
bad
calm,
or
this
was
playlist
count
which
could
be
our
parallel
of
amount
of
projects
or
code
base
and
then
the
plan
so
plan
could
be
tier.
It
was
premium
or
gold
subscription,
or
something
like
that.
A
So
this
was:
are
there
groups
how
you
manage
groups,
so
the
rule
was
someone
would
be
named
DJ
if
they
had
a
playlist
that
had
over
101
songs.
So
our
problem
would
be
more
than
ten
projects
more
than
ten
active
projects,
I'm
just
throwing
things
out
there.
I
may
be
saying
things
that
don't
make
any
sense,
but
you
understand
the
gist
of
the
idea
right,
yeah.
A
Okay,
so
here
you
have
like
paying
user,
so
it
could
be
free
versus
any
tier
and
so
on
and
so
forth,
and
this
was
something
that
I
really
like
and
that's
managing
feature
flag
dependencies.
In
theory,
you
can
create
a
feature
flag
that
is
connected
to
code.
That
already
has
a
feature
flag
connected
to
it,
and
then
you
don't
want
to
get
to
a
situation
where
one
is
turned
on
and
one
is
turned
off
and
then
some
weird
behavior
happens.
A
A
Okay,
so
this
is
more
about
the
groups
and
how
it
supports
regular
expression,
which
is
really
cool.
I,
haven't
even
created
an
issue
for
this
because
we
don't
create.
We
don't
support
rednecks
for
anything
yet
like
when
filtering
so
I
think
this
is
really
really
even
further
down
the
line
in
terms
of
what
we
want
to
create.
A
So
this
is
still
an
open
end
question
of
how
we
want
to
implement
it
in
good
lab.
I.
Think
that
this
is
the
right
implementation,
which
is,
if
you
have
access
to
an
environment,
and
you
have
access
to
turn
on
the
flag,
but
I
guess
we
need
to
understand
the
internal
use
case
first
before
turning
off
this
capability
for
our
own
developers.
A
So
this
is
a
dashboard
that
they
had,
which
was
really
cute
regarding,
like
watching
all
the
feature
flags
in
one
place
and
whether
or
not
they're,
they're,
active,
so
green
means
active
and
states
also
for
environment.
The
percent
roll
out.
We
have
something
similar,
but
not
as
slick,
and
what
I
really
liked
was
that
once
it
hit
a
hundred
percent,
they
became
gray
and
it
auto
archived
the
feature
flag.
So
it
didn't
like
delete
it,
it
are
kind
it
and
then,
if
someone
one
day
want
to
go
back
to
it,
they
could
potentially.
A
A
B
A
They
have
a
very,
very
comprehensive
solution.
I,
don't
think
we're
going
to
be
matching
them
feature
by
feature
and
we're
also
pretty
late
in
the
game
and
basically
I'm
not
sure
that
every
use
face
that
they
support.
We
do
we
want
to
support
at
the
end
of
the
day.
I
do
want
to
be
able
to
be
proud
to
say
that
we
have
a
feature
flag
solution
that
ties
together
nicely
with
our
CCD
solution.
A
A
A
So
this
is
feature
fogging
with
it
last
year,
right
and
feature
flying
in
JIRA,
and
this
one
actually
had
the
item
that
we
are
working
on
on
12.4,
which
is
associating
the
feature
flight
to
the
issue
and
the
way
it
shows.
It
shows
you
the
flag,
whether
it's
on
or
off,
and
the
percent
roll
out,
which
I
like.