Jenkins: X or 2.0 ?

Jenkins X has become one of the most noticed recent open source announcements.

In this article, I discuss appealing features of the new product which have not been specifically mentioned in documentation.

I recommend reading about the motivation and features if you need a product guide or specs of any kind.

Is It Just a New Hype Tool? What Is so Special About Running Jenkins in Containers?

Kubernetes is the de facto standard for managing containers, distributed applications, and virtual infrastructure. It's offered as a managed service by major public cloud providers and can be installed on-premises. If you build a cloud app today and want it to be portable anywhere, Kubernetes is your choice!

While the ecosystem is huge, it's still very young and is more focused on dealing with "Day 1" challenges, like K8s rollout. It's natural to solve the most pressing issues first. 2018 is predicted to bring more stabilization, integration, and user experience aspects. Today, we think about how to operate on Day 2, how to build something on top, and make developers more productive.

Jenkins X is filling the gap with holistic CI/CD management here.

Is It Just a Rebranding of Jenkins 2.0?  

Jenkins is a tool which was developed long before cloud become the norm and it's definitely not a cloud-native tool, meaning it doesn't have OOTB capability to survive outages, seamless scaling, etc.

Luckily for us, it is extensible. Jenkins X does its magic with Kubernetes plugin, allowing you to forget about provisioning virtual machines or physical servers for slaves; each job uses disposable agents, running in separate containers, which can scale with your cluster. 

With Jenkins X, you get not only K8S pipelines for your apps, but also a very scalable CI/CD solution.

Can You Install Jenkins for Our Team?

This is the most frequent question from development teams when Kubernetes is presented as a project platform of choice. Migrating major tools means lots of changes for any organization; literally, it affects all major DevOps processes and requires significant learning effort.

Jenkins X is shipped with K8s pipelines, agents, and integrations make migrations to Kubernetes and microservices a way simpler.  

What about Version Control?

Jenkins X is built with GitOps concept in mind. 

Keeping all configurations in version control means better security, DR, and the possibility to apply all SDLC practices to operations tasks.  

Out of the box, you get CI/CD infrastructure configuration saved into Git and your toolkit is continuously follows that principle.

You never get a chance to break this rule due to some urgency and this is by design! 

Building Blocks

Jenkins2.0 - "good old" CI server

Helm- package manager

Draft- dev environment build tool

Monocular- UI for helm repositories

Chartmuseum- helm repository with cloud backends support

Nexus- artifacts repository

Docker registry- container image registry

All of the above are under control of a jx tool and configuration is shipped as a "platform", set of helm charts.

A Fresh Look at Environments Management

One of the most interesting as for me!

The environment as an entity is controlled by the tool, you can manage lifecycle, promote and configure! You can easily customize, template and reuse it.

GitOps pattern is used and you have one repository for each environment. This is best practice and is driven OOTB by jx.

Helm is used for configuration management. The environment is represented as a helm package and each application is being added as a dependency, while promoted. This approach makes a lot of sense since environment configuration is the least standardized area. Many teams spent lots of time until I came to something similar. You'll get it for free!

Swiss Army Knife CLI

Jx CLI is an entry point to all functionality of the framework.

The most important: it's a key construct, which is widely invoked in CD pipelines. They can be easily played with and debugged directly, any step can be replayed or repeated from CLI.