Jenkins: X or 2.0 ?
Jenkins: X or 2.0 ?
Dig deeper into some of the features from the recently announced Jenkins X, including whether it's an iteration or something brand new.
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
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.
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!
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.
Opinions expressed by DZone contributors are their own.