In this step by step tutorial we are going to build a CI/CD solution for a modern cloud application based on microservices with Jenkins X. By the end of this tutorial, we will have a working CI/CD solution that will enable us to develop, test and deliver our application in a fast and reliable way.

Tutorial Chapters

1. Continuous Deployment with Kubernetes and Jenkins X (Overview)
2. Jenkins X Serveless Architecture (Chapter 1)
3. Install & Setup Jenkins X Serverless (Chapter 2)
4. You’re here → Import Existing Project into Jenkins X (Chapter 3)
5. Create Custom Build Pack for Jenkins X (Chapter 4)
6. Integration Testing in Jenkins X (Chapter 5)

---

In this chapter, we will learn how to import an existing project into Jenkins X.

Different Environments Created by default by Jenkins X

Before importing your project to Jenkins X, we need to understand what are the different environments created by default by Jenkins X. By default, Jenkins X creates the following environments:

1. jx environment – In this environment we perform the building and unit testing.
2. Staging environment – In this environment we perform the integration testing.
3. Production environment – Our final production release.
4. Preview environments – Environments for testing purposes.

Step 1 – Create a New Repository 

The first this you will need to do is fork the repository with the source code of your project, and then clone it to your development environment.

In this chapter of the tutorial, we will use the Backend1 demo project as an example. You should fork the main tutorial repository and run the following commands in order to clone it to your development environment:

GIT_USER=[...]
PROJECT_NAME=[...]
git clone https://github.com/$GIT_USER/$PROJECT_NAME
cd $PROJECT_NAME/backend1

Now you have a new repository to work with, but you still don’t have all the needed files for Jenkins X to work with it.

Step 2 – Add Necessary Files for Jenkins X

To add necessary files for Jenkins X, the first thing you need to do is import the project. The command below will import the project. Before running this command, verify that you are inside the home directory of the project we’ve just cloned to the development environment:

jx import --batch-mode

As part of the default import process, Jenkins X will go over the code and choose the right default build pack for the project based on the programming language. Our project was developed in Python so it will be a Python build pack.

You can view the contents of the build pack by looking at:

/.jx/draft/packs/github.com/jenkins-x-buildpacks/jenkins-x-kubernetes/python

To verify the import progress, run the command below:

jx get activities --filter $PROJECT_NAME

When the import is successfully finished, you will see that all the files that are in the build pack now appear in the project repository, the difference is that some of them were templates before and now they are legit files.

Wait, What Happened Here? 🤨

Let’s go over what happens behind the curtains of the import process:

1. Jenkins X chooses the right build pack and pushed the new files to the project’s repository.
2. Jenkins X creates a Jenkins project.
3. Jenkins X creates a webhook to trigger builds whenever there is a code change in the project’s repository.
4. Jenkins X uses skaffold.yaml to build the container image.
5. Jenkins X uses the helm charts to create a build and pushes it to the chart-museum.
6. Jenkins X commits changes to the staging environment repository.
7. It adds the new service version as a dependency on the environment.
8. It adds an ingress for the new service.
9. Jenkins X applies the changes to the Kubernetes cluster, the new service is deployed by Kubernetes in the staging environment.
10. Jenkins X provides us with a URL to the new service.
11. We can interact with our service via HTTP.

Impressive, huh? 😲

The cool thing about this process is that all the changes are tracked in Git and can be viewed by going to: https://github.com/$GIT_USER/environment-$CLUSTER_NAME-staging/env/requirments.yaml

In order to verify whether the service was deployed correctly to the staging environment, you can view the service by the URL that will be printed in the console at the end of the import process. For example, in our demo project Backend1, the following JSON should appear in your browser after opening the provided URL:

{"name": "backend1", "version": "1"}

You can see that you get the name and version of the service, but what about unit testing? This stage is not included in the default build pack. To solve this, you will need a custom build pack for Jenkins X.

This brings us to the next chapter – Go ahead and click here to get started… 🚀