 Hello, this video is about A-B testing in OpenShift 3.3. If you have watched my earlier videos, you would have seen how we did A-B deployments in the earlier versions of OpenShift. So OpenShift always had A-B deployment model, but there is a much more easier and integrated approach 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-B deployments work in OpenShift version 3.3. 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 part. Now let's say you made a small change to this application and introduced version 2. You can instantiate this version 2 part and you can configure in the route that 90% of the traffic goes to version 1, for example, and just 10% of the traffic goes to version 2. You introduce this version 2 part as a canary. Now if you are 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. 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. I'm 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. Now it's a 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 and B. So I'll call it app AB 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 AB route to use the round robin road balancing on the HAProxy router. This will eliminate the stickiness. We can also look at the annotation that we just added on the route itself. So I navigate to the route through the web console and here is the annotation that I just added. This will tell the load balancer to use the round robin method to load balance across the parts that are behind this route. 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'm version 1 and the parts IP addresses 10.1.0.5. Now let's make the quick code change. I'm going to edit this to version 2 and go back to the console and apply 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. Now the build for application B, which is pointing to the second version of the application is now running. This will take a few seconds. The deployment of application B is now complete. Now the route is still pointing to application A and if I curl this route from my CLI I should only see version 1. Now let's go back and set up AB. 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 versions. Let's select application B. Let's introduce this app B as a canary. So we'll send 90% of the traffic to application A and just 10% of the traffic to application B. 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 AB. Let's go back. I'll run the same curl 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'll change this route to have equal weights. Now the traffic would be equally distributed across both the parts. 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 we'll further edit it to reduce the traffic 10% and 90%. Now if we come back and check we'll see that most of the traffic is going to version 2. So let's go easy to do AB testing with OpenShift 3.3. Thanks a lot for watching.