►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
let's
get
started
so,
first
of
all,
my
name
is
sweethearts
and
I'm
working
as
a
technical
community
manager
at
harness
I'm,
a
cncf
Ambassador
I've
been
leading
the
community
for
the
litmus
chaos
incubating
projects
in
CFN
keyboarding
project,
and
you
might
have
seen
me
doing
a
lot
of
chaos,
engineering
and
right
now.
I've
started
building
communities
for
feature
flags
as
well
as
finops,
and
have
been
also
organizing
a
lot
of
events
in
the
community.
A
You
can
connect
with
me
on
these
socials
so
for
the
agenda
for
today,
we'll
be
talking
about
software
delivery
and
its
challenges.
We'll
also
talk
about
the
deployment
inefficiencies
that
can
be
fixed,
we'll
start
introducing
future
Flags,
some
common
use
cases,
the
software
release
workflow
with
feature
Flags,
how
to
do
feature
Flags
the
right
way,
some
case
studies,
key
learnings
and
eventually
about
the
community.
A
So
before
we
get
started
with
what
feature
flags
are:
let's
discuss
some
challenges.
I
mean
the
modern
software
development
delivery
has
has
demanded
the
code
to
be
shipped
fast
and
it's
getting
faster
day
by
day,
and
it's
it's
not
just
the
code
that
that's
you
know
at
risk,
but
even
the
customers,
the
end
users
want
it
to
be
faster,
want
applications
to
deliver
faster
and
and
without
without
any
risk,
and
that's
why
there
is
CI
CD
is
has
required
some
upgrading
itself,
and
that
is
where
the
idea
of
future
Flags
was
brought
in
I.
A
Believe
when
software
delivery
wasn't
just
enough
in
terms
of
CI
CD,
but
there
was
something
that
was
required
in
terms
of
enabling
and
disabling
features
and
making
sure
that
features
are
delivered
with
without
any
risk,
with
higher
velocity
and
with
I
mean
as
and
when
required.
So
before
that,
we
will
talk
about
the
challenges
itself
and
I
believe
that
software
delivery
has
many
challenges,
but
I've
segregated
them
into
Technical
and
business
challenges.
A
So
from
the
technical
aspect.
Obviously,
there's
there
are
a
lot
of
feature
branches
in
development.
A
It's
hard
to
test
multiple
Solutions,
it's
it's
I
mean
it's
hard
to
identify
all
the
risks
that
are
associated
with
decision
making
on
what
to
build,
how
to
build
and
roll
backs
due
to
failed
deployments
of
individual
features
are
pretty
common
and
and
these
these
challenges
are
faced
day
in
and
day
out
by
by
developers
by
the
the
engineering
teams
and
it's
it's
very
hard
to
identify
how
to
I
mean
from
a
from
a
granular
aspect
that
how
these
challenges
can
be
mitigated.
A
If
and
it's
difficult
to
manage
these
large
amount
of
features
and
codes
with,
especially
when
the
the
eventual
goal
is
to
run
them
in
in
production
so
and
and
moving
on,
if
we
talk
about
business
challenges,
I
mean
obviously
there's
a
loss
of
customer
confidence.
It's
it
leads
to
negative
customer
impact
due
to
release
quality
issues.
Rollbacks
or
roll
forwards
can
cause
business
time,
as
well
as
a
lot
of
money.
A
Companies
end
uploads
losing
millions
of
dollars
in
that
sense,
and
then
time
and
effort
spent
in
in
the
whole
team
and
and
the
loss
of
confidence
and
lack
of
governance
leads
to
a
lot
of
challenges
for
businesses
itself.
Today,
a
lot
of
companies
are
facing
these
challenges,
and
there
are,
there
are
frictions
between
engineering
release,
timelines
teams,
and
then
there
are
issues
between
the
productive
and
the
marketing
team.
So
these
are
some
challenges
today
that
software
delivery
has
been
facing
and
CI
CD
itself
has
faced
being
part
of
the
community
for
so
long.
A
This
is
something
that
I
have
learned
itself,
that
these
are
the
challenges
that
that
are
that
have
been
hard
to
mitigate
and
if
we
look
at
the
larger
problem
in
terms
of
features
or
delivering
features,
there's
been
I
mean
developers
day
in
and
day
out
have
faced
tight
deadlines.
They
have
faced
a
lot
of
stress
during
deployment.
A
Personal
personalization
hasn't
been
that
good
and
which
has
in
in
return,
has
had
repercussions
such
as
reduced
velocity,
increased
risks,
poor
developer
experience
and
eventually,
as
I
mentioned,
that
these
These
Old
bags,
these
these
bad
features
have
have
cost
them
dearly.
A
So
moving
on
what
are
the
fixable
deployment
inefficiencies
or
what
are
the
inefficiencies
that
that
have
been
usually
I
mean
there
with
today's
deployments
that
are
offering
All
or
Nothing
basically,
and
it
creates
rework
and
pay
in
it,
I
mean
there's
slow
releases,
I
mean
they
are
slow,
costly
and
and
new
features
in
production
become
become
difficult
and
you
can't
test
certain
features
because
I
mean
every
feature
has
a
different
segment
and
rolling
them
out
progressively
becomes
becomes
difficult
and
similarly
bug
fixes
take
a
lot
of
time.
A
It's
costly,
there's
an
added
expense
due
to
targeted
rollouts,
when,
when
you
are
trying
to
ensure
that
that
a
certain
group
of
people
are
able
to
access
a
certain
feature,
a
certain
feature,
a
few
features,
and
then
you
have
different
features
for
a
certain
group,
and
this
if
I
have
to
take
an
example.
This
is
something
that
I
have
seen
myself.
A
Let's
say
if
I'm
using
an
application,
let's
say
a
food
delivery
application
in
recent
times,
if
I
have
to
take
an
example
and
I've
seen
that
the
same
application
that
is
being
used
by
my
friend
has
has
got
some
different
features
and
I
have
been
delivered
some
different
features.
If
you
talk
about
Instagram,
they
have
some
different
features
for
the
beta
version.
They
have
some
different
features,
features
for
their
Alpha
versions.
A
So
so
these
These
are
the
problems
that
each
and
every
App
application
or
companies
that
are
delivering
these
applications
face,
and
that
is
where
I
mean
feature
Flags
come
into
play
where
the
the
idea
is
to
I
mean
ensure
that
features
are
decoupled
in
the
right
sense
or
let's
say
a
developers
can
conditionally
turn
certain
sections
of
their
code
on
and
off
and
and
it's
it's
to
be
honest,
an
extension
of
continuous
delivery.
A
So
the
the
idea
is
to
obviously
you
know,
you
can
think
of
future
flags
as
a
new
way
to
you
know,
building
and
releasing
applications
by
clearly
defining
features,
components
that
can
be
changed.
Toggle
on
and
off
individually.
You
allow
for
experimentation,
control,
rollouts
to
different
users
and
and
as
well
as
you
know,
letting
more
people
such
as
developers,
your
sres,
your
product
managers,
your
support
teams
to
turn
and
turn
turn
on
and
turn
off
things
for
customers,
as
as
you
require.
A
So
you
know
at
a
higher
level,
I
mean
future
Flags,
give
a
lot
of
power
to
developers
to
create
better
features,
deliver
them
faster
and
at
the
same
time,
they
ensure
that
engineering
is
not
the
bottleneck
for
the
business
and
that's
why
it
delivers
value.
In
terms
of
you
know
the
technical
sense,
it's
like
you
shift
responsibility
to
the
business
to
determine
release
dates.
A
You
release
new
features
faster
and
iterate
rapidly
without
negative
consequences.
You
never
roll
back
a
good
new
feature
due
to
a
different
bad
feature
or
you
are
able
to
easily
release
individual
features
to
production
daily
and
that
that's
why
it
has
a
lot
of
positive
outcomes
as
well,
where
you
know,
there's
less
time
spent
remediating
feature
failures
in
production.
There's
less
time
spent
in
coordinating
releases,
there's
less
time
spent
in
auditing
for
compliance.
There
are
more
bug
fixes
and
eventually
more
features
are
shipped
and
from
a
business
perspective.
A
If
you,
if
you
talk
about
what
are
some
I
mean,
we
spoke
about
some
key
challenges,
but
you
know
you
are
able
to
deploy
features
more
frequently,
there's
shift
controller
feature
releases
to
customer,
facing
teams,
there's
increase
in
net
retention
rate,
there's
a
lower
churn
rate
and
obviously
there's
less
less
exploitation
of
security,
loopholes
and,
and
eventually
this
helps
the
business
grow
and
and
do
better
so
so
we'll
take
a
look
at
some
I
mean
common
use
cases
of
where
to
use
feature
Flags.
A
There
are
a
few
ways
to
look
at
where
and
you
should
use
feature
Flags
and
we
will
explore
some
of
them
and
another
way
to
look
at.
It
is
your:
when
is
your
Tech
stack
ready
or
when?
Is
it
ready
to
use
feature
Flags?
But
we
will
talk
about
that
later
on,
perhaps
so,
if,
if
we
have
to
talk
about
different
roles
itself,
so
for
developers,
of
course,
it
helps
increase
velocity.
A
It
helps
them
ship
code
faster
and
it
decouples
releases
and
deployments
from
a
devops
engineer
perspective
which
helps
them
get
operation,
control,
maybe
kill
switches,
help,
let's
say,
kill
an
application
or
kill
a
feature
it
itself.
The
operation
control
is
helps
them
to
respond
to
roll
out
issues
automatically
and
it
basically
automates
the
process
for
them
and
from
a
product
manager
perspective
you
they
are
able
to
control
releases
a
b
tests,
they're
able
to
learn
and
experiment
quickly
and
and
releases
are
delivered
in
a
better
sense
and
from
a
sales
or
support
aspect.
A
You
can
see
that
they,
they
have
better
access
to
customers,
the
customer
facing
teams
get
more
empowerment
and
it
it
helps
in
in
you
know,
understanding
the
customer
better
and
basically
help
the
the
business
better
or
you
you
say,
delivering
features
in
a
better
sense
and
moving
on
I
mean
that
the
current
state
of
feature
Flags
teams
solve
this
themselves,
but
there
are
limitations.
Of
course,
the
power
of
feature
Flags
has
not
been
fully
leveraged.
I
mean
a
lot
of
people
are
using
homegrown
future
flag.
Solutions
I
mean
I.
A
I
wouldn't
suggest
that
Homegrown
Solutions
are
not
good,
but
I
believe
that,
with
a
lot
of
things
that
are
developing
and-
and
there
are
so
many
open
source
projects
out
there
shout
out
to
open
feature,
that's
been
doing
good
in
terms
of
leveraging
the
power
of
each
flag,
so
feature
management,
I,
would
say,
and
and
then
there's
lack
of
confidence
and
governance.
A
Where
you
know
the
the
current
state
is
that
people
are
happy
with
with
their
cicd
Solutions
and
they
have
not
taken
a
look
at
at
what
other
things
that
can
be
done
or
brought
up,
but
you
know
getting
started
with
feature.
Flags
is
easy,
I
mean
if
you,
if
you
talk
about
a
lot
of
other
developer
tools
out
there
it
it
might
take
a
longer
time
to
integrate,
but
this
this
doesn't
really
take
a
long
time.
I
mean
you
just
need
to
ensure
that
let's
say
our
your
features
are
in
place
and
you
can.
A
You
can
usually
find
I
mean
feature
flags,
as,
as
you
know,
a
few
lines
of
code
or
a
few
commands.
It's
basically
a
comment
as
they
say,
and-
and
that's
that's
where,
if,
if
you
are
just
moving
the
comment
as
a
feature
it
it
became,
becomes
a
flag
or
basically
acts
like
a
button
right.
So
the
current
state
obviously
also
means
that
there
is
lesser
adoption
the
community
has
been
has
been
growing.
A
I
mean
people
have
not
seen
feature
flags
as
something
which
is
essential,
but
slowly
there's
there's
with
with
the
identification
of
how
important
managing
your
features
are.
I
think
the
the
the
shift
has
has
started
to
you
know
ensuring
that
feature
Flags
is
is
being
adopted
and
if
you
look
at
it
from
a
software
release,
workflow
perspective
I
mean
developers
the
writing
code,
but
you
know
any
changes
are
put
behind
a
feature
flag,
so
that
makes
the
living
code
on
time.
Testing
features
for
impact
easier.
A
If
you,
if
you
talk
about
you,
know
devops
Engineers,
releasing
code
to
production,
it
becomes
makes
deployment
easier
and
and
helps
bring.
You
know
change
to
the
process
and
it
continues.
I
mean
you
move
on
to
the
product
manager
side
and
then
obviously,
the
the
customer
facing
side.
So
it
acts
in
a
loop
where
the
value
you
know
eventually
helps
you
iterate
on
your
features
faster
and
and
deliver
features
with
with
quality,
as
we
spoke
about
during
the
value
of
feature
Flags
and
from
business
perspective.
A
As
you
can
see,
this
is
an
example
of
a
new
UI
feature
flag
that
we
have
taken
and
that
I
mean
they.
They
can
be
managed
in
terms
of
Kit,
Ops
or
yaml
files,
and
it
helps
you
know,
automate
your
business
processes.
You
are
developing
and
then
you're
automating,
so
it's
it's
I
mean
and
and
then
eventually,
if
you
want,
you
can
create
your
flag
rules.
How
how
you
want
your
flag
to
behave
if
you,
if
you're,
not
sure
how
they
behave
you
you
know,
you
have
to
understand
that
feature.
A
Flags
get
applied
to
end
users
of
the
application
right
so
or
you
can
call
them
targets
or
other
other
systems.
You
may
call
them
users
sessions.
So
you
know
these.
These
targets
have
attributes
that
Define
and
that
there
are
various
attributes
that
can
be
there,
such
as
email,
licensing,
plan,
location,
other
characteristics,
and
then
you
can
use
those
attributes
to
decide
which
flags
to
serve
them
right.
A
So
I
I
took
the
example
of
a
new
UI,
but
let's
say
if
I
have
to
take
some
more
examples
of
of
what
what
can
be
used
or
or
what?
What
are
the
key
business
processes?
Then
you
know
they
they
involve
I
mean
making
the
velocity
better,
because
you
can
merge
your
feature
branches
sooner
and
deploy
more
often
without
worrying
or
isolating
complete
features.
A
It's
easier
to
control
the
state
of
changes
across
environments
with
less
custom
scripting-
and
you
can
add
these
things
over
to
your
stakeholders
to
decide
how
or
when
when
to
make
them
work.
So
moving
ahead,
how
feature
flags
do
it
or
what
are
the
best
ways,
feature
Flags
function?
It
helps
you
control
access
to
your
features,
as
I
mentioned
before,
there's
a
toggle
feature
that
that's
mostly
available
in
in
your
production
environments,
where
you
can
switch
on
or
switch
off
the
features
that
you
want.
A
It
helps
you
resolve
issues
without
without
roll
feedbacks,
as
you
mentioned
before,
so
it
just
helps
you
I
mean
avoid
roll
backs
and
and
save
time
and
I
mean
mitigate
risks.
Suppose
it
also
helps
you
deploy
in
a
smaller
sense,
which
I
mean,
as
as
we
spoke
about
large
deployments,
hosting
a
lot
of
risks.
A
I
think
if
you're
deploying
I
mean
features
one
by
one
or
in
a
smaller
sense,
then
obviously
there's
less
risk
in
in
terms
of
you
know,
run
time
while,
while
the
systems
are
in
production,
it
also
minimizes
the
blast
radius
of
changes
So.
Eventually,
there
are
a
lot
of
I
mean
you.
Can
you
can
serve
your
requirements
faster
and,
and
it
becomes
easier
for
you
to.
You
know:
go
ahead
with
your
deployments
or
your
feature
deployments
and
outside
engineering
itself.
A
As
we
spoke
about
your
sales
teams,
your
customer
facing
teams
they
they
are
eventually
empowered
with
how
feature
Flags
help
you
toggle
in
between
your
features
so
moving
on.
Let's
take
a
look
at
a
few
case
studies
and
what
are
the
challenges?
A
few
uses
of
feature
Flags
out
there
have
faced
so
I
mean.
Let's
take
a
look
at
this
Enterprise,
it's
called
enter
and
they
they
were
facing
a
lot
of
challenges
to
stabilize
their
pre-production
environments.
A
You
know,
as
as
development
teams
increase-
and
you
know,
I
mean
there
were
initially
12
teams,
and
then
it
became
20
teams
and
and
the
the
it
was
essential
to
reimagine
delivering
software
itself.
As
we
spoke
about-
and
you
know,
software
teams
have
their
methodologies,
they
they
might
end
up
using
different
feature
flag
providers
or
they
might
want
to
deliver
the
software
differently.
A
They
want
to
operate
their
deployment,
so
you
know
having
a
unified
approach
was
necessary,
and
that
is
why,
just
you
know
they
enhance
their
their
idea
of
software
delivery
with
you
know,
having
feature
Flags
in
place
which
help
them.
You
know,
increase
deployment
frequency
from
twice
per
week
to
14
times
a
week.
It
helped
them
decrease
their
change,
failure
rate
from
28
to
5
and
there's
a
there
was
a
reduced
rollback
time
from
two
hours
to
five
hours.
A
Eventually,
you
know
ensuring
that
this
feature
Flags
becomes
successful
for
them,
and
you
know
there
are
a
lot
of
fees.
Problems
that
you
know
feature
Flags
over
the
time
have
have
incurred
or
presented
in
front
of
the
community.
I
mean
teens
didn't
get
time
to
clean
them,
up,
leading
to
them
to
a
I,
mean
messy
or
strolling
code,
or
a
lack
of
clarity
around
which
flag,
still
matter,
I
mean
they're.
The
the
engineers
were
still
creating
their
Flags,
but
they
did
not
know
what
they
meant
they.
A
A
So
sometimes
it's
the
engineering
manager,
so
it
you
know
felt
like
playing
a
hot
potato
somewhat,
and
everyone
who
operated
flag
eventually
had
access
to
production
right
so
which,
which
felt
insecure
in
in
some
in
some
sense
team
started
feeling
insecure
and
you
know
that's
where
the
solution
came
into
place.
A
Where
you
know
you
have
a
discussion
up
front
of
how
to
clean
up
the
flags
promptly
once
the
feature
has
been
rolled
out,
decide
on
who
owns
the
process
and
agree
on
regular
view,
reviews
of
the
flag,
inventory
and
necessity.
The
the
recommendation
is
also
to
make
extensive
use
of
the
r
back
mechanism
and
bringing
a
security
and
compliance
methodology
into
process,
or
you
know,
by
deciding
who,
to
onboard,
to
feature
flags
and
with
what
permission
level
while
feature
flags
do
not
give
anyone
access
to
customer
data.
A
It's
obviously
necessary
that
you
know
that
you
should
know
your
intentions
about
who
has
that
access,
and
even
if
there
may
not
be
a
single
owner
for
a
flag,
it's
it's
very
necessary
early
on
in
development
that
it's
be
it.
A
It
be
relevant
to
a
cross-functional
group
to
have
the
conversation
and
outline
who
should
do
what
and
who
should
not
do
what
and
who
should
update
the
flags
at
different
stages,
and
this
is
the
learning
from
from
the
community
that
that
we
have
had
over
these
various
case
studies
moving
on
there's
another
case
study
that
there
was
too
much
risk
too
slow
for
a
release
process.
So
I
mean
again
this.
This
is
another
a
company
called
metricus.
A
They
needed
to
be
able
to
reduce
the
risk
of
feature
deployment
while
simultaneously
increasing
the
velocity
at
which
they
shipped
code,
and
there
I
mean
they.
They
believe
that,
eventually
it
helped
them.
You
know,
apply
CI
CD
in
a
in
a
proper
way
where
it
was.
It
wasn't
just
about
I
mean
applying
cicd,
but
you
know
making
it
faster:
releasing
features
to
customers
in
a
faster
sense
and
making
it
I
mean
easier
for
them
to
you
know,
commit
to
production,
I
mean.
A
If
you
have
to
talk
about
them
itself,
then
I
think
they
they
reduced
production
I
mean
competing
to
production
by
66
percent,
and
they
they
are
able
to
take
smarter
risks.
Feature
development,
help
them
solve.
Two
I
mean
two
major
problems.
That
is
one
is
they
don't
have
to
decide
internally
on
how
or
who
has
to
create
it
and
then
how
how
to
push
it?
So
it
becomes
more
Diversified.
The
responsibility
of
releases
become
more
Diversified
as
as
it
says.
A
And
lastly,
if
we
talk
about
this
use
case
style
attack,
so
their
their
product
teams
were
asked
to
have
more
control
over
feature
releases
and
exposure
instead
of
deployment,
and
they
they
had
to
I
mean
they
take
the
next
step
in
leveling
up
the
increase
in
velocity
and
controlling
their
software
delivery
processes.
So
I
mean
they
they
wanted
to
achieve
unparalleled
velocity.
A
I
would
say,
I
mean
that's
where
I
believe
that
CI
CD
is
not
enough,
and
you
know
feature
Flags,
obviously
help
you
integrate
better
with
the
CI
CD
side
of
things,
and
it
makes
your
I
mean
the
customer
account
team,
responsive
and
helps
deliver
features
as
as
we
we
mentioned
previously.
A
So
with
this,
we
will
just
talk
about
what
are
the
best
ways
to
I
mean
deliver
features
and
manager
features
it's
necessary
for
you
to
have
a
Flag,
Management
dashboard,
which
helps
you
manage
these
flags.
There
has
to
be
a
global
governance
enforcement,
as
we
spoke
about,
so
that
governance
is
better,
there's
a
flexible
user
targeting
so
so
that
your
I
mean
your
users
are
flexible
in
terms
of
getting
access
to
these
features,
and
you
can
you
can
build,
deploy
and
release.
A
That
comes
up
as
a
challenge
with
feature
Flags,
and
with
with
that,
you
know
you,
you
need
to
continue
to
scale,
improve
your
feature.
Management
side
of
things
ensure
that
there
are
minimal
rollbacks
and
how
you
can
you
can
deliver
feature
in
the
better
sense
and
and
obviously
release
confidently
with
with
Pipelines.
A
So
with
this
I
think
we
we
come
to
the
end
of
this
talk,
but
in
the
end
obviously
I'll
like
to
give
you
a
gist
of
things
that
you
know
we
spoke
about
how
half
each
Flags
are
essential.
What
are
the
risks
during
software
delivery
and
obviously
how
you
can
ensure
that
software
delivery
is
managed
in
a
better
sense?
A
You
can
ship
code
faster
and
toggle
around
your
features
as
and
when
required,
so
that
you
can
deliver
them
to
the
end
users
in
in
a
better
sense
and
and
mitigate
all
the
risks
that
come
come
up
with
the
challenges
of
software
delivery
and
for
that
I
also
would
love
to
invite
you
to
the
feature
Flags
community
that
we
are
building.
It's
a
meter
group
as
well
as
the
slack
community,
and
we
we
will
talk
more
from
a
community
aspect
about
feature
Flags.
A
What
can
be
done
better
by
Future
Flags,
not
just
essential
for
developers
but
all
personas,
and
obviously
we
look
forward
to
learn
more
alongside
you
in
terms
of
feature
management
and
feature
Flags.
So
with
this.
Thank
you
so
much
for
tuning
in
and
see
you
next
time.