►
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
A
B
B
A
B
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
B
B
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
B
A
A
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.