Welcome to our next guided exercise. In this guided exercise, we are going to be using the express-helloworld application. This is the application that we have developed in our previous credit exercise. If you are unfamiliar with this application, return to our previous guided exercise, either in this PDF or in one of our previous videos. In our previous guided exercise, we have modified the application and we have pushed the application into the forked repository, into the D0101x-app repository. This is our forked and on top of that, we created a new branch called devenv-versioning branch. Let's quickly take a look at what happened. This is our application. We have added the slash mars and buoyant. This is what we are going to be testing. Our application is in the express-helloworld directory. Let's just verify in the source control view that the branch exists on the devenv-versioning. The branch with the name devenv-versioning exists. Let's get to our guided exercise. In the step number one, in the first step, we are instructed to create a Developer Sandbox account. In this course, we are going to be using the Red Hat Developer Sandbox, which is an OpenShift Sandbox environment, and for that to work, all you need is a free Red Hat Developers account. Then you get an essentially free OpenShift Sandbox environment where we can deploy our applications and test the behavior of our applications in the OpenShift environment. I have opened up my Red Hat OpenShift Sandbox environment. If you are unfamiliar with this, would be all right, be sure to check out our previous videos on the web UI. You might be in the administrator perspective, and if you are, be sure to check the administrator perspective and switch to the developer perspective. I'll also be working in the -dev namespace or project. The project that we are working with is your username -dev. At this point, what we want to do is we want to deploy our application. Let's take a look in step Number 2. What we want to do is we want to create a new application. The application is a JavaScript-based Node.js application. We want to name it helloworld. That's fair enough. We want to use our Git repository, specifically, a good repository hosted on GitHub. The application, as we have seen, is in the express-helloworld directory. In the Git repository, there is a directory called express helloworld or express-helloworld, which hosts our application. We cannot forget that we made our changes in the devenv-versioning branch. This is very important because this is where we actually pushed our change. That's all well and good. Let's deploy our application. In the OpenShift environment, what I want to do is I want to click the Add button. This brings us to our Developer Catalog, which enables us to create our applications. We can click all Services. OpenShift comes with a number of services that enable us to create a number of applications. I can select languages and we want to deploy a JavaScript-based application. We see Node.js applications, and what I want to do is I want to select the builder image. I have my Git repository and out of the Git repository, I want to build my own application. I will select my builder image and I will click the Create Application. This is the source to image application, and that is exactly what we want. Step number 1, we have to provide the Git repository URL. This is the URL to our forked repository. I can go to my forked repository and select the HTTPS version of our cloning URL and paste it in. OpenShift does some validations for us and we see that the URL is validated. However, we also have some advanced parameters such as the branch and the directory that we want to build inside of this repository. Let's click "Show advanced Git options." The first option that we have is the Git reference. This is the branch that we want to build, and the branch name is, and let's just double-check, is devenv-versioning. The second parameter is the context directory. This is the directory that we want to build. Again, let's double-check, and this is the express-helloworld subdirectory. This parameter starts with a dash. This dash is very important because this is a path within the Git repository. Leave the dash in. This directory starts with a dash, and then has the name of the directory. Then all we have to do is change the name. We have application name is helloworld, the name is also helloworld, and then we are also instructed, if I'm not mistaken, to create a DeploymentConfig. That's fair enough. We can do that. Because we want to make this application accessible on the Internet, we verify that the Create a route to the Application is checked. One last check. The Git repository URL is a fork repository. The URL contains your user. The Git reference is the branch name, so that will be devenv-versioning, and you should double-check that this branch name actually exists. If you created a branch that's called devenv-version and here in the OpeShift Web UI, you specified the branch name versioning, for example, the two will mismatch and you will not be able to build your application. I have verified that the devenv-versioning does exist in VS Code. Then the context directory parameter starts with dash and then contains the name of the directory. In our case, it is the express-helloworld. Sorry, it starts with a slash not a dash. It starts with a slash and then contains the name of the directory, and then we have simply a name of the application. This all seems fairly good. Let's create our application. There we go. We have our application. If I hover over this green checkmark, I see that the build is complete, I can also click on this application and click the "Details tab " and I see that one pod is running. From our previous videos that a pod contains a container, one or more containers and a container is the application. A container is a process that contains the application. This seems like our application should be accessible from the Internet. We have selected that the route should be available. I can either return the Resources tab, scroll down and there is a route, or I can simply click this "Open URL button." I can open it in a new tab, and fair enough, there's our helloworld message. However, this is just part of the application that we wanted to write. This is the original application. Now what I'm really interested in is the Mars endpoint because, this is my part of the application that I added. Let's test that part of the application. There we go. If I add /MarsEndpoint, and I hit "Enter", I see the Hello Mars application. We see that we were able to instruct OpenShift to basically go and clone our Git repository and we were able to take our branch and build and deploy our code to on Red Hat OpenShift which is in the Cloud. This is an excellent first step on becoming a Cloud native developer with Red Hat OpenShift. This is one last thing that I want to do, and that is because we are using the developer sandbox. The developer sandbox has one restriction, which is the namespace or the project restriction. We are using the same projects throughout the course and so what I want to do is I want to clean up the project. I want to delete all of the resources that we have created throughout this guided exercise. We can do that in a number of ways. We can for example, click this project view, and in the project view we can delete the resources one-by-one. Later, I will show you a better way of deleting the resources, but for now we can delete them one-by-one. Let's start with the route. I can delete the route, and I can click these three dots and delete the route, so I can refresh my browser to see whether the route has already deleted. One thing that I want to mention is that previously I have noted that a route is a way to get back to my application from the Internet. Back on the topology view, we can verify that the application is still running. We see that there is a one part that is running. However, in the resources, the route is no longer there. I still have my window open that's previously worked. Now that I have deleted the route, I can refresh, my application is no longer available. This is just a nice verification that the route actually does what it's supposed to do. When the route does not exist, the application is not accessible from the Internet.Back to deleting our resources, so that was our route. We can delete our service as well. In the same manner, let's delete our service. Let's go into our project, again. We have zero services. It seems like our service has been deleted. That's excellent. Let's click our "DeploymentConfig", and in the same way I will delete the DeploymentConfig. Here I definitely want to keep the delete dependent objects of this resource checked. There's DeploymentConfig. This DeploymentConfig manages the port with the application, and so when I delete this DeploymentConfig, it deletes automatically the application port. Let's delete this DeploymentConfig. Back in the project view, we still have some secrets. We have two secrets to delete, which is the helloworld-generic-webhook-secret and helloworld-GitHub-webhook-secret. I can delete them one-by-one. Definitely let's not forget about the build. We have the helloworld build, which is represented by the BuildConfig object, so let's delete that one as well. Back in the project view. This looks fairly well. Back in the topology view, we see that our topology is clean. This concludes our guided exercise, and I'll see you in the next video.
