Software Development with Jenkins X

Software development is hard. It takes a long time to turn into a proficient developer, and the tech and the procedures change from time to time. What was viable yesterday, isn't really powerful today. The quantity of dialects we code in is expanding. While before, most engineers would work in a similar language all through their entire bearer, today it isn't exceptional for a designer to take a shot at various undertakings written in various dialects. We may, for instance, chip away at another undertaking and code in Go, while despite everything we have to keep up some other venture written in Java. For us to be effective, we have to introduce compilers, aide libraries, and many different things.

Regardless of whether we compose all the code in a solitary language or not, our applications will have various conditions. One may require MySQL, while the other may utilize MongoDB as the data storage. We may likewise rely upon applications developed by different groups working in parallel with us. Regardless of how great we become at composing ridicules and stubs that supplant those conditions, in the long run, we'll require them running and accessible from our laptops.

Historically, we've been tackling those issues by having a common improvement condition, yet that demonstrated to be wasteful. Sharing improvement conditions results is an excessive amount of overhead. We'd have to coordinate changes, and those that we make would regularly break something and cause everybody to endure. Rather, we need every designer to have the choice to have its very own condition where conditions required for an application are running.

For the conditions to be valuable, we should run them in (nearly) a similar way we're running them underway, that implies we ought to convey them to Kubernetes also. For that, we can pick minikube or Docker Desktop in the event that we incline toward a nearby bunch, or get a portion (Namespace) of a remote group.

Unfortunately, compilers and dependencies are not everything we need to develop efficiently. We also need tools. Today that means that we need Docker or kaniko to build container images. We need helm and kubectl to deploy applications to Kubernetes. We need skaffold that combines the process of building images with deployment. There are quite a few other tools specific to a language and a framework that would need to be installed and configured as well.

Even if we do set up all those things, we are still missing more. We need to be able to push and pull artifacts from container registry, ChartMuseum, Nexus, or any other registry that might be in use in our organization.

As you can imagine, installing and configuring all that is not trivial. It is not uncommon for a new hire to spend a week, or even more, on setting up its own development environment. And what happens if that person should move to a different project or if he should work on multiple projects in parallel?

We can continue with business as usual and install all the compilers and the tools on our laptops. We can dedicate time setting them up and connecting them with the system (e.g., with the registries). We can continue giving new hires long Word documents that walk them through all the actions they need to perform to be able to develop our applications. Or, we can take a different approach. We might be able to create a full-blown development environment on demand and for each person. We can even make those environments application-specific. And we might be able to make it so fast and straightforward that anyone can do it with a single command and in only a couple of minutes.

Jenkins X allows us to spin up a project-based private development environment with all the tools, configurations, and environment variables we might need to work on any of our applications. That feature is called DevPod.