►
Description
With maturity of CI/CD, monitoring and networking ecosystem - progressive delivery has become possible and much easier to implement. In this talk we will understand what it takes to do progressive delivery so that you can prepare your organisation and teams to get progressive delivery right. We will also cover some best practices we learnt when implementing progressive delivery for a healthcare company and talk about various OSS technologies we evaluated in the journey.
A
So
vishal
both
are
from
infra
cloud
technologies
and
vishal
is
an
engineer
and
cto
at
in
fact
technologies.
He
helps
companies
transform
their
businesses
by
using
technology
and
coaching
people
and
he's
also
a
contributor
to
fishing,
which
is
a
fast
and
secret
service
function
for
kubernetes
and
vishal
is
also
an
organizer
for
kubernetes
and
cncf
meetup.
A
A
B
Thank
you
for
being
present
here.
My
name
is,
and
I'm
working
at
infra
cloud
as
a
staff
engineer,
so
at
infrared
cloud
I
mainly
work
to
help
clients
to
handle
their
needs
in
regards
to
infrastructure,
design,
scale,
modernization
or
stability
around
their
application.
Using
cloud
native
stack
like
kubernetes
and
a
bunch
of
other
tech
stack
that
normally
falls
under
the.
C
Cool,
so
you
have
definitely
heard
the
classic
saying
that
you
know
move
fast
and
break
things.
I
think
this
was
popularized
by
the
facebook
ceo
around
2014
or
so,
and
this
is
pretty
popular.
You
know
saying
that
as
a
product
or
as
a
company,
you
should
move
faster.
You
know
break
things,
but
I
think
we
are
living
in
a
world
which
is
changing
now.
C
We
definitely
want
to
move
fast
without
actually
breaking
things,
and
we
will
learn
today
how
to
achieve
this
in
the
context
of
software
with
progressive
delivery
in
context
of
software
development
right.
So
before
we
go
further.
Let's
understand
the
word
progress.
What
does
it
mean?
So
if
you
take
the
literal
meaning
of
the
adjective
progressive
from
the
it
means
something
that
happens
gradually
or
in
stages,
and
I
think
this
is
a
crucial.
You
know
thing
to
keep
in
mind
as
we
as
we
progress
into
talking
about
progressivity.
C
So
one
thing
I
want
to
clarify
a
friend
is
progressive.
Delivery
does
not
mean
you
stop
doing
continuous
delivery
and,
in
fact,
if
anything,
progressive
delivery
rests
on
the
foundation
of
solid,
continuous
delivery,
and
you
know
builds
on
top
of
that
I
would
say
so
what
is
progressive
level?
You
know,
I
think
this
diagram
sums
up
the
concept
kind
of
very
nicely.
C
The
idea
is
to
develop
software
in
production
or,
if
not
possible,
in
production
as
close
to
production
as
possible
in
an
incremental
and
gradual
way,
and
this
could
mean
you
could
release
it
to
a
set
of
users
or
sometimes
to
set
up
testers.
But
the
goal
is
to
do
this
in
production,
because
anything
else
is
not
like
production.
C
Now
you
must
be
wondering
why
you
know
that
is
so
important
right,
so
testing
in
production
like
environment
right.
So
let's
take
a
couple
of
scenarios.
Examples.
We
have
tried
this.
You
know
approach.
For
example,
companies
try
to
set
up
the
whole
thing
on
a
developer's
machine,
but
it
is
anything
like
real
setup.
The
issues
come
from
resource
exhaustion
or
lack
of
resources
on
your
developer
machine,
or
sometimes
you
can't
run
an
elastic
or
kind
of
production
grade.
C
Now
other
scenarios,
you
know
you
try
to
test
in
production
like
environments
like
staging,
for
example,
right
staging
is
often
touted
as
production,
but
it's
still
not
the
same
as
production
and
if
you're
in
industry,
you
know
where
compliance
is
huge,
for
example,
key
power
pci
your
database
is
never
the
real
database
or
size
of
database.
It's
like
a
smaller
replica
of
the
actual
database
right.
Similarly,
you
may
not
have
observability
in
the
production
environment.
The
way
you
have
in
you
know
other
environments,
for
example
right.
C
Lastly,
today
it
is
not
just
for
application
anymore,
you
know
it's
all
systems
which
are
sometimes
very
unique
to
production.
For
example,
your
configurations,
your
infrastructure,
the
kind
of
traffic
that
you
have
it's
very
hard
to
replicate
the
vr
in
production.
It's
almost
hard
to
replicate
in
any
other
environment
right,
so
no
matter
what
you're
not
testing
the
way
you
test
in
production.
That
also
means
some
behaviors.
You
will
see
only
in
production,
not
in
other
environments.
Right
and
that's
where
this
is.
C
So
now
we
are
living
in
a
fairly
new
world
where
things
have
changed
quite
a
bit
in
the
way
we
deploy
in
the
way
we
observe
the
way
we
manage
and
stuff
like
that
right,
but
the
way
we
do
software
testing,
you
know
whether
we
bring
everything
together
and
try
to
do
a
testing
on
that
whole
entire
setup
hasn't
changed
a
lot
and
it
still
you
know,
follows
the
very
traditional
practices.
In
a
way
I
would
say
so.
You
just
don't
need
to
stop
testing.
C
You
know
because
you're
in
production,
in
fact,
testing
in
production
is
actually
happening
literally
by
users
on
continuous
basis,
but
we
need
to
leverage
the
state
of
the
r
tools,
the
state
of
the
art
that
is
available
in
production,
in
a
way
that
they're
able
to
test
it
without
impacting
you
know
anybody
else.
For
example,
you
can
do
canary
you
can
do
traffic,
shifting
or
shaping
and
stuff
like
that.
C
So
you
of
course
have
seen
the
classic
meme
that
you
know.
I
always
don't
test
my
code,
but
when
I
do
I
tested
in
production
now
this
might
have
sounded
like
a
meme,
probably
a
couple
of
years
ago
or
maybe
half
a
decade
ago.
But
technically
I
would
say
it's
reality.
Today
we
can
test
in
production
in
a
very
sophisticated
and
a
very
you
know,
interesting
mannerism.
C
B
B
Okay,
and
so,
as
vishal
has
already
stated
right,
so
these
deployments
can
be
in
production
can
be
tested
in
three
ways.
You
can
test
it
at
a
deployment
after
deployment
by
using
some
other
form
of
integration
test,
or
you
can
do
it
after
the
candy
or
any
other
kind
of
release,
and
you
can
also
do
in
post
release
section
where
you
are
continuously
monitoring
it
and
checking
by
some
or
other
way
of
let's
say
doing
a
testing
either
a
b
test
or
chaos
test
in
post
release.
B
Part
of
the
same
okay,
so
yeah
and
progressive
delivery
is
not
always
about
candy
or
blue
green
or
a
b
forma.
It's
much
more
than
that.
So
you
must
be
wondering
like
how
we
should
do
this
deployment
where
we
are
deploying,
but
not
releasing
to
the
end
users.
So
there
are
different
techniques
available
for
the
same
and
let's
look
into
them
now.
Okay,
so
first
technique,
I
would
say,
is
the
future
fracking.
B
So
this
is
essential
technique
where
basically,
you
inject
a
flag
on
top
of
every
functionality
or
code
block
that
you
develop
or
you
have
written
and
by
some
other
way
you
allow
users
or
by
yourself
to
enable
that
flag
and
after
only
enabling
that
flag,
the
new
version
of
your
application
is
available
for
your
users.
Okay,
so
sometimes
you
might
have
seen
the
case
where
you
have
been
logged
into
the
application,
and
it
shows
you
at
the
right
on
the
top
saying
we
have
our
new
version
available.
B
B
B
You
want
to
move
to
the
new
version,
let's
call
it
as
a
version
35,
so
you
will
create
exact
replica
of,
or
you
can
say,
exact
infrastructure
with
new
version
of
your
application.
You
do
all
your
end-to-end
testing
and
once
you
are
confident
enough
that
my
new
version
is
working
fine,
then
only
you
move
to
the
new
version
and
cut
down
all
the
old
version
of
your
application.
B
So
the
term
candy
deployment
comes
from
old
coal
mining
technique,
so
these
mines
were
always
containing
some
or
other
hazardous
gases
that
could
kill
the
miners,
so
canary
birds
were
most
sensitive
to
airborne
toxins
than
humans,
and
so
miners
used
to
use
them
to
detect
these
things.
And
so
similar
approach
is
with
the
calendar
deployment
where,
instead
of
putting
the
entire
end
users
in
dangers
like
in
case
of
big
bang
deployment,
we
instead
start
releasing
our
new
version
to
a
small
subset
of
users.
B
B
Apart
from
that,
there
is
a
new
technology
or,
I
would
say,
technique
called
as
a
adb
testing.
So
let's
say
I'm
a
part
of
a
product
development
team
itself
and
we
would
be
having
always
these
kind
of
huge
debates
where
one
person
is
saying
you
know
we
should
have
our
login
icon
at
the
right
top
side
corner.
Someone
is
saying
no,
we
should
have
it
at
the
center
or
someone
saying
at
somewhere
else.
B
A
B
Okay,
and
apart
from
that,
there
is
also
this
technique
called
as
a
tab
compare
which
is
a
kind
of
internal
testing
mechanism.
I
would
say
so.
What
we
do
normally
in
this
kind
of
technique
is
capture
your
production,
traffic
and
route
it
to
the
new
version
as
well,
and
compare
the
result
of
your
old
version,
as
well
as
new
version
and
based
on
the
response
decide
whether
should
we
move
forward
or
not,
and
apart
from
that
there
is
this,
also
a
method
where.
B
Shifting
mechanism,
so
you
can
use
service
messages
or
engine
x
kind
of
english
controllers,
where
you
would
gradually
send
traffic
as
part
of
your
candidate
release
and,
at
the
same
time,
with
help
of
your
internal
teams.
Maybe
you
can
either
pass
some
custom
headers
to
your
nginx
controller
and
do
all
the
testing.
At
the
same
time,
you
would
be
able
to
use
the
user
traffic
as
well
to
determine
whether
we
should
promote
ahead
or
not,
and
I
will
let
now
we
shall
to
take
further.
C
C
So
so
it's
important
to
spend
the
time
and
get
it
right
rather
than
you
know
hurrying
into
it.
I
would
say
beyond
that
also
takes
preparation,
because
it's
important
that,
if
you're
doing
something
like
this,
you
are
testing
production,
you
don't
want
to
have
any
unintended
consequences
on
other
users
who
speak
right.
For
example,
you
can't
if
you
can't
make
sound
decisions
about
you
know
whether
your
new
version
of
the
system
is
producing
more
errors
or
less
errors.
You
probably
will
not
be
in
a
good
shape.
C
You
know
make
that
call
right,
so
you
need
to
have
a
good
observability
system.
Similarly,
you
need
to
have
a
good
rollback
and
you
need
to
go
forward
system.
You
need
to
have
the
right
schema,
you
know
changes
and
backward
compatibility
built
into
it
should
speak
right,
so
such
changes
will
need
that
changes,
but
also
you
as
an
organization
or
a
team,
are
culturally
understanding
the
trade-offs
and
making
the
right
decisions
over
here.
Basically,
now,
let's
look
at
the
look
at
aws.
C
You
know
reloaded
example
that
the
public
talked
about.
So
typically
our
application
goes
through
four
phases.
We
have
source
code,
then
we
build
tests
and
you
know
eventually
take
production
through
some
sort
of
pipelines
right.
But
if
you
look
at
in
a
zoomed
in
way
in
each
of
these
areas,
how
aws
does
it
for
their
services
so
in
the
source
and
build
area
itself
right?
They
have
automated
pipeline
for
every
piece
of
things.
C
C
For
example,
alpha
or
beta
might
be
more
about
understanding
the
functionality,
whereas
gamma
is
almost
like
production,
where
your
monitors
and
other
alarms
are
as
good
as
production,
and
you
get
a
pretty
good
sense
of
how
good
this
service
is
performing
right
now
at
aws
scale,
when
you
refer
to
production,
which
is
the
next
step
in
the
logical,
you
know
movement,
you
don't
want
to
again.
You
know
affect,
because
your
users
are
globally
spread,
and
you
know
they're
using
at
various
time
zones
and
stuff
rapid.
C
So
the
production
route
actually
follows
a
fairly
detailed
wave
based
approach.
Basically
right,
you
move
slowly
from
one
stage
to
another
stage
and
and
based
on
certain
decision
points
you
know
in
the
previous
stage,
you
decide
whether
to
continue
to
next
stage
or
you.
You
know
kind
of
pause
at
that
stage
and
you
know
roll
back
and
stuff
right,
one
very
important
concept.
There
is
big
time,
and
I
think
this
is
a
fairly
you
know
basic
or
stroke
time
as
it
is
called.
You
know
in
many
companies
industry
right.
C
The
idea
is
that
a
lot
of
times
when
you
deploy
a
change,
the
effects
which
might
be
good
or
bad
are
not
immediately
visible
in
you
know,
5-10
minutes
right.
Sometimes
it
might
take
20
minutes.
Sometimes
it
might
take
an
hour
right
so,
based
on
how
far
ahead
you
are
in
the
pipeline
of
progressive
delivery
and
how
huge
the
change
is,
how
huge
the
impact
would
be.
C
Your
break
time
could
be
sometimes
an
hour
or
sometimes
it
could
be
12
hours
before
you
decide
to
move
to
the
next
stage
right
and
then
you
have
some
metrics
that
you
have
thought
through
and
designed
beforehand,
where
you
take
a
call
whether
this
is
a
positive
sign
which
would
move
ahead
and
and
those
matters
are
meeting
you
know
their
required
kind
of
anticipated
levels,
basically
right.
So
having
talked
about
this
I'll,
let
nina
continue
and
talk
about
some
of
the
tools
in
this
space.
A
B
Move
towards
which
tools
can
help
to
do
some
kind
of
code
parenting.
I
would
say
part
of
this
progressive
delivery.
I
mean
which
tool
can
help
you
to
enable
progressive
delivery
at
your
requirement.
So
there
are
currently
a
couple
of
tools.
Several
like
argo,
cd,
flagger,
spinnaker,
launch,
darkly
or
optimizely
flagger
and
argo
city
are
quite
a
major
one
being
used.
I
would
say.
B
Community
and
another
by
viewer
of
streams,
my
personal
opinion
is
both
tools
are
really
good.
Both
tools
have
had
add,
really
good
features,
except
that
rbc
comes
with
the
gui.
If
someone
need
understanding,
maybe
okay,
which
tool
I
should
give,
I
should
go
for,
I
would
say
if
you
have
flexibility
or
system
already
in
place,
maybe
go
for
flagger.
B
So
I
just
wanted
to
demonstrate
how
you
easily
can
convert
your
existing
deployment
objects
into
the
rollout.
All
that
you
need
to
do
is
first,
have
a
cargo.
Rollout
is
installed
on
your
kubernetes
cluster
and
then,
let's
say,
if
you
have
a
deployment
instead
of
deployment,
you
will
convert
it
to
kind
as
a
rollout
and
instead
of
strategy
as
a
rolling
update,
which
is
a
kind
of
default,
you
can
change
it
to
either
candy
or
bluegreen
and
now
in
terms
of
service.
B
If
you
have
one
service,
you
will
create
two
services,
one
will
be
handling
traffic
from
camry
and
one
one
will
be
handling
from
your
older
version.
Okay,
and,
as
I
said
right
when
you
are
doing
this
scanning,
you
would
might
need
to
do
some
kind
of
testing,
so
either
these
testing
can
be
performed
manually,
but
best
and
preferred
approach
is
to
do
it
in
automated
way.
B
I
would
say
now
that
I
learned
from
my
experience
as
part
of
insta
cloud
team,
where
we
happen
to
help
a
healthcare
industry,
business
client
to
achieve
the
progressive
delivery
using
candy
and
traffic
splitting
technique
using
our
labs,
so
make
sure
to
run
it
enough
times
and
make
sure
to
understand
that
this
is
not
what
you
are
going
to
get
correct
in
one
shot.
It
need
to
be
done
as
a
part
of
a
iterative
process.
B
Okay
and
yes
in
case,
if
you
want
to
do
some
more
deep
dive
with
hands
on,
please
do
check
out
the
recording
from
kcd
bangalore
event
where
we
have
done
this
workshop,
and
these
are
some
of
the
blogs.
I
would
say
that
you
can
check
it
out.
Definitely
to
get
some
more
in-depth
understanding
around
how
progressive
delivery
can
be
worked
out
yep.
So
that's
it
from
our
end.
Do
let
us
know
if
you
have
any
question
and
we
would
be
happy
to
help.