Jenkins X preview environments

This is the second post about Jenkins X of a series of posts that we will write. Some weeks ago we wrote an introductory post talking about what is Jenkins X and how can help you to deploy your application into a kubernetes cluster.

This time we will talk about a Jenkins X feature called preview environments and how useful is in order to test new features before merge them to another branch.

If you are using gitflow in your company, Jenkins X can help you to manage all the flow that this methodology proposes. Recently, we have been invited to be speakers in a meetup organized by Spainclouds community where we talked about Gitflow and Jenkins X. Here you can watch the recorded session.

Jenkins X environments

Jenkins X, out of the box, comes with 3 kinds of environments divided in two flavors:

• Static environments
  • Staging
  • Production
• Ephemeral or dynamic environments
  • Preview environments

Of course you can create as many static environments as you need to satisfy your team/company requirements (for example, to implement gitflow branch structure) but this time we will talk about preview environments; how they work and how can help us.

Preview environments are ephemeral. That means that they are dynamically created for each PR and they are destroyed when this PR is closed. Doing this, all the necessary resources are only created and used strictly when we need them.

Preview environments

To explain this Jenkins X feature we will assume that we have only Staging and Production environments.

Let’s imagine that you need to develop a new feature. These are the steps that you’ll probably do:

1. Create a new branch to implement the new feature
2. Make all necessary commits to this new branch
3. Once you think that you’ve finished developing the new feature you will create a new PR in order to merge to a branch (develop, master,…)
4. After some code review, unit testing,.. and so on, you will finally able to merge into the desired branch.

Nice! Let’s explain to you what Jenkins X does in order to create the preview environment:

When Jenkins X detects that you’ve created a new PR to merge your branch, JenkinsX starts a pipeline that creates an specific namespace in your kubernetes cluster with all the necessary resources to execute and expose your pod with the content of the branch.

The pipeline that Jenkins X executes is a predefined pipeline defined in Jenkins X buildpacks and depends on the language your app is written. Of course, you can modify these out-of-the-box pipelines to satisfy your needs (adding or modifying steps, testing,…) but we will talk about that in another post. 😉

When Jenkins X finishes you can see something like this in your kubernetes cluster:

bash~$ kubectl get pod -A | grep preview
NAMESPACE                   NAME                               READY   STATUS      RESTARTS   AGE
jx-mycompany-jxqsapp-pr-16  preview-preview-7d48fd5f6-9fjlz    1/1     Running     0          23m

And these are all the resources created inside this ephemeral namespace.

bash~$ kubectl get all -n jx-mycompany-jxqsapp-pr-16
NAME                                  READY   STATUS    RESTARTS   AGE
pod/preview-preview-7d48fd5f6-9fplz   1/1     Running   0          31m

NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
service/jxqsapp   ClusterIP   10.110.76.143                  80/TCP    31m

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/preview-preview   1/1     1            1           31m

NAME                                        DESIRED   CURRENT   READY   AGE
replicaset.apps/preview-preview-7d48fd5f6   1         1         1       31m

When the preview pipeline finishes, Jenkins X exposes your preview environment configuring the ingress controller and creates a comment on your Github PR with this information:

Jenkins X creates a link pointing to the preview environment URL created for this PR.

Once the PR is merged to master, Jenkins X deploys this version into Staging environment to finish all the testing/integration steps. Finally, the last step,  will be promote to Production environment.

Preview environment main benefits:

• Enable developers to collaborate and validate changes before they are integrated back into the codebase
• Test the PR deployed in a real kubernetes cluster before merge
• Raise confidence before promoting code to production
• Create an accessible URL to allow UAT before merge
• Adhere to testing best practices

Would you like to implement Jenkins X in your Company? We can help you. Contact us and feel the Geko Way! 🙂