►
From YouTube: AB Testing on OpenShift Container Platform 3.3
Description
In this video, Veer Muchandi covers integrated A/B Deployments and how to test application changes in OpenShift Container Platform 3.3.
A
A
Hello,
this
video
is
about
a/b
testing
and
openshift
3.3.
If
we
have
watched
my
earlier
videos,
you'd
have
seen
how
we
did
a
bee
deployments
in
the
earlier
versions
of
OpenShift
so
open.
She
would
always
have
a
bi
deployment
model,
but
there
is
a
much
more
easier
and
integrated
approach
in
that
that's
introduced
in
OpenShift
3.3,
and
we
are
going
to
cover
that
in
this
video.
Let's
have
a
quick
recap
of
how
a
bee
deployments
work
in
OpenShift
version
3.3.
A
Let's
assume
that
you
have
an
application
version
1
and
you
call
this
app
a
when
an
end-user
tries
to
access
this
application.
Using
this
URL,
the
request
goes
and
hits
the
router
first
and
from
there
it
would
be
redirected
to
the
application
part
that
is
running
so
100%
of
this
traffic
gets
redirected
to
the
same
par.
A
You
introduced
this
version,
2
part
as
a
canary
now,
if
you're
happy
with
how
the
version
2
is
performing,
you
can
gradually
increase
the
percentage
of
traffic
going
to
version
2
and
reduce
the
traffic
going
to
version
1
and
let's
see
how
this
can
be
done
with
openshift
3.3
and
how
easily
it
can
be
configured
in
the
system.
So
just
like
in
the
last
video
I'm
going
to
use
the
same
exact
example:
I
have
source
code
in
my
github.
This
is
a
simple
PHP
page.
A
It
says
I'm
version
1
and
it
also
displays
the
IP
address
of
the
part.
Let's
use
this
code
to
deploy
the
application
and
selecting
PHP
app
version.
A
I
don't
want
to
create
the
route
yet
so
I
got
into
the
Advanced
Options
and
I'm
unchecking.
The
route
I
would
say,
create
the
build
is
about
to
start.
As
you
can
see,
there
is
a
service
created,
but
there
is
no
route
while
the
build
is
running,
let's
go
and
add
a
route,
so
I
want
to
add
a
route,
but
I
want
a
common
route
for
both
application.
A
A
and
B
so
I
will
call
it
app.
A
B
and
I'll
give
a
hostname
for
this
route,
and
this
route
is
currently
pointing
to
service
app.
A
the
build
is
still
running
in
the
meanwhile
we'll
make
this
route
unsticky
by
annotating
this
route.
So
I'm
annotating
the
route
that
we
just
created.
The
app
may
be
route
to
use
the
round-robin
Road
balancing
on
the
HF
proxy
router.
This
will
eliminate
the
stickiness.
A
A
The
build
is
now
complete
and
the
application
is
getting
deployed
and
it
is
running
now.
Let's
click
on
the
route,
to
see
what
the
output
is.
So
it
says,
I
am
version
1
and
the
pods
IP
address
is
10.1
dot
5.
Now,
let's
make
the
quick
code
change
I'm,
going
to
edit
this
to
version
2
I'll
go
back
to
the
console
and
deploy
the
version
2
as
application
B,
again
I'm,
adding
to
the
project
this
time,
I'm
using
app,
B
I'll
use
the
same
repository
and
again
I
won't
create
a
route.
A
A
A
Now,
let's
go
back
and
set
up
a
B
I'm
navigating
to
the
route
and,
let's
edit
this
route.
Currently
it
is
pointing
to
service
a
and
let's
split,
the
traffic
across
both
the
oceans.
Let's
select
application
B,
let's
introduce
this
app
B
as
a
canary,
so
we'll
send
90%
of
the
traffic
to
application.
E
and
just
10%
of
the
traffic
to
application
can
be
I'll.
Save
this
and
that's
it.
You
can
see
the
graph
here
that
90%
of
the
traffic
would
go
to
app
a
and
just
10%
to
a
B.
A
Let's
go
back,
I'll
run
the
same
coal
again.
I
ran
this
20
times
and
you'll
see
that
9
times
it
went
to
version
1
and
once
it
went
to
version
2.
Let's
try
to
make
another
change.
I've
changed
this
route
and
edit
it
to
have
equal
weights
now
the
traffic
would
be
equally
distributed
across
both
the
parts.
A
So,
let's
test
that
you
can
see
that
one
request
is
going
to
version
1
and
the
second
request
is
going
to
version
2
and
it
repeats
so
the
traffic
is
equally
distributed
now,
assuming
that
we
are
happy
with
version,
2
will
further
edit
it
to
reduce
the
traffic
10%
and
90%.
Now,
if
we
come
back
and
check,
we
will
see
that
most
of
the
traffic
is
going
to
version
2.
So
that's
how
easy
it
is
to
do
a/b
testing
with
openshift,
3
or
3
thanks
a
lot
for
watching.