Creating a Remote Development Environment
This lesson covers the steps for creating a devpod and configuring it for our application.
We'll cover the following
- Browse to go-demo-6 directory
- Creating a DevPod
- Exploring the new development environment
- Confirming the installations
- Compiling the binary
- Inspecting skaffold.yaml
- Explanation of skaffold.yaml
- The build section
- The deploy section
- The DIGEST_HEX variable
- The deploy section of the dev profile
- The DOCKER_REGISTRY variable
- Checking the env variables
- Initializing the Helm client
- Generating UUID and running skaffold using the dev profile
- Inspecting the output
- Confirming the installation of application
- Inspecting watch.sh
- Exiting the DevPod
- Running the application
Let’s say that we want to change the go-demo-6 code.
Once we finish making changes to the code, we’ll need to compile it and test it, and that might require additional installations and configurations. Once our code is compiled, we’ll need to run the application to confirm that it behaves as expected.
- For that, we need Docker to build a container image, and we need a Helm to deploy it.
- We’d also need to create a personal Namespace in our cluster, or create a local one.
- Given that we adopted Skaffold as a tool that builds images and deploys them, we’d need to install that as well. But that’s not the end of our troubles.
- Before we deploy our application, we’ll need to push the new container image and the Helm chart, to the registries running inside our cluster. To do that, we need to know their addresses, and we need credentials with sufficient permissions.
Even when we do all that, we need a repeatable process that will build, test, release, and deploy our work whenever we make a significant change. Better yet, whenever we make any change.
📝 Here’s the task for you.
Change anything in the code, compile it, build an image, release it together with the Helm chart, deploy it inside the cluster, and confirm that the result is what you expect it to be. I urge you to stop reading and do all those things.Come back when you’re done.
How much did it take you to get a new feature up-and-running? Chances are that you failed. Maybe you used Jenkins X and the knowledge from the previous chapters to do all that. If that’s the case, was it efficient? I bet it took more than a few minutes to set up the whole environment. Now, make another change to the code and don’t touch anything else. Did your change compile? Were your tests executed? Was your change rolled out? Did that take more than a few seconds?
If you were not successful, we’ll explore how to make you succeed the next time. If you didn’t, we’ll explore how to make the processes much easier, more efficient, and faster. We’ll use Jenkins X, but not in the way you expect.
Get hands-on with 1400+ tech skills courses.