Oops! Something went wrong while submitting the form.
We use cookies to improve your browsing experience on our website, to show you personalised content and to analize our website traffic. By browsing our website, you consent to our use of cookies. Read privacy policy.
Jenkins X is a project which rethinks how developers should interact with CI/CD in the cloud with a focus on making development teams productive through automation, tooling and DevOps best practices.
The difference between Jenkins X and Jenkins
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 out of the box capability to survive outages, seamless scaling, etc.
Basically, Jenkins X is not just a CI/CD tool to run builds and deployments, it automates the whole development process end to end for containerised applications based on Docker and Kubernetes.
With Jenkins X, you get not only Kubernetes pipelines for your apps but also a very scalable CI/CD solution.
Challenges while setting up CI/CD pipelines for container-based applications:
Setup the cloud environment
Setup kubernetes cluster and set up multiple environments like development, staging, testing
Migrate application to the container so that user can start building docker images
Figure out how to deploy the application on Kubernetes and generate some yml and helm charts
Figure out how to do continuous delivery including promotion processes - eg Promote versions of the application from testing to staging to production.
Store all operational configurations like web application source code on the GitHub repository.
Then automate everything
So all this stuff which developers have to do is kind of unnecessary heavy lifting. Jenkins X is designed to get the above stuff done and focus on delivering actual value to customers.
How does Jenkins X help?
Automate the installation, configuration & upgrade of Jenkins + other s/w components (helm, nexus etc) on Kubernetes
Automate CI/CD for your applications on Kubernetes
Docker images
Helm charts
Pipelines
Uses GitOps to manage promotions between environments
Test - Staging - Promotion
Lots of feedback. Eg. commenting on issues as they hit Staging + Production
What does Jenkins X do?
By using Jenkins X, the developer can type one command jx create or jx import and the following process : get the source code, the git repository and application created, automatically built and deployed to Kubernetes on each Pull Request or git push with full CI/CD complete with Environments and Promotion.
Developers and teams don’t have to spend time figuring out how to package software as docker images, create the Kubernetes YAML to run their application on kubernetes, create Preview environments or even learn how to implement CI/CD pipelines with declarative pipeline-as-code Jenkinsfiles. It’s all automated in Jenkins X.
If you want to see Dockerfile, Jenkinsfile or Helm charts for your apps or their environments then those are all available versioned in Git with the rest of your source code with full CI/CD on it all.
Jenkins X conceptual model
Automated CI/CD Pipelines
Create new projects or import existing source code quickly into Jenkins X via the jx command line tool and:
Get a Pipeline automatically set up for you that implements best practice CI/CD features:
Creates a Jenkinsfile for defining the CI/CD pipelines through declarative pipeline-as-code
Creates a Docker file for packaging the application up as an immutable container image (for applications which generate images)
Creates a Helm chart for deploying and running your application on Kubernetes
Ensures your code is in a git repository (e.g. GitHub) with the necessary webhooks to trigger the Jenkins CI/CD pipelines on push events
Triggers the first release pipeline to promote your application to your teams Staging Environment
On each Pull Request, a CI pipeline is triggered to build your application and run all the tests ensuring you keep the master branch in a ready to release state. When a Pull Request is merged to the master branch the Release pipeline is triggered to create a new release:
A new semantic version number is generated
The source code is modified for the new version and then tagged in Git
New versioned artifacts are published including docker image, helm chart, and any language-specific artifacts
Jenkins X functionality
JX is a command line tool for installing and using Jenkins X. Check out how to install jx. To create a new Kubernetes cluster with Jenkins X installed use the jx create cluster command. The command initialises Pods with the following applications in jx namespace of Kubernetes:
Chartmuseum (Open-source Helm Chart repository)
Docker registry (Docker image storage)
Jenkins (Automation server)
MongoDB (NoSQL Database)
Nexus repository (Artifact storage)
Let’s have a look at how the JX processes correlate to Git actions. For simplicity, let’s use only master and one feature branch. The table below details the steps of the flow.
Prerequisites for setting up Kubernetes + Jenkins X using GKE
Note: Following steps are for Ubuntu 16.04
Install Git and set your account’s default identity using Git config
After triggering this command, we are prompted to authenticate Google Cloud account. It also prompts for some questions on how to create our cluster. It generates a random admin password which is used to access all the applications that we’ve installed.
We can now get logs for the build jobs which are actually provisioning the staging environment. Please find detailed logs of the above command displayed below.
It will prompt for some questions like the type of project, mvn group ID, artefact name, spring boot dependencies etc. It initializes this project as a Git repository. It adds some extra files to the repo i.e. Dockerfile, Jenkinsfile, charts etc. This will create a repository in GitHub. Also creates a project in Jenkins and registers webhooks in the Git repository.
The first build takes time because it downloads some dependencies from maven central.
We are using Nexus which was installed as a part of Jenkins X platform so that remaining builds will be faster because dependencies will be cached.
After that it tags our potential release & push tags to Github.It then builds application using maven.
It uploads artefacts to Nexus so that it can be shared between the teams.
Docker image is been built for this application & pushed to docker registry.
It then generates change log and publish it to chartmuseum registry.
Pipeline waits for pull request for staging environment to be merged and then waits for another pipeline to be triggered & perform deployment for our new application on staging environment using helm.
Now we can see staging environment with our application running in it.
10. Now, you can see the application running on the given URL.
So where is Jenkins?
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 repository, 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.
Additional JX Commands:
jx open
open apps, services or pipelines in your browser
jx activity
explains how things got to where they are, a history
jx get environments
list environments
jx get apps
show the state of applications, what versions are in what environments.
Conclusion
So this is how Jenkins X automates installation, configuration of Jenkins and some other software components. It also automates CI/CD for your applications on Kubernetes along with promotions through GitHub.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Jenkins X is a project which rethinks how developers should interact with CI/CD in the cloud with a focus on making development teams productive through automation, tooling and DevOps best practices.
The difference between Jenkins X and Jenkins
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 out of the box capability to survive outages, seamless scaling, etc.
Basically, Jenkins X is not just a CI/CD tool to run builds and deployments, it automates the whole development process end to end for containerised applications based on Docker and Kubernetes.
With Jenkins X, you get not only Kubernetes pipelines for your apps but also a very scalable CI/CD solution.
Challenges while setting up CI/CD pipelines for container-based applications:
Setup the cloud environment
Setup kubernetes cluster and set up multiple environments like development, staging, testing
Migrate application to the container so that user can start building docker images
Figure out how to deploy the application on Kubernetes and generate some yml and helm charts
Figure out how to do continuous delivery including promotion processes - eg Promote versions of the application from testing to staging to production.
Store all operational configurations like web application source code on the GitHub repository.
Then automate everything
So all this stuff which developers have to do is kind of unnecessary heavy lifting. Jenkins X is designed to get the above stuff done and focus on delivering actual value to customers.
How does Jenkins X help?
Automate the installation, configuration & upgrade of Jenkins + other s/w components (helm, nexus etc) on Kubernetes
Automate CI/CD for your applications on Kubernetes
Docker images
Helm charts
Pipelines
Uses GitOps to manage promotions between environments
Test - Staging - Promotion
Lots of feedback. Eg. commenting on issues as they hit Staging + Production
What does Jenkins X do?
By using Jenkins X, the developer can type one command jx create or jx import and the following process : get the source code, the git repository and application created, automatically built and deployed to Kubernetes on each Pull Request or git push with full CI/CD complete with Environments and Promotion.
Developers and teams don’t have to spend time figuring out how to package software as docker images, create the Kubernetes YAML to run their application on kubernetes, create Preview environments or even learn how to implement CI/CD pipelines with declarative pipeline-as-code Jenkinsfiles. It’s all automated in Jenkins X.
If you want to see Dockerfile, Jenkinsfile or Helm charts for your apps or their environments then those are all available versioned in Git with the rest of your source code with full CI/CD on it all.
Jenkins X conceptual model
Automated CI/CD Pipelines
Create new projects or import existing source code quickly into Jenkins X via the jx command line tool and:
Get a Pipeline automatically set up for you that implements best practice CI/CD features:
Creates a Jenkinsfile for defining the CI/CD pipelines through declarative pipeline-as-code
Creates a Docker file for packaging the application up as an immutable container image (for applications which generate images)
Creates a Helm chart for deploying and running your application on Kubernetes
Ensures your code is in a git repository (e.g. GitHub) with the necessary webhooks to trigger the Jenkins CI/CD pipelines on push events
Triggers the first release pipeline to promote your application to your teams Staging Environment
On each Pull Request, a CI pipeline is triggered to build your application and run all the tests ensuring you keep the master branch in a ready to release state. When a Pull Request is merged to the master branch the Release pipeline is triggered to create a new release:
A new semantic version number is generated
The source code is modified for the new version and then tagged in Git
New versioned artifacts are published including docker image, helm chart, and any language-specific artifacts
Jenkins X functionality
JX is a command line tool for installing and using Jenkins X. Check out how to install jx. To create a new Kubernetes cluster with Jenkins X installed use the jx create cluster command. The command initialises Pods with the following applications in jx namespace of Kubernetes:
Chartmuseum (Open-source Helm Chart repository)
Docker registry (Docker image storage)
Jenkins (Automation server)
MongoDB (NoSQL Database)
Nexus repository (Artifact storage)
Let’s have a look at how the JX processes correlate to Git actions. For simplicity, let’s use only master and one feature branch. The table below details the steps of the flow.
Prerequisites for setting up Kubernetes + Jenkins X using GKE
Note: Following steps are for Ubuntu 16.04
Install Git and set your account’s default identity using Git config
After triggering this command, we are prompted to authenticate Google Cloud account. It also prompts for some questions on how to create our cluster. It generates a random admin password which is used to access all the applications that we’ve installed.
We can now get logs for the build jobs which are actually provisioning the staging environment. Please find detailed logs of the above command displayed below.
It will prompt for some questions like the type of project, mvn group ID, artefact name, spring boot dependencies etc. It initializes this project as a Git repository. It adds some extra files to the repo i.e. Dockerfile, Jenkinsfile, charts etc. This will create a repository in GitHub. Also creates a project in Jenkins and registers webhooks in the Git repository.
The first build takes time because it downloads some dependencies from maven central.
We are using Nexus which was installed as a part of Jenkins X platform so that remaining builds will be faster because dependencies will be cached.
After that it tags our potential release & push tags to Github.It then builds application using maven.
It uploads artefacts to Nexus so that it can be shared between the teams.
Docker image is been built for this application & pushed to docker registry.
It then generates change log and publish it to chartmuseum registry.
Pipeline waits for pull request for staging environment to be merged and then waits for another pipeline to be triggered & perform deployment for our new application on staging environment using helm.
Now we can see staging environment with our application running in it.
10. Now, you can see the application running on the given URL.
So where is Jenkins?
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 repository, 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.
Additional JX Commands:
jx open
open apps, services or pipelines in your browser
jx activity
explains how things got to where they are, a history
jx get environments
list environments
jx get apps
show the state of applications, what versions are in what environments.
Conclusion
So this is how Jenkins X automates installation, configuration of Jenkins and some other software components. It also automates CI/CD for your applications on Kubernetes along with promotions through GitHub.
Velotio Technologies is an outsourced software product development partner for top technology startups and enterprises. We partner with companies to design, develop, and scale their products. Our work has been featured on TechCrunch, Product Hunt and more.
We have partnered with our customers to built 90+ transformational products in areas of edge computing, customer data platforms, exascale storage, cloud-native platforms, chatbots, clinical trials, healthcare and investment banking.
Since our founding in 2016, our team has completed more than 90 projects with 220+ employees across the following areas:
Building web/mobile applications
Architecting Cloud infrastructure and Data analytics platforms