Creating a Remote Development Environment

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.