Accelerate Application Management Using Jenkins X

Introduction

Technology is ever-evolving, and we have seen a major shift in application platforms from on-premise to cloud and containerization, application architecture from monolithic to micro-service, and many more. Organizations today are working towards making the operations an easy task and reducing the cost, as it is one of the painful areas where the project spends a lot of time and effort to streamline the entire process. Jenkins X is one of the platforms which has such kind of capability.

For an individual who is into technology, the familiarity of the name Jenkins is not uncommon. But "What is Jenkins X?" and once we will know about it, certainly, there will be more questions in our mind, and most of them will be answered in this essential document.

Comparing Container Pipelines

Introduction

Containers brought a monumental shift to DevOps by allowing teams to ship code faster than ever before. However, we still have to go through the process of building, packaging, and deploying those containers. That's why we use container pipelines.

However, there are many different choices when it comes to container pipelines. How do we know which one to use? In this article, we'll compare six choices and cover the configuration, benefits, limitations, and pricing of each.

Jenkins X Step-by-Step Tutorial to Continuous Deployment with Kubernetes

At TestProject we strive to use the most up-to-date best practices, and as part of an upgrade for some components and workflows in our infrastructure, we are partially shifting to Jenkins X. There is a lack of useful material available on Jenkins X serverless setup, so as part of our belief in sharing and giving back to the community we’ve decided to create a full-blown step by step tutorial on about it!

Jenkins X serverless and Kubernetes continuous integration solves the following problems:

Is Your Cluster Ready for Jenkins X?

If you're reading this, chances are that you do not want to use jx cluster create to create a new cluster that will host Jenkins X. That is OK, and even welcome. That likely means that you are already experienced with Kubernetes and that you already have applications running in Kubernetes. That's a sign of maturity and your desire to add Jenkins X to the mix of whichever applications you are already running there. After all, it would be silly to create a new cluster for each set of applications.

However, using an existing Kubernetes cluster is risky. Some people assume that it will be easy to create a cluster from scratch. "We're so awesome that we don't need tools like Rancher to create a cluster for us. We'll do it with kubeadm." Then, after a lot of sweat, we announce that the cluster is operational, only to discover that there is no StorageClass or that networking does not work. So, if you assembled your own cluster and you want to use Jenkins X inside it, you need to ask yourself whether that cluster is set up correctly. Does it have everything we need? Does it comply with standards, or did you tweak it to meet your corporate restrictions? Did you choose to remove StorageClass because all your applications are stateless? Were you forced by your security department to restrict communication between Namespaces? Is the Kubernetes version too old? We can answer those and many other questions by running compliance tests.