►
Description
This video was prompted by the discussions in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67377. We discuss in general how GitLab feature flags work and how the proposal will take us down a different path that allows GitLab to experiment.
A
Hello,
I'm
kevin
chu
product
manager
in
the
release
group,
I'm
talking
with
andrew
who
knows
all
the
things
about
our
feature:
flight
capabilities
andrew.
We
were
discussing
a
proposal
being
a
merch
request
and
I
am
lost
as
to
what
the
proposal
is
about,
because
I
don't
really
understand
how
unleashed
or
how
our
future
flag
feature
works
to
begin
with.
If
you
you
don't
mind,
just
kind
of
walking
me
through
the
basic
of
the
components
that
are
involved
and
what
they
do,
that'd
be
really
helpful.
B
Sure
so
some
history
about
the
mr
is
that
for
a
very
long
time,
when
we
get
lab
developers
want
to
utilize
feature
flags,
we
use
a
ruby
gem
called
the
flipper
at
the
base
level
and
flipper
is
a
very
ruby
specific
database.
Centric
kind
of
rails
focused
feature
flag
solution,
but
we
also
offer
feature
flags
as
a
feature
of
the
product
and
there's
always
been
this
conversation
around
how
we
should
bridge
that
gap
and
dog
food.
Our
own
feature
flags,
as
that
is
a
very
important
value
that
we
like
to
hold.
B
So
the
way
the
unleash
client
works
is
that
when
you
start,
or
at
least
the
ruby
one
anyways,
because
that's
the
one
that
matters
for
us
when
you
start
your
ruby
application,
you
tell
unleash
kind
of
like
what
api
endpoint
contains.
Your
feature,
flags
and
some
other
registration
details
and
every
I
think,
15
seconds
by
default.
B
It
goes
out.
It
makes
an
http
request.
It
goes
out
and
it
gets
those
feature
flags
and
it
updates.
It's
like
internal
store
cache,
and
the
fear
is
that
the
way
we
deploy
gitlab
would
cause
many
many
requests
against
some
sort
of
separate
gitlab
instance
like
staging
or
ops
or
like
yeah,
one
of
those
two
or
even
internally.
B
If
you
do
the
http
request
to
yourself,
we
would
end
up
de-dossing
ourself,
which
is
not
good
or,
at
the
very
least,
significantly
impact
the
performance
of
feature,
flag
checks,
and
we
want
those
to
be
as
light
as
weight
as
possible,
because
the
idea
is
the
feature
flag
should
impact
the
performance
of
the
feature.
B
A
B
Yeah
not
not
yeah,
so
the
there's
and.
B
Or
yes,
okay,
yeah,
so
the
client
runs
within
our
our
server,
but
we
deploy
gitlab
instead
as
like
a
series
of
containers
right
that
are
spun
up,
so
each
container
would
have
its
own
process
managing
its
feature
flags.
B
So
each
container
would
then
update
its
own
feature,
flag,
store
every
15
seconds
and
that's
kind
of
the
major
concern.
There's.
B
Which
would
also,
I
guess,
cause
some
consistency
concerns
if,
if
a
user
hits
a
container
that
has
not
quite
updated
its
feature
flag
store
yet
then
there's
a
chance
that
they
might
be
like
they
might
not
receive
a
feature
flag.
That
was
on
previously
right.
A
B
By
default,
which
is
it's
configurable
right,
but
that
is
a
lot
of
like
yeah.
B
Unleash
the
like
reference,
server
implementation
that
they've
put
out
heavily
utilizes
a
concept
called
etags
to
get
around
this
by
so
the
request
comes
in,
but
basically,
when
the
client
requests
the
future
flags,
it
tells
it
it
tells
the
server.
I
got
flags
that
look
like
this.
B
If
nothing's
changed
give
me
the
new
ones
and
a
lot
of
the
times
the
server's,
just
like
yeah
nothing's
changed,
and
then
I
think
also
for
their
self
or
for
their
hosted
solution.
B
They
scale
in
a
way
that
where
each
customer
gets
their
own
kind
of
instance
of
unleash
is
my
understanding,
or
at
least
like
something
similar,
something
kind
of
like
that.
B
Is
an
approach
to
using
our
own
feature
flag?
Our
own
git
lab
offered
feature
flags
to
control
the
experiments
that
the
growth
team
runs
and
it
does
that
by
circumventing
most
of
the
unleashed
client.
So,
instead
of
doing
an
http
poll,
it
just
goes
into
the
database
sees
if
there's
a
feature
flag,
matching
the
name
of
the
experiment
and
returns
that
it
doesn't
have
an
internal
cache
right
it
just
every
time
the
the
experiment
is
picked
up,
it
goes
and
it
gets
the
feature
from
the
database.
So
there's
no
polling
concerns
anymore.
B
A
So
a
user
hits
a
page,
and
that
page
has
one
of
these
experiments
on
it.
Sure
yeah
and
the
server
well
somehow
understand
that
this
is
we're
talking
about
this
experiment
here
and
then
within
that
process
itself,
it's
gonna
go
check,
hey!
Should
we
return
something?
There's
no
like
there's
no
self
calling
self
via
http,
it's
all
within
the
the
same
same
request,
that's
right
and
then
that
same
request
that
gets
the
information
and
then
serves
it
back
up
to
the
user's
browser.
B
That's
correct,
okay,
so
it
kind
of
kills
a
lot
of
the
it
it.
B
Concerns
a
lot
of
the
spread
trips
that
are
needed,
but
it
comes
with
its
own
set
of
potential
issues.
B
Because
it
makes
this
component,
this,
like
experiment,
come
out
component
very
strictly
tethered
to
our
implementation
of
how
feature
flags
work.
So
if
we,
if
we
wanted
to
change
something
going
forward,
it
would
be
a
little
bit
more
difficult.
B
B
B
Yeah
they
can't
just
like
they're,
not
they're,
not
connected
to
git
lab
in
the
same
easy
way.
They
can't
just
like
reach
into
the
database
and
pull
out
the
feature
whenever
they
need
it.
B
They
are
currently,
I
think
this
was
just
viewed
as
an
opportunity
to
be
able
to
attempt
to
dog
food,
something
that
we
haven't
really
been
able
to
previously
haven't
been
able
to
as
much
the
there's.
The
customers.gitlab
project,
which
does
dog
food
feature
flags
for
us,
but
certainly
not
to
the
same
scale
as
if
all
of
git
lab
feature
flags
were
running
through
unleash
right.
A
Like
you
can't
be
the
same
thing
because
I
mean
if
we
are
ultimately
successful
and
people
are
using
git
lab
for
feature
flagging
of
their
own
application.
That's
I
mean
it's.
It's
going
to
be
a
lot
of
requests
and
we're
only
talking
about
gitlab.com
using
this
right
now
and
we're
already
concerned.
A
B
I'm
I'm
a
little
dubious
as
to
how
how
unscalable
it
is
yeah,
I'm
not
100
sure
if
there's
been
a
lot
of
testing
in
that
area,
I'm
just
skeptical
and
skeptical,
because
you.
B
Yeah,
but
that
you
know
it's
not
it's
not
a
concern
to
be
to
be
scoffed
at
by
any
means
like
it's
a
very
real.
It's
a
you
know
it's
something
that
needs
to
be
looked
at
and
investigated.
B
I
think
if
we
do
reach
some
sort
of
mega
feature
flag
success,
I
could
see
there
being
the
need
for
my
thought
was
always
that
there
could
be
like
a
an
entity
similar
to
the
the
runner
where
you
can.
Very.
You
know
how
you
can
very
easily
deploy
a
runner
to.
A
B
It
feels
like
it
shifts
the
burden
around
a
little
bit
and
then
it
kind
of
helps,
I
think,
in
some
potentially
like
hairy
enterprise
network
scenarios,
where,
like
I
don't
know,
a
lot.
A
B
A
lot
of
the
times
your
if
you're,
in,
if
you're,
in,
like
a
self-hosted
enterprise
solution,
you
don't
really
want
your
gitlab
instance
to
be
talking
to
the
outside
world
very
much
or
you
want
that
limited
as
as
limited
as
possible,
and
then
the
same
goes
for
your
your
like
deployed
application.
B
B
But
then,
if
you
have
like
some
sort
of
little
deployable
service,
you
can
do.
You
can
set
up
like
a
quarantined
kind
of
machine
that
sits
between
the
two
and
lets
the
communication
happen
in
in
ways
that
are
easier
to
know
about
and
inspect
and
things.
So
I
was
always
I've
always
thought
that
that
was
kind
of
a
good
idea.
A
B
B
It's
definitely
something
you
have
to
consider.
So.
I've
always
thought,
like
some
sort
of
little
middle
middle
service
would
be
nice
unleash,
has
kind
of
put
one
out
for
a
very
specific
job
where,
if
you're
like
on
a
phone
or
in
a
browser-
and
you
have
only
the
phone
client
or
the
browser
client,
the
idea
of
pulling
a
server
every
15
seconds
for
feature
flags
and
doing
that
extra
computation
is
kind
of
it's
draining
on
the
battery.
It's
not
very
performant
in
the
browser
kind
of
tough
to
recommend.
B
B
Yeah
so,
instead
of
the
client
doing
all
the
feature
flag
resolution
right,
because
the
way
the
unleash
client
works
now
is
that
you
just
get
all
the
feature
flags
and
then,
when
somebody
is
like
hey,
is
this
enabled
the
server
that
is
or
that
the
client?
I
guess
figures
out
if
it's
enabled
for
for
whatever
the
inputs
are,
which
is
very
different
from
something
from
how
flagsmith
worked
right
like
when
we
were
talking
to
flagsmith?
That
was
just
they
do
all
the
resolution
on
their
side.
B
All
you
get
in
the
end
is
whether
or
not
something
is
on
or
off,
and
this
proxy
is
supposed
to
act
like
that,
where
the
phone
or
the
browser
can
directly
call
them
with
all
the
data
that
they
need
to
get
all
the
feature
flags
all
at
once,
kind
of
not
need
to
necessarily
do
heavy
polling
or
any
of
that
or
any
heavy
like
computations
yeah.
A
B
B
Get
it
to
a
an
agreeably,
workable
solution.
B
B
Just
not
gitlab.com,
I
think
it
would
be
worthwhile
to
ask
the
growth
team
kind
of
what
they
would
get
out
of
using
gitlab
feature
flags.
B
Because
I
think,
if
I
remember
correctly,
the
kind
of
the
big
issue
with
flipper
right
now
is
that
there's
you
know
there's
no
nice
ui,
so
you
can
go
and
see
all
your.
A
B
That
means
it
means
sending
like
feels
like
an
incantation
as
a
message
in
slack
to
see
how
things
are
going.
You
know.