Learn how to use Jenkins X to automate your pipeline and achieve CI/CD.

DevOps for Developers

Jenkins X is a powerful tool for providing software developers continuous integration, automated testing, and continuous delivery, known as CI/CD, in Kubernetes.

It’s no secret that Kubernetes is extremely complex, and Jenkins X helps you by simplifying processes into concepts that can be adopted quickly and without spending months trying to figure out “the right way to do stuff.”

In this course, you’ll start by exploring the inner workings of Jenkins X and how to create a cluster using it. You’ll then learn how to combine Jenkins X with tools you’re already using. Throughout, you’ll see how this exciting new tool changes how you work with Kubernetes.

By the time you’re done, you will be confident managing CI/CD using Jenkins X in a Kubernetes cluster.

Jenkins X with Kubernetes

## Checking the pipelines
Let's take a quick look at the pipelines currently active in our cluster.



- vfarcic/environment-jx-boot-dev/master
- vfarcic/environment-jx-boot-production/master
- vfarcic/environment-jx-boot-staging/master



We are already used to working with `production` and `staging` pipelines. What is new is the `dev` pipeline. That is the one we just executed locally. It is now available in the cluster as well, and we should be able to trigger it by pushing a change to the associated repository. Let's test that.
## Triggering the `dev` pipeline
We'll explore the Jenkins X upgrade process later. For now, we just want to see whether the `dev` repository is indeed triggering pipeline activities. We'll do that by making a trivial change to the `README.md` file.



echo "A trivial change" \
    | tee -a README.md

git add .

git commit -m "A trivial change"

git push

jx get activities \
    --filter environment-$CLUSTER_NAME-dev \
    --watch



We pushed the changes to GitHub and started watching the activities of the `dev` pipeline. The output, when the activity is finished, should be as follows.



STEP                                      STARTED AGO DURATION STATUS
vfarcic/environment-jx-boot-dev/master #1       4m10s    3m52s Succeeded 
  release                                       4m10s    3m52s Succeeded 
    Credential Initializer 7jh9t                4m10s       0s Succeeded 
    Working Dir Initializer Tr2wz               4m10s       2s Succeeded 
    Place Tools                                  4m8s       2s Succeeded 
    Git Source Vfarcic Environment Jx...         4m6s      36s Succeeded https://github.com/vfarcic/environment-jx-boot-dev.git
    Git Merge                                   3m30s       1s Succeeded 
    Validate Git                                3m29s       1s Succeeded 
    Verify Preinstall                           3m28s      26s Succeeded 
    Install Jx Crds                              3m2s      10s Succeeded 
    Install Velero                              2m52s      12s Succeeded 
    Install Velero Backups                      2m40s       2s Succeeded 
    Install Nginx Controller                    2m38s      16s Succeeded 
    Create Install Values                       2m22s       0s Succeeded 
    Install External Dns                        2m22s      16s Succeeded 
    Install Cert Manager Crds                    2m6s       0s Succeeded 
    Install Cert Manager                         2m6s      16s Succeeded 
    Install Acme Issuer And Certificate         1m50s       2s Succeeded 
    Install Vault                               1m48s       8s Succeeded 
    Create Helm Values                          1m40s       3s Succeeded 
    Install Jenkins X                           1m37s     1m3s Succeeded 
    Verify Jenkins X Environment                  34s       5s Succeeded 
    Install Repositories                          29s       5s Succeeded 
    Install Pipelines                             24s       1s Succeeded 
    Update Webhooks                               23s       4s Succeeded 
    Verify Installation                           19s       1s Succeeded 




That's the first activity (`#1`) of the `dev` pipeline. To be more precise, it is the second one (the first was executed locally) but, from the perspective of Jenkins X inside the cluster, which did not exist at the time, that is the first activity. Those are the steps of Jenkins X Boot running inside our cluster.

We won't go through the changes that were created by that activity since there are none. We did not modify any of the files that matter. We already used those same files when we executed Jenkins X Boot locally. All we did was push the change of the `README` file from the local repository to GitHub. That triggered a webhook that notified the cluster that there are some changes to the remote repo. As a result, the first in-cluster activity was executed.

The reason I showed you that activity wasn't due to an expectation of seeing some change applied to the cluster, there were none, but to demonstrate that, from now on, we should let Jenkins X running inside our Kubernetes cluster handle changes to the `dev` repository, instead of running `jx boot` locally. That will come in handy later on when we explore how to upgrade or change our Jenkins X setup.

Please press *ctrl+c* to stop watching the activity.
## Checking the Namespaces present in the cluster
Let's take a look at the Namespaces we have in our cluster.



# Checking the pipelines
Let's take a quick look at the pipelines currently active in our cluster.





We are already used to working with `production` and `staging` pipelines. What is new is the `dev` pipeline. That is the one we just executed locally. It is now available in the cluster as well, and we should be able to trigger it by pushing a change to the associated repository. Let's test that.
# Triggering the `dev` pipeline
We'll explore the Jenkins X upgrade process later. For now, we just want to see whether the `dev` repository is indeed triggering pipeline activities. We'll do that by making a trivial change to the `README.md` file.





That's the first activity (`#1`) of the `dev` pipeline. To be more precise, it is the second one (the first was executed locally) but, from the perspective of Jenkins X inside the cluster, which did not exist at the time, that is the first activity. Those are the steps of Jenkins X Boot running inside our cluster.

We won't go through the changes that were created by that activity since there are none. We did not modify any of the files that matter. We already used those same files when we executed Jenkins X Boot locally. All we did was push the change of the `README` file from the local repository to GitHub. That triggered a webhook that notified the cluster that there are some changes to the remote repo. As a result, the first in-cluster activity was executed.

The reason I showed you that activity wasn't due to an expectation of seeing some change applied to the cluster, there were none, but to demonstrate that, from now on, we should let Jenkins X running inside our Kubernetes cluster handle changes to the `dev` repository, instead of running `jx boot` locally. That will come in handy later on when we explore how to upgrade or change our Jenkins X setup.

Please press *ctrl+c* to stop watching the activity.
# Checking the Namespaces present in the cluster
Let's take a look at the Namespaces we have in our cluster.



In this lesson, we will verify the installation done by Jenkins X Boot by checking pipelines, Namespaces, activities and creating a new quickstart project. 

Verifying Jenkins X Boot Installation

Checking the pipelines #

Triggering the `dev` pipeline #

Verifying Jenkins X Boot Installation

Checking the pipelines #

Triggering the dev pipeline #

Triggering the `dev` pipeline #