 Let us take a look at a common deployment pipeline example. If you look at this flow, we are talking about how the code changes made by the developer and submit across different environments like how they get compiled and built, how they get into the development environment and then QA environment, pre-production and production environments. Now, when you think in terms of DevOps, automation plays an important role and also the provisioning of these environments play an important role. So what we are doing here is trying to get some tools together and execute this flow in a seamless fashion so that you can achieve things like continuous delivery. So this example is built around continuous delivery. However, you can also do continuous deployment in the same fashion. In case of continuous delivery, you do not go all the way up to production in terms of automated deployments. In continuous deployments, you can actually automate the deployment all the way up to production. If you look at this flow, this is a common flow that all the developers understand. This is not a prescribed flow or anything, it's just an example. Now, the developer commits the code changes into a source control repository and during the build phase, the compiles are done. Units are run, quality lists are run and once all these things succeed from the build environment, the build code will be automatically pushed into the development environment and in the development environment, integration tests would be run and once it is ready, the QA team can be notified to push a button and deploy the same build into the QA environment for testing. So the QA could have some automated testing tests run in their environment as well as some manual user testing can happen in the QA and then it goes into production and the operations team would deploy the same build into production. Now, let's see by using a build pipeline how we can enable it. Now, let's look at the tools used here. We would have a source control repository. In our example, we'll be using GitLab as a source control repository where when the developers make the changes, they would be checking those changes into GitLab. We would also have an enterprise continuous integration and continuous delivery server and Jenkins will play that role in case of the example that we are seeing. You could be using any build server but in this example we are using Jenkins. You could have an enterprise artifact repository where the compiled artifacts are stored and the development QA and production environments are provisioned in OpenShift. So all these tools are coming together. We will be using a sample KitchenSync application in our example and this application is available as part of GitLab and let's clone the Git repository onto my local machine first. It is cloned and I am moving into the KitchenSync folder. Now, I also open the GitLab in my browser and this application is running in three different environments and these environments are distinguished by using OpenShift's namespaces. As you can see, the application is now running in development environment which is with namespace ks-dev. The same app is running separately in the QA namespace which is ks-qa and the same app is running in the production as well, ks-prod. Now, we have used your namespaces to separate out the environments but in the real world you could be setting up three completely different OpenShift environments for dev QA and production. I also wanted to show you that there is a build pipeline in Jenkins that we have built and this build pipeline has, as we have seen in the figure earlier, right? There is a build phase where once you make changes and check in those changes into the source control repository, it will be automatically picked up by this commit phase. This will compile the changes and it will do the building and it will run some unitess and after that it will automatically deploy the changes to development and then after that once the changes are ready in development and are tested when they are ready to go to QA, then the QA person can come and manually click a button to do the deployment to the QA and the same thing happens with production. Let's see how it goes. Now let me make a small change to this application and check in the code. All I'm going to do is make a change to the header. It says welcome to KitchenSync. I'll add on OpenShift. This is a small change. I'll save these changes. Now I'll commit the changes to the Git repository and I'm now pushing the changes to GitLab. Once I push this change, it should automatically trigger the build process in the build pipeline. There you go. Once the commit phase is complete, it will automatically trigger the build process again in the development. At the end of this build, you will notice that an email gets sent by Jenkins to my email address saying that the build is ready. It says the new build is available and it is in ks-dev.apps.osclot.com. Now if I go back to the development environment and refresh, I should see the changes. Welcome to KitchenSync on OpenShift. As of now, the changes are only moved to development. In QA and in production, those changes are not there. They're only running in the development. Developers have a chance to completely test this application and then notify the QA that their build is ready to move to QA. Now let's log out and log in as QA and look at the build pipeline. Now you see that the QA has a button here to trigger the build process in the QA environment and the QA goes and triggers a build. Now this application gets deployed into the QA environment and all the tests are run. It's done. Now at this point, I'll have another email that the build is ready in the QA environment and this points to ks-qa.apps.osclot.com. So let's go back and check in QA. The application is available in QA. But in production, the updates are not there yet. So we'll go back to the build pipeline and we have this button for production and I'll trigger a build for production just like how I did for QA and this should build for production. It's done. So now at this point of time, if I go back and check my emails again, I should see that there is one more email that says that it's available in production. Now the production should be updated. So to summarize what we have done so far, we have used Jenkins with OpenShift to create a build pipeline for continuous delivery and using that, we have, when the code changes are checked in by the developer into a source controller repository, it automatically gets picked up and it moves across different environments. Some of these moves that we have done from development to QA and from QA to production, we made the manual processes to trigger manually but they can also be completely automated if we want to achieve a continuous deployment instead of continuous delivery. Now if we had errors during the build process, then for example, if there were compilation errors, they would have stopped during the commit phase. If we had any errors during integration tests, it would have stopped during the development phase and would not move forward. And if there were errors during the QA testing, then they would have stopped here. So that's also part of the build pipeline itself. Now that completes the demo of how OpenShift and other tools can work together to enable DevOps.