 In this video, we are going to talk about rolling deployments with OpenShift. At this point, I have an application that has a PHP front end and a backend database with MySQL. And this application has been configured in such a way that the source code is in a GitHub repository. And I have taken the web hook from this application running on OpenShift. And this web hook has been configured inside my Git repository so that whenever there are, if there is a commit made to this repository, to this project on GitHub, then it will automatically trigger a new build on OpenShift. And also, at this point, we only have a single pod running the front end on OpenShift. So when we make any changes to this application, this is the part that gets updated. Now let us make a small change to this application. I am going to open the dbtest.php file and add a small line. I'll write and commit these changes. I committed it into the local Git repository and I am going to push it now. Now as the changes are getting pushed, you'll see that it will trigger a new build. And this is the new build that got triggered. And once this build is complete, the new image that is created with these changes will be deployed onto that pod that is currently running. So when it's about to deploy now, let me keep refreshing the screen to see what happens to this pod. Now the application is getting deployed. And you will notice that there is a slight downtime here and now it's back again. So the application goes down because there is a single pod running and at that particular point of time when that pod goes down and the new code change, the new image is deployed, you see a 503 for a little while. So for this exact reason of that little bit of downtime, right, OpenShift provides an option for rolling deployments. Now if you see the number of pods that are running for this front end is just one. If you have a scaled application and you have more than one pod running for this application, when you make code changes and do the same thing that we did before which is make code changes and push them and when the build is done and when it is trying to get deployed, it will not bring down all the pods at the same time, it will do one at a time or some at a time. So that way it'll ensure that your application doesn't go down and you don't get that 503. So let's look at that. Now first I'm going to resize the application to scale to four pods instead of one. So let me do that. Now, if I check the number of pods, there are one, two, three and four and two are on note two and two are on note three. Now let's go back and make another code change and push it. At this time, I'll go back again and check and the build is now running again. The deployment is now in progress. Now let's see what happens. Keep watching the screen and you'll see that this pods are, now one of the pods is at least updated. The other part is not updated. So you are seeing this end of the list appearing in the output on some of the pods and not on some of the pods. So the application is not coming down. Instead, the pods are getting updated one after another. You'll notice that the end of the list was missing on some of the pods and now it's like all the pods are now updated and running. So everything is up and running. So I should get the same output. So every pod is updated. So this is the process of rolling deployments where the application doesn't go down completely. It doesn't give a 503 like before. When there are multiple pods, the pods are going through a rolling deployment process.