 Hello. In the last video, we used Launcher to generate code, added that code to the Git repo and deployed that code on an OpenShift cluster, and we saw how that code runs. In this video, we'll use a code that was generated by the Launcher last time. We will edit that code using a containerized IDE in code-ready workspaces. You are currently looking at a code-ready workspaces dashboard. This dashboard allows you to select from different kinds of stacks for different technologies. We will be selecting the Spring Boot stack, but before we do that, let's go back and see how the code-ready workspaces actually runs on an OpenShift cluster. This is a project where the code-ready workspaces is deployed. The dashboard that we just saw is displayed based on this part that is running. This is your workspace master. It is supported by a Peaclub server and a 4-space-equal database that stores the user input. Now, when we create a new workspace, this workspace master would go and start up a new workspace part based on the stack that we have selected under this technology list. I'll leave the name as what was generated by default, although I can use a specific name of my choice. Let's select Spring Boot application because the code that we generated earlier with the Launcher is a Spring Boot app will leave the default size of the machine. Now, when I select the stack, it goes and downloads this container image to start up the workspace. Let's add the project. I'll copy the GitHub repo link and paste it here as the URL to get the code from. See Add and let's create the workspace. At this point, if we go back and check the console, there is a new workspace part that is coming up, which you can see that it is getting ready now. And at the same time, if you look at the code-ready workspaces, it is actually pulling that container image for the workspace and it is starting a container inside a new part. So each time a developer creates a new workspace, that workspace starts up in its own new separate part. Now, this workspace part is the place where your IDE runs, which is equal state, and it provides a runtime for your application to be tested locally. It also provides a space to copy the code, make some changes, and test it locally. So this is kind of your workstation running inside the container, which is called a workspace. The workspace just got ready. It is configuring the code, it is pulling the source code, and it is setting up the source code inside the workspace now. Project got imported. So let's see the code. You'll find the source code, all copied from the GitHub. Now, we'll have to make some changes to this code so that it can be used locally within the workspace. Just like a local workstation, in this workspace, we don't have a database to connect to. So let us try to change the palm dot XML in such a way that we can use a local H2 database instead of the PostgreSQL database that got deployed on the actual development environment. So this is our local environment where we want to connect to a local in-memory database. So I'll edit the palm dot XML file, make it bigger. Let's navigate to profiles, and I'll add a new profile. The ID for this profile, I call it local. It is active by default in this workspace, and I have defined a dependency to use H2 database here. There's no need to save it. It gets saved automatically. But in order to build the application, we also need to define the Maven command to build and run. So I'll add a Maven command here. We'll call it build and run, and we'll change the command to run Springboard. The first one is an option to increase memory for this build process. Maven Springboard run to run Springboard locally. While running Springboard, we are using the local profile that I just created. Also, in order to use the local parameters to connect to a local database, I'm saying use the profile local. Now, in order to use the local profile, I need to create an application local properties file, which we'll do in a minute. We can also provide a preview URL so that we can just click and it takes us to a running application when the app gets ready. Since our CRUD application is exposed at true.index.html, I'm adding that here as the preview, and I'll save this Maven command. Let's go back to the code. In the resources, we see an application properties file, which is currently pointing to a PostFaceSQL database. But when we are using the local profile and running this application locally within this workspace, we want it to actually connect to the history database. So let's create an application local properties file to be able to do that. I'm adding a new file in the resources. We'll limit as application local properties. And we'll add the data source parameters that point to the H2 database. Now we are ready to start the build process. So let's click on this menu, select our new build and run. The build process would start. The build command is displayed here. This is the command that I just created as well as a route to connect to the application. Once it is ready is also displayed here. Let's go back to the OpenShift web console and check. When the workspace comes up, Core-ready workspaces has automatically created different kinds of routes. One of them is getting connected to port 8080. And this is the one that we are using to connect to our application. The build process would take a couple of minutes. So I'll pause this video and come back when the build is complete. The build is now complete and the application got deployed. As requested, the local profile is being used and the H2 database is being used as it is running in this workspace. Let's click on the route. It points us to our credit application. Let's add a new fruit. The fruit got added. Added to this. It gets changed. So we can see that the application is running locally within the workspace. Let us make a small change to this code. We change this fruit list to fruits list. I'm adding a s here to change it to fruits list. Now the index.html got changed. Let's build and run again. Code is being rebuilt and the code is now deployed. Let's test the application again. Now it shows fruits list instead of fruit list. So our changes are intact. Now that we are happy with the changes, let's say we want to commit these changes to the Git repository where we pull the source code from in the first place. Let's look at the Git options here. If you see the Git remotes, the Git remote is pointing to a H2TP-based URL. At this point of time, we are using a SSH-based access to GitHub. And in order to make that work, I'm going to remove this origin and add the SSH version of the origin again. So let's remove this first. Add a new origin for the same repo. So here is the Git repo. And instead of selecting the H2TP version, we'll select the SSH link to this repo. Come back to the code-ready workspace and add the SSH version. So this way, it will use the SSH key to connect to this Git repo and push the changes there. Close this. Now you can commit. It shows us the list of things that have changed. We have added a local application properties file. We changed the index.html file and we also made some changes to add a local profile to the form.xml file. I'm adding all these changes to the Git repo so that if another developer wants to use the same code, they don't have to recreate these things again. They can use my application local properties and the changes made to the form.xml as well. Now let us commit these changes. The commit is complete. And we'll push the changes to the remote Git repository. The changes are being pushed. Push is complete. It shows that the changes I just made are pushed already. Now let's go back and check the OpenShift project. You can see that build2 has just started. When the launcher created this project and deployed this application on OpenShift, it also created a web hook. So whenever the change is pushed, the build starts automatically on the OpenShift cluster. This build will run for a couple of minutes and once it gets deployed, we'll test the application again. The build is now complete and the application is now getting deployed. The new pod is now ready. Let's test the application. We see that FruitStylist is now available. So in summary, we have imported the code into code-readywork spaces. We learned how to use code-readywork spaces locally. We made some changes yesterday locally. When we were happy with the changes, we committed those changes back to the Git repo and once the changes were committed to the Git repo, they were automatically deployed back on the OpenShift cluster as a real application and we can see the changes are there. I hope you enjoyed this video. Thanks a lot for watching.