 Hello everyone, in this demo, I will show how Red Hat OpenShift Dev Spaces can be used to build, package, and deploy and test your application all in our workspace. The project that we will be working on for today's demo is this Quarkus project. In this Quarkus project, we manage these food resources and we have some endpoints for managing them. And these food resources are being stored inside of a PostgreSQL database that this project depends on. I'm going to copy the URL of this GitHub project, copy and paste the URL into the OpenShift Dev Spaces dashboard to create the workspace. You can also create the workspace with the factory URL as well. So while we wait until the workspace starts up, I'm going to go to the pod section of the OpenShift console and we can see our workspace pod is starting up. Further examining the pod, we can see the inner containers and the containers that we also defined in our dev file, which are the containers we need for development. Going into the previous tab, the workspace is running and we can see that we have VS Code as our editor. On the left-hand side, we have our project already cloned. First, I will build the application. So to do that, I will run a task. So I started the command palette with VS Code and I'm going to run the Jpackage task. These tasks are already predefined in the dev file of the project. You can see here in the terminal output that we're downloading the Maven artifacts. It's also possible to set up your workspace so that the Maven artifacts are being stored inside a persistent volume so that the next time we shut down our workspace and start up the same workspace again, the persistent volume can be mounted to the workspace and at that point, we won't need to download these artifacts again. So essentially, if you can have persistent volume set up for this, meaning that this would be the only time you would download these specific dependencies for this workspace. You can also create a PVC that is auto-mounted to every workspace where the persistent volume contains the M2 directory. In other words, you can have the M2 directory be persistent and shared across multiple workspaces. The Maven package command has been completed. Next, let's build the container image for our application. This application we have a Dockerfile provided and also a task to build the image as well. So we will run the build image task and this is essentially a podman build with the Dockerfile specified. Opening up the command palette once more, I will run the build image task. The image has been built. So the next step here would be to push our image. So let's push the image to the local OpenShift registry. First, I will log into the registry. So I have another task for that. This will be the login to local OpenShift registry task. Login succeeded. And let's push our image as well using the push image task. The image has been pushed. So next, let's deploy our application onto the cluster that the workspace is running in. So out of the box, when starting a new terminal inside one of the development containers, out of the box, we have the kube config already set up. So if I, in the terminal, run a command such as oc get pods, this will show all of the pods running in my username space. You can verify that by going into the OpenShift console. It's only the workspace pods that's running and that's the exact same output that we see with oc get pods as well. So from here, you can also do other commands such as, of course, oc and apply a template. There's a template I would like to apply. And I'm going to use this template to deploy our application within the same workspace that our workspace is running in. So I will call oc apply. This creates the deployment for the corpus application, deployment for the PostgreSQL database and the associated services as well. So after that, you can do oc get pods once more. And verify that our application has been deployed along with the PostgreSQL database. So from here, I can just test my application by running curl and I will curl the service. So I will call the food endpoint. So this gives me all of our food resources that are already inside of the PostgreSQL database. And we can verify that we do get a list of food items right here with the 200 response code. So that was the demo. This example showed how to build, package, deploy and test the application from within the workspace. And of course, you can maybe make some changes to the code as well and rebuild the application, push the image once more and do something like oc rollout. Start, deploy and the deployment name to see the new changes as well. That was the demo. Thank you for watching.