 Hello in this video will learn how to promote your application across environments in this example. We assume that there are three different projects for different environments development QA and production and we will set up these projects in such a way that the developer has edit access to the development project. The tester would have edX access to QA and operations would have edit access to production whereas the tester would have view access to the development project and the same as the operations would have view access to the development project. In the in the real example, I only deal with development project and the QA project production is the production project would be very similar to how we work with the QA project. So how does this work? The developer creates an application in the development project when the devil when an application gets created it it is built by open shift. A Docker image gets created and it will be pushed into the internal Docker registry now development project will have its own image stream which tells you what the what the images name is and what the tags for that image and that's that's where your image is pushed into to that particular image stream we would provide image pull access for QA project and the production project. So now once the application is built now the development product development itself might go through multiple cycles, right? So when the developer is happy with the application and thinks that this is the time to promote this into the QA environment. Let's say right at that point of time the developer can tag that image as ready to promote kind of tag, right? So and at that point of time that particular version of Docker image gets stacked and tester can pull that particular image to create the application in the QA project and same thing can be done in production once the testing is complete another question that comes up is if you're using a single installation of open shift I have some infrastructure where I want to deploy only production loads or I have some cheaper infrastructure where I can run my dev or QA. Can I really direct my workloads production workloads to specific infrastructure? Can I direct my developer workloads to specific infrastructure? That kind of question comes up. The answer is yes, it can be done to show an example of how it is done. Let's have a look at the default project. If you see the annotations here, there is something called a node selector annotation that you can define on a project and this can be done on any project. All it says is when you deploy anything onto this project the parts should run on the nodes with that are labeled as region equal to infra. Now if we have a look at our nodes in my setup anything that I run on in the default project will run only on this particular node in the same way for your setup. Let's say you have specific set of hosts that are meant for deploying production workloads. Let's say then you could set up something like environment equal to production as a label and then on your production project you can set up a node selector that points to environment equal to production and then all that workload that is created in the project will land up only on those particular set of hosts. Now let's create the project and assign permissions. So first I will create a development project and I'm using my username to create this project and in order to add other users for example as a as developers. I have a user with user ID developer dev one. I'll add that user as a developer. So I'll give edit access to the developer to this product. Now this particular developer can deploy applications onto this product. I will also add view access to a tester. I have a tester with ID test one. So I'm saying OC policy add role to user view access to the tester now. I'll also create another project and this is the Q a project and to this project I'll provide edit access to the tester. Now what we what did we do? We created the development project and we give edit access to a developer named Dev one and we give view only access to a tester named test one and we created a Q a project and we gave edit access to the tester. Next, I need to provide this testing Q a project to be able to pull images from the development project. The process is same for the production project. So I'm not doing this part. I'm just dealing with the development and Q a so you so that you get an idea. So in order to do this, I'm saying OC policy add role to group and I'm giving system image puller access to a service account that is created by default in this testing project, which is named as testing. This is the default service account will get image puller access on the development project, right? So I have created a testing project and there is a testing project default service account that gets the image puller access now. I'll log in as a developer and create a new application. So I'll log in as developer Dev one Dev one is a new user. The only project that developer has access to is development and this this is the default project that is getting used now. I'm creating a new application now. So I'm creating this new application based on a template. It's it uses the EAP six basic STI template and I'm providing all the parameters that the template expects. I'm calling my application as my app and I gave a host name my have my app have hyphen Dev which represents development dot apps dot demo v3 all the rest of the URL. Then I am pointing to my Git repository to pull the code from and I'm labeling my application as my app in a few minutes this application will be built and deployed. So I'll pause for a moment while the application gets deployed. The application is deployed and it is now running as a single pod and here is a URL that we gave my app hyphen Dev. Let me open this in a new tab. The application is running. You can see that I have put a version one as a representation here to just know what version of application is running. Now, let's look at the image streams that that are there in this development project. There is an image stream called my app as part of the development project and if I describe this image stream, I'll I'll can see the full name of the image. I'll make a copy of this and now let's say the developers have created this application and they have tested it and I think that it is a candidate to promote into QA. Now in order to promote this into QA, the developers would go and tag this image. So I'm still logged in as a developer. I'm using a command called oc tag and I'm pointing to the full name of this image and I'm giving it a new tag name. I've called it development slash my app, which was which is already there, right? This is development slash my app and but I'm tagging it as promote just to indicate that I want to promote this to QA now. If I run oc describe image streams again, it will show me that there are two tags. One is the latest this will always be the latest and the other is promote which which is just assigned by me and they are both pointing to the same full image name. Now I'll log in as a tester and I'll switch over to the disaster as access to both development and testing and that for the development project. He has view only access. That's what we assigned right? But for the testing project, he has edit access. I'll switch over to the resting project and this time I will create an application by using the image that that is tagged as promote. So you can see I'm pointing to development slash my app colon promote which is the image tag and this is the tag I'm using to create my application inside this testing project. Now when I run this this time, there is no build and deploy. I'm taking an existing Docker image from the development project and I'm deploying it in the QA project. So there isn't there is no build process involved. I'm reusing the Docker image. So that got deployed pretty quickly. Now since I created an application directly by using the Docker image, I didn't use any template. So let me look at the service. I got to expose the service and when I expose the service around gets created and this is the URL that got assigned to this QA project this time. It's my app hyphen testing. This is the project name and let me pull that pull that up in the browser and here is the this this testing application that got deployed inside the testing project. This is the same version one. This was created based on the Docker image that's coming from the development projects image stream. Now I'll make some changes to this application. So let's say I will change the welcome message. Welcome to JVOS AS application running on pen shift and you have successfully this is version 2 commit this changes and now let me switch over and log in as developer again and in the development project. I'll start a new build. This will take a minute for the build to complete. Let's wait for it. The second build is complete. So let's and it should have been already deployed. So let's go and see I'll refresh this application and development and see what happened. Oh, there is a change JVOS AS application. Oops, there is a spelling mistake. There's a typo it's version 2. That's true. But now let's look at the QA version of this application. It's still running version one, which is the older version, right? It's it's not changed. Let's also look at as a developer in the development project. What does the ISA right? There is a the latest is now pointing to a newer version. Whereas promote is continuing to point to the older version. The earlier the latest was pointing to this version. So both are there, but the the Docker image the latest is pointing to the whatever was built just a couple of minutes ago, right? QA continues to stay on that promote where the promote tag is pointing to. So that's the reason why this QA application has not changed. It remains the same now. Let's make one more change. We'll fix this error made in this development version. Now I'm fixing this mistake that I did in the past as a developer and I'm being more careful this time and this is version 3 commit the changes make sure I'm logged in as developer and start a new build. Now build 3 has started. Let's give it a minute. Build 3 shows as now complete. Let's go back and rough just this page. Yes. Now the mistakes are fixed. It's version 3. Let's look at QA. It continues to be at version 1. Now let's say we test this application and everything is good. It's there are no mistakes in this application and now it's ready to promote, right? Now I go back to the development project and I'll find the tag for the latest which is the good version. So I'm using the full image name again and I'm applying the same promote tag on this new image now. So I'm running the same OC tag command and I'm taking the newer version of full image ID and I'm applying the same promote tag on that. So right now if you see the promote is pointing to whatever was the version one. It's ending in 98 F. The version one was 98 F the latest is now D1F and I'm trying to tag it as promote on D1F. So once I promote if I log in as tester and I switch over to the testing project by the time I came here a newer version got deployed about 14 seconds back. So which means I didn't have to do anything. All I did was I applied the promote tag based on which this QA version of the project was using the application as this application was created from promote tag and since that version of the application with promote tag changed it automatically redeployed it. Now let's go back and check the QA application this time the testing application if I refresh now it's running version three. So it's as simple as that the development goes through cycles they may have some versions of their doc development Docker images that are not ready to go to QA. So you will not touch this but when they are ready to pass them on to QA they can just go and tag them as okay promote to QA and it gets promoted to QA. So we have seen how a project can be promoted from development to QA and now the QA can have its own cycles and when they are ready to move it to production they can intimate operations and the production project can be set up exactly the same way how we did with the QA project to have image pull access from development and view access from the production project to the development project's image stream so that you are able to pull the images and the images can land in production in the same way. So this is how you can do promotion across the environments when OpenShift is managed as a single deployment and there are three different projects for development QA and production. Now there is another way that you could use where you have completely distinct OpenShift environments for development QA and production or maybe one environment for Dev and QA and a distinct one from production for whatever the reasons are. In such a case what you would do is expose the Docker registry outside. So OpenShift runs the Docker registry as a part. So you would expose the Docker registry's service with a name so that and make it accessible from the other OpenShift environment where the production project is running. So that way you would deploy the application in production for example by pulling an image from the Docker registry from the other OpenShift environment. So it's pretty similar, but it's two different environments. So your access is not within internally. It has to in your QA or production, you are actually pulling an image from a Docker registry from a completely different environment. I hope you enjoyed this video. Thanks for watching.