Tag: Jenkins X

I recently wrote about how all the cloud platforms are all in Kubernetes and so are developers. It is an exciting time, but the problem for many is that this is a huge blank sheet of paper for how to build and deploy applications. A white space, a void, a limitless canvas of possibilities. Insert metaphors here.

The problem as you may guess is that few people really like or are able to start with a blank canvas. I know I prefer to start with something working and iterate towards a solution, or be given some rails to stay on (again with the metaphors).

Introducing the Jenkins X project – a Kubernetes-native continuous integration and continuous delivery platform for developing cloud native applications that was just introduced as a Jenkins Enhancement Proposal, sponsored by James Strachan.

There is a lot to take in but at it’s heart, this is an open source opinionated way to do continuous delivery with Kubernetes, natively, without necessarily having to learn all the things I talked about in my last blog post. I shall attempt to explain what this is all about and why it matters to developers. As someone said on the jenkins-dev mailing list “We have the two glued together with baling wire and twine” – Jenkins X aims to simplify how to work with continuous delivery and Kubernetes.

First and most importantly, a sneak peek at the logo:

You can see the nautical theme leaking through (and Kubernetes). Whilst it is called Jenkins X, it is about quite a lot more than Jenkins.

Jenkins X makes decisions for you

Jenkins X presents itself to you initially as a handy sleek command line (a native binary you can install called jx – the debate is on as to how pronounce it). Let’s take a tour (sail?):

> jx import my-app

If you have an existing project, this will detect what type of project it is, build a pipeline for you (and a bunch of Kubernetes things, like Helm Charts), add it to your project and set it up in GitHub, WebHooks and all, build the project (run the pipeline) and deploy a version to a “staging” environment.

If it looks ok, you can promote it to production:

> jx promote —env production —version 1.0.1 my-app

If something went wrong in production, you can roll back an app to any version (the version numbers are made for you):

> jx promote —env production —version 1.0.0 my-app

> jx get apps # list versions

An environment is a well-established concept for web developers using continuous delivery: out of the box Jenkins X makes three of them for you (dev, staging and production), but you can make as many as you like. Environments have rules around how things are promoted into them (and they also have their own extensible pipelines, but you can just use them as-is to start).

You can also create a Spring Boot microservice app:

> jx create spring

Answer a few questions and it will set everything up for you.

Any changes you make to your app automatically are built, and if the build looks good, they go through to the staging environment. WebHooks are setup for you (if you are using GitHub) to smooth this over.

For those looking at starting from pre-made apps, there are “quickstarts”:

> jx create quickstart

They are based on a growing set of starter apps, in a variety of languages and tech stacks.

Review apps for your changes: Each pull request is built/tested, and a “review app” is made available in a temporary environment. That means each proposed change, before it goes to the default branch (master), has an environment made (temporary) that it can be tried out in. In GitHub, this shows up as a comment in the pull request:

Project type detection

As you can see, so far there is no editing or manual creation of pipelines, or scripting or setup, just importing or creating your app and go. This is powered by Draft “packs” (a handy project that came out of Azure). What you end up with is a Jenkinsfile in your project repository. You may want to edit it one day, or you may be happy with it as is! Jenkins is famous for being un-opinionated in what you do, but Jenkins X has strong opinions (but you can extend and customise).

Deploying or promoting to environments

Deploying happens via pipelines behind the scenes – when a change is pushed, or a version promoted. You don’t need to directly interact with Kubernetes if you don’t need to. A tool called Helm does the heavy lifting: Helm is used to package and perform installations and upgrade for your apps.

Nautical theme intensifies

There is a little more magic going on here with environments, which you don’t see at first. Each environment, for a team, is represented by a Git repository behind the scenes. Configuration as code is a well-established best practice these days, so why not use it to track deployments and initiate deployments. I also mentioned in my previous post how declarative Kubernetes is: it is perfect for keeping all config in a repository, of the desired system state.

Each promotion is actually a pull request to a per-environment repository. This repository is made and managed for you (and kept outside of the main application code repository), you don’t have to look at it, but you can extend things there should you need to. Specific environment repositories may have different access rules, or be controlled by a different team (perhaps even deploy to a different cluster). Some have coined the term for this as “GitOps.” I first came across this concept on a WeaveWorks blog.

I’ll try and explain this one with a diagram:

 

The pipeline is actually split in the middle. On the left is the more familiar continuous integration pipeline. This works on pull requests, pre-release version of things and is all about testing (automated and manual review). The source of truth for this is the configuration in the applications repository: branches, pull requests and so on.

The right-hand side is the continuous delivery pipeline. This kicks in when the application is ready to be updated with a new release. This is the “GitOps” repo behind the scenes that controls the state of things in Kubernetes. A promotion on this side is a pull request, and then a merge, from the staging repository to the production repository.

Installing Jenkins X

The jx command line has a jx install command that installs it into a Kubernetes cluster.

The best experience initially is using Google’s excellent GKE service:

> jx create cluster gke

This will ask a few questions, and go and set it all up for you in a cluster set aside for Jenkins X (recommended). Jenkins X runs entirely as services on top of a Kubernetes cluster.

> jx install

Is designed to work with a Kubernetes cluster (if it already exists, recommendation is to have a cluster put aside for Jenkins X if possible). Amazon EKS support is coming (mostly it is around testing), that service is in beta/early access so it is still a work in progress, as is Microsoft Azures excellent AKS service.

So where is Jenkins?

Good question, thanks for asking. Well, it is behind the scenes. As you have seen, there was no direct interaction with Jenkins, but it is there, running the pipelines for continuous integration and continuous delivery of the respective repositories, and orchestrating things with Kubernetes.

If you run jx get pipelines you can see URLs to the various pipelines that have been setup for you are part of interacting with Jenkins X.

By the way, James Strachan has written an extensive blog on jenkins.io that really explores the Jenkins X project in-depth. Once you finish reading this blog, take a stroll on over there and read James’. He also provides several ways you can get involved in the project.

What else can I do with the command line?

Lots, the jx command line has built in help:

jx open

– open apps, services or pipelines in your browser

jx activity

– explains how things got to where they are, a history

jx help

jx get environments

– list environments

jx get apps

– show the state of applications, what versions are in what environments.

What’s next with Jenkins X

There is a whole lot more to this, and lots more moving parts and services that are set up for you that are very useful, but it is best to head over to jenkins-x.io and have a look.

This project is obviously in early stages (it is a JEP after all) and there is lots happening. Check out the Jenkins X community if you want to chat on slack, IRC, issues or email. Read the Jenkins Enhancement Proposal doc.

CloudBees recently joined the Cloud Native Computing Foundation, which includes a lot of important cloud native tech, including (but not only) Kubernetes. It will be interesting to see communities grow around continuous integration, continuous delivery and Kubernetes.

 

Michael Neale is a development manager at CloudBees. Michael is an open source polyglot developer. For his sins, he spent time at JBoss, working on the Drools project and then Red Hat, where he continually caused trouble on various projects. Post-Red Hat, Michael was one of the co-founders of CloudBees, seeing great opportunity in cloud technologies. His interest in the cloud is natural, as he is attracted to disruptive technologies. Michael lives and works in the Blue Mountains, just outside Sydney, Australia. He has no hobbies, as his hobbies tend to turn into work anyway. Mic’s motto: “Find something you love doing, and then you will never work a day in your life again.” Follow Michael on Twitter.

Jenkins X is an open source project that offers automated CI/CD for cloud native applications on Kubernetes. Now over a year old and under the auspices of the Continuous Delivery Foundation, the emerging interest and growing implementations of Jenkins X has developers learning more about this technology and what it can do for them.

Using Jenkins X provides developers with a number of benefits including faster software delivery releases, simplicity of installation and configuration and enhances the business sustainability over time.

In this blog post, I’ll answer some of the most common questions about Jenkins X and why it’s important to you.

What is Jenkins X?

So what is Jenkins X? James Strachan, distinguished engineer at CloudBees and chief architect of Jenkins X, defines Jenkins X as an “open source opinionated way to do continuous delivery with Kubernetes, natively,” without worrying too much about the underlying infrastructure. Jenkins X supports all major cloud platforms including Amazon, Azure, Google, IBM Cloud, OpenShift and Pivotal. It is a sub-project of Jenkins and uses automation, tooling and DevOps best practices to increase development speed and improve CI/CD.

With Jenkins X, Kubernetes can be leveraged without spending too much time and effort configuring the complex ecosystem. It reduces the complexities and provides a guided approach with the right selection of tools, all within a system that is easy to use and learn. Jenkins X ensures that when a project is started, it’s not necessary to spend a lot of time creating the structure and gathering the required files. If you need a Kubernetes cluster, all the tools can automatically be in working condition without worrying about installation and configuration. In fact, a single jx command in Jenkins X can create CD pipelines, Git repositories and set webhooks. The list of what Jenkins X does is vast, and grows daily.

What is the difference between Jenkins and Jenkins X?

Unlike Jenkins, Jenkins X is opinionated and built to work better with technologies like Docker or Kubernetes. Having said that, Jenkins and Jenkins X are deeply related as everything that is done with Jenkins X can be done with Jenkins, using several plugins and integrations. However, Jenkins X simplifies everything, letting you harness the power of Jenkins 2.0 and using open source tools like Helm, Draft, Monocular, ChartMuseum, Nexus and Docker Registry to easily build cloud native applications.

In fact, it’s this selection of tools and processes that make Jenkins X special and different from Jenkins and any other CI/CD solution. For instance, Jenkins X defines the process, while Jenkins adapts to whichever process are wanted or needed. Jenkins X adopts a CLI/API first approach, relies on configuration as code and embraces external tools (e.g., Helm, Monocular, etc). On the other hand, Jenkins has a UI first approach with configuration via UI, and everything heavily driven by internal plugins. Additionally, the Jenkins X Preview environments enable developers to collaboratively validate changes integrated into the codebase by creating a running system per Pull Request.

Why was Jenkins X started?

Software development processes have completely transformed over the last few years and continue to evolve. With DevOps, developers’ responsibility for application and configuration management has significantly increased. While DevOps aims to improve the speed of development and reduce the risk of downtime, the transition from developer to the operational role hasn’t been very smooth for developers. Nonetheless, DevOps is gaining higher acceptance and adoption. At the same time, significant changes have taken the industry by storm.

Microservices architecture: While the cloud with its several deployment models (public, private and hybrid) gained adoption across all industries, the challenge of deploying, managing and updating applications remained unresolved. This enabled a way forward for a microservices architecture. Unlike the monolithic apps, apps built on microservices can be deployed on smaller, independently deployable and scalable hosts. After taking a cue from the likes of Amazon, eBay, PayPal and Netflix, today most organizations are moving applications from the monolithic to the microservices architecture.

Container ecosystem: Containers, which offer OS virtualization, gained popularity as they solve some of the problems associated with microservices. Today, different containers on the same host can deploy microservices built on different technologies and frameworks. This allows developers to use whatever language they are comfortable with and package the dependencies within the container itself. Containers are also more efficient than virtual machines (VMs), which virtualize only the hardware. Docker, which helped lead the container movement, has a huge repository of preconfigured Docker images in its Dockerhub public repository, which open-source communities use in abundance. These and many other advantages have made containers a default choice for deployment of code on the cloud.

The rise of Kubernetes: While containers make things simpler, they are not free from challenges. In fact, they are similar to VMs when it comes to managing or orchestrating them. It is challenging for any organization to make sure that machines are not under or over provisioned and every dollar spent for memory, CPU, or storage is well accounted for. There was a need for a solution which allowed efficient and optimal operations with an ability to move containers around, automatically if possible. Google found this exact solution a long time ago and later introduced it in the form of Kubernetes. The open source solution simplifies installation, upgrades and orchestration of containers. Though other cloud vendors also offer their own solutions to orchestrate containers, Kubernetes is vendor-agnostic and offers a common platform for handling containers across all types of clouds and even an in-house infrastructure.

Nonetheless, with all these changes, today developers have a lot of options within a fragmented open source ecosystem with numerous tools for CI/CD. Every tool is purpose-built to solve a part of the problem, but it’s not easy to choose the right ones. It can take years for an organization to gain a good enough understanding of CI/CD and develop an efficient setup. Developers often have to spend more time fine-tuning their CI/CD setup than work on real development. There’s also not a straightforward way to manage Kubernetes clusters and people are wary of the lack of effective monitoring for Kubernetes in production environments.

Though Jenkins can help developers make the most of their CI/CD setup with Kubernetes, it is not easy to select the right combination of plugins and configuration which can all work in tandem with the code. Very few teams agree on what’s the best way to do CD on Kubernetes and many haven’t ever set up a Jenkins Pipeline.

These challenges led the community to think about a solution which can leverage Jenkins to automate CI/CD in the cloud for those who haven’t used Kubernetes before or even those who are using Kubernetes but are struggling with CI/CD. The thought eventually took the form of the Jenkins X project.

What are the main features of Jenkins X?

Jenkins X is built for developers and is designed to help ship code faster, following the best practices in DevOps. That’s why it offers preview environments, simplifies cluster creation with DevEx and can run on different cloud providers’ clusters. One of the biggest advantages of using Jenkins X is that knowledge of Kubernetes internals isn’t necessary and developers can start leveraging the ecosystem right away. However, if it’s necessary to change the setup to fit specific environments or workflows tweaks can be made to the underlying Dockerfile, Jenkins X pipeline, Jenkinsfile or Helm charts as everything is versioned in Git. Let’s examine some of the most talked about features of Jenkins X:

Automated CI and CD: Jenkins X offers a sleek jx command line tool, which allows Jenkins X to be installed inside an existing or new Kubernetes cluster, import projects and bootstrap new applications. Also, Jenkins X creates pipelines for the project automatically.

Environment Promotion via GitOps: Jenkins X allows for the creation of different virtual environments for development, staging, and production, etc. using the Kubernetes Namespaces. Every environment gets its specific configuration, list of versioned applications and configurations stored in the Git repository. The promotion of new versions of applications between these environments is done automatically following GitOps practices. Moreover, code can be promoted from one environment to another manually and change or configure new environments as needed.

Preview Environments: Though the preview environment can be created manually, Jenkins X automatically creates Preview Environments for each pull request. This provides a chance to see the effect of changes before merging them. Further, Jenkins X adds a comment to the Pull Request with a link for the preview for team members.

You can learn more about all Jenkins X features here.

What are the top 5 advantages of Jenkins X?

Easier setup: Jenkins X offers build packs for different kinds of projects, automates the installation, configuration and upgrades of external tools (Helm, Skaffold, Monocular etc.), and helps developers get started quickly with a single line jx command. Moreover, developers have freedom to explore the internal plumbing of Jenkins X whenever deemed fit.

Isolation: Every team gets to run its own instance of Jenkins X; either in a shared cluster or in their own separate clusters. Within a shared cluster, each team can have its own namespace and can effectively share resources while being able to have different pipelines, flows, and configuration as that used by other teams. With separate clusters, the teams get its own set of resources, and won’t be impacted by other teams’ workloads.

Higher velocity: Jenkins X allows unhindered development without shipping logistics slowing things down. Powerful commands expedite most tasks and provide seamless integration with cloud or SCM. For example, a simple ”jx create cluster gke” command installs Jenkins X on Google cloud. AWS (EKS), Azure (AKS), Oracle (OKE) and more can also be used. Furthermore, the application code along with all necessary files for containers, packaging, and pipelines are stored in a common repository and are available out of the box.

Faster recovery: GitOps creates a single source of truth with everything versioned and comments available for every pull request. The configuration as code, of both Jenkins X and your environments, allows developers to get the right context and traceable information to resolve outages faster.

Predictable releases: Jenkins X helps create development/test environments using the “jx create devpod” command to provide each developer their own sandbox inside the Jenkins X cluster. As the devbuild pods are the same as those used in the pipeline used in production, it ensures code will perform in a predictable manner. Further, Jenkins X helps spin up Preview Environments before code is promoted to production. All these features help roll out stable code.

How CloudBees can help developers get started with Jenkins X?

Start off by subscribing to CloudBees Jenkins X Support for initial setup and keeping Jenkins X up-to-date, stable and compliant. CloudBees offers 24×7 technical support for both Jenkins and Jenkins X and is home to the largest group of Jenkins-certified engineers anywhere. You can also watch this video by James Rawling to learn more about Jenkins X.

 

Additional resources

• How to install Jenkins X
• Learn more about Jenkins X
• Read the FAQ on Jenkins X
• Subscribe to the biweekly Jenkins X newsletter

 

Ask your industry colleagues what Jenkins X might be and you may get different answers. Is it a plane, train or automobile? Is it Jenkins++? Is it the beloved Jenkins Butler on steroids?

If you’re a developer, you know Jenkins and now Jenkins X is perhaps one of the most important emerging technologies for building cloud native applications on Kubernetes. Developers who’ve tested and deployed Jenkins X find the benefits of using the technology for their continuous integration (CI) and continuous delivery (CD) infrastructure invaluable.

Matthew Lebrasseur, vice president, information technology for Simplified Telephony Solutions Inc. in Toronto says his experience using Jenkins to build an agile software delivery pipeline will lead to the full deployment of Jenkins X.

Like many leaders who’ve burned their fingers trying different tools for CI/CD, Lebrasseur had struggles with the software development process using a variety of tools such as Spinnaker, Drone and Terraform. Although some of these CI/CD tools were easy to implement and use, they lacked many basic features.

These tools might have worked for a single project, but Lebrasseur said his team had to work on multiple projects, languages and pipelines. The projects weren’t getting anywhere with the barebones functionality these tools offered. All this changed when Lebrasseur decided to bring Jenkins into the picture.

Jenkins was highly impactful in automating the entire software delivery process and expediting deliveries for his organization. Lebrasseur has never been averse to taking risks and choosing the right CI/CD tools for his business is no exception. In fact, it’s part of the company DNA.

“In the technology world, you have to be nimble to adapt quickly to the changing realities and make the most of what technology has to offer. Taking risks is a big part of this exercise,” he said. Lebrasseur’s team grew quickly from just three to 16 engineers and with that staff came the expectation to move and innovate faster and take risks that translate into competitive advantage.

Simplified Telephony Solutions spent just two-days converting all of its pipelines from Jenkins to Jenkins X.

As an example, Lebrasseur said his team took only two weeks to transition from Nomad to Kubernetes and had used the same for three years when Jenkins X became an attractive option.

While Jenkins gives tremendous flexibility to developers in configuring their CI/CD environment with plugins of their choice, the abundance of plugins can overwhelm small teams working under strict deadlines. Jenkins X makes it easier for such teams to leverage the power of Jenkins with several powerful single line commands and a higher degree of automation.

Lebrasseur noted that he’s followed the Jenkins X project from the very beginning, but could only opt for it when it started offering support for BitBucket. As a result, Simplified Telephony Solutions spent just two-days converting all of its pipelines from Jenkins to Jenkins X.

“We converted clusters…just abandoned ship on everything else and just streamlined our pipelines for every project,” Lebrasseur said. “Everything’s the same.”

While the most significant advantage with Jenkins X had been the ease of usage and its ability to automatically create CI/CD pipelines for all kinds of languages and projects, one can’t forget GitOps. Labrasseur pointed out GitOps and the “ability to recover an entire cluster” within seconds with full history and traceability using a simple rollback.

Jenkins X had Lebrasseur at GitOps.

Additional resources

• Download an ebook on how to get started with Jenkins X
• Read a quick overview of Jenkins X and its benefits
• Listen to a podcast featuring the team behind Jenkins X

 

Motivation

First, we articulated the business value that Jenkins X in automating Continuous Everything for Kubernetes. We encourage you to read it first.

If you recall, Jenkins X as an automated CI/CD solution for cloud applications on Kubernetes. Jenkins X automates the installation, configuration, and upgrades of tools, so that users can learn at their own pace. This vastly simplifies the user experience, since users don’t have to stomach all the various pieces on Day One, and can learn at their own pace.

With the built-in automation, teams can focus on releasing quality and secure software frequently and predictably to customers, without worrying about the shipping logistics. At CloudBees, we think it will be easier for our users if we tease things apart even before you start wondering what’s under the hood. This blog provides a quick overview on some of those “undercover agents,” including Jenkins itself, so that you can seamlessly continue on your journey in the continuous paradigm!

Jx

Jenkins X introduces the jx command line – a single command to rule them all.

You can either:

• Install the “jx” binary on your local machine, or
• Use the Google Cloud shell. The shell comes with most of the tools that you will need like Git, gcloud, kubectl, etc.

Some examples of using jx are:

• “jx create cluster gke “ creates a new Kubernetes cluster on Google Cloud
• “jx create quickstart” creates a new app and imports the generated code into Git and Jenkins for CI/CD
• “jx open jenkins” opens Jenkins in a browser
• “jx sync” synchronises your local files to a devpod
• “jx cloudbees” opens the CloudBees CD for Kubernetes app in a browser
• etc.

You can type “jx help” to find the various operations you can perform in Jenkins X.

Helm

Find details here.

Helm charts:

• Manage Kubernetes applications in a predictable and repeatable fashion, which means, they:
  • Define the app
  • Install the app
  • Upgrade the app
• Are versioned in source control, and hence can be audited
• Are easy to create and publish, and hence reduce communication overhead
• Make rollbacks to the last known good version stress-free (and drama-free)

In our modest example, Jenkins X creates the following Helm chart asset(s) in Git:

• https://github.com/junibutler/gojenx/tree/master/charts/gojenx

ChartMuseum

Find details here.

Let’s understand the basics of a chart repository first.

A chart repository is:

• An HTTP server that houses an index.yaml file and optionally some packaged charts
• A location where packaged charts can be stored and shared

ChartMuseum:

• Is an open-source Helm chart repository written in Go
• Is Compatible with cloud storage backends like
  • Google Cloud Storage
  • Amazon S3
  • Microsoft Azure Blob Storage
  • Alibaba Cloud OSS Storage
  • Openstack Object Storage
• Generates the repository index (index.yaml) based on packages found in storage
  • You are no longer required to maintain your own version of index.yaml
  • If you store your own version of index.yaml, it will be completely ignored
• Provides a CLI for
  • Installation
  • Configuration
  • etc.
• Provides an API for:
  • Uploading a new chart version
  • Deleting a chart version
  • Uploading a new chart package to storage
  • Listing all the charts
  • etc.

Skaffold

Find details here.

Skaffold is a command line tool that:

• Facilitates CD for Kubernetes applications
• You can iterate on your application source code locally then deploy to local or remote Kubernetes clusters
• Handles the workflow for building, pushing and deploying your application, and leverages that workflow in an automated pipeline to promote applications from test to staging to production.

Jenkins X creates the following build and deploy workflow yaml using Skaffold:

• https://github.com/junibutler/gojenx/blob/master/skaffold.yaml

Jenkins

Find details here.

Jenkins is an open source automation tool that:

• Is a self-contained Java-based program that can be used as a simple CI server or turned into a continuous delivery hub
• Has a plugin ecosystem to support building, testing, and deploying any project
• Requires Jenkinsfile that supports pipeline-as-code syntax/DSL in two formats:
  • Declarative syntax (recommended)
  • Scripted syntax

Jenkins X creates the following pipeline to promote through various stages:

• https://github.com/junibutler/gojenx/blob/master/Jenkinsfile

Docker

Find details here.

Docker:

• Standardizes and automates the way we build, manage, and secure applications using containers
• Creates true independence between applications and infrastructure
• Creates a model for better collaboration and innovation between developers, QA, release, operations and security professionals

Jenkins X creates the following image for the containerized application:

• https://github.com/junibutler/gojenx/blob/master/Dockerfile

Kubernetes

Find details here.

Kubernetes runs production workloads at Google, which translates to running billions of containers per week

Among many other things, Kubernetes:

• Automates deployment, scaling, and management of containerized apps
• Groups containers that make up an application into logical units for easy management and discovery
• Gives you freedom to take advantage of on-premise, hybrid, or public cloud infrastructure, letting you effortlessly migrate workloads
• Restarts containers that fail
• Replaces and reschedules containers when nodes die
• Kills containers that don’t respond to health checks
• Scales your application up and down:
  • Automatically based on CPU usage or
  • Manually with a command or a UI

Ksync

Find details here.

Ksync:

• Syncs files between our local file system and a Kubernetes cluster.
• Transparently updates containers running on the cluster from your local checkout.
• Enables developers to use their favorite IDEs to work from inside a cluster instead of from outside it. There is no reason to wait minutes to test code changes when you can see the results in seconds.

“jx sync” within Jenkins X allows us to sync files between our local lie system to the devpods on the Kubernetes cluster. This prevents typical problems like “works on my machine!” from slowing down business, even when everyone knows there are problems in production.

Prow

Find details here.

Prow is the system that handles GitHub events and commands for Kubernetes. It hails from the Kubernetes ecosystem and was created at Google. It is an event based solution that provides a loosely coupled architecture ideal for the cloud native world. It leverages ChatOps to interact with a build system. Prow manages its job configuration in Git. So, in the event of a wipeout, pipelines can be restored.

Prow includes a scalable and highly available webhook event handler that writes ProwJob CRDs to Kubernetes based on git events, so that other microservices can perform operations like running CI/CD pipelines. These git events can be triggered by new PRs and issues, comments, merges and pushes.

Jenkins X includes Prow out of the box when creating clusters on GKE (Google Kubernetes Engine) with Terraform using “jx create terraform” or when using the feature flag on “jx create cluster gke —prow” or “jx install —prow” commands. Prow, along with Knative build, makes serverless Jenkins possible that addresses problems originating from static Jenkins masters.

Knative Build

Find details here.

Knative Build is a cloud native solution that extends Kubernetes with CRDs and provides ways to build applications from source. Teams can chain steps that run sequentially in the same Kubernetes pod using different containers where they can share state between each step.

Build templates are Kubernetes CRDs and are automatically upgraded with each Jenkins X release. The Prow configuration that is generated by Jenkins X when creating or importing applications refers to a build template. Knative build, along with Prow, makes serverless Jenkins possible that addresses problems originating from static Jenkins masters.

Teams can leverage build templates to reference the type of Kubernetes pod that is created to run builds. These templates allow teams to specify which docker image to execute your build in, what environment variables exist at build time, what service accounts and secrets are in play and what volumes should be mounted.

Cloud

For those of us who have tinkered with Kubernetes, we know it is difficult to setup and manage. Jenkins X alleviates that pain and leverages the managed Kubernetes solutions offered by major cloud providers, like:

• Google Cloud (GKE)
• Amazon Web Services (EKS)
• Microsoft Azure (AKS)
• Oracle Cloud (OKE)
• etc.

Let’s take the example of Google cloud. The Google cloud sdk provides the command-line interface for Google Cloud Platform products and services, like:

• Gcloud, which manages authentications, local configurations, developer workflow, and interactions
• Kubectl, which orchestrates the deployment and management of Kubernetes container clusters on gcloud
• etc.

Summary

Jenkins X automates CI/CD for cloud applications on Kubernetes. So that engineers can focus on writing and testing products that wow the world, Jenkins X abstracts away a lot of the shipping logistics that would otherwise consume your time and energy.

Jenkins X gets you started at the speed of light, however, the onus lies on you to gradually and eventually catch up to these underlying details. While we are sure you are well on your way to design and implement resilient pipelines, we wanted to make sure you have these details at your fingertips.

Pipeline is no longer a pipe dream – so, happy coding!

Additional resources

• Tune in to the latest DevOps Radio podcast about Jenkins X
• Listen to the webinar Serverless Jenkins with Jenkins X
• Download the free eBook about building cloud native applications