Exploring Jenkins

Jenkins was one of the most popular CI tools used to build and test different kinds of projects. It’s now also used for CD and is a very important part in DevOps practices.

Firstly, we need to understand what CI is. CI is one of the most popular application development practice in recent time. Developers integrate new features, bug fixes in a code repository. Then CI tool verifies automatically, builds and tests to detect any problem with current sources and provides quick feedback to the development team.

“Jenkins is an open source automation server written in Java. It helps to automate the non-human part of the software development process, with continuous integration and facilitating technical aspects of continuous delivery. It is a server-based system that runs in servlet containers such as Apache Tomcat”–Wikipedia

 

Plugins

Plugins make Jenkins easier to learn, easier to use. There are various categories of plugins available for it, such as:

  1. Source code management
  2. Slave launchers and controllers
  3. Build triggers
  4. Build tools
  5. Build notifiers
  6. Build report
  7. Post-build actions
  8. UI plugins
  9. Library plugins

In this article, I’m using Laravel project with Git repo and Java e2e automation test for example build. So there are should-have plugins:

  1. Jenkins Pipeline plugin
  2. SonarQube
  3. Github Integration plugin
  4. Allure Jenkins Plugin
  5. Default suggestion plugin from Jenkins

 

The pipeline as code concept

The default interaction model with Jenkins, historically, has been very web UI driven, requiring users to manually create jobs, then manually filling in the details through a web browser. This requires additional effort to create and manage work to test and build multiple projects, it also keeps the configuration of a job to build, test or deploy separately from the actual code being built, tested or deployed. This prevents users from applying their existing CI/CD best practices to the job configurations themselves.

With Jenkins pipeline plugin as I listed in should-have plugins, users can implement a project’s entire build-test-deploy pipeline in a Jenkins file and store that alongside their code.

Building on the core Jenkins value of extensibility, Pipeline is also extensible both by users with Pipeline Shared Libraries and by plugin developers. 

The flowchart below is an example of one CD scenario easily modeled in Jenkins Pipeline:

Pipeline syntax overview:

There are 2 kinds of pipeline code:

1.Declarative Pipeline (New concept):

Declarative Pipeline replaces Groovy variable assignments, control structures, loops, and exception handling with a predefined structure and model to allow users of all experience levels to quickly create consistent, concise Pipelines without learning Groovy.

All valid Declarative Pipelines must be enclosed within a pipeline block

2.Scripted Pipeline (Advance):

Scripted Pipeline, like Declarative Pipeline, is built on top of the underlying Pipeline sub-system. Unlike Declarative, Scripted Pipeline is effectively a general-purpose DSL built with Groovy. Most functionality provided by the Groovy language is made available to users of Scripted Pipeline, which means it can be a very expressive and flexible tool with which one can author continuous delivery pipelines.

In this article, I can’t give you a full introduction to Pipeline syntax. If you want to get deeper with this, this docs contains fully syntax and examples for both ways of pipeline code.

 

Jenkins in Actions

There are a lot of ways to approach Jenkins. You still can get your job done perfectly even you are using Web UI driven or Pipeline as Code. Base on your organization, projects, and skills, you can choose what is most suitable for yourself.

In this section, I’m introducing how did I implement CI/CD server for my organization.

1.Requirements:

a. Implement CI for automated build Laravel, Rails projects

b. PHP code should be following PS-R2 coding standard.

c. Execute e2e test written in Java

2.Actions

a. For building project, I prefer using docker container and execute bash script inside.

b. For checking Code quality, SonaQube is my best choice

c. Following requirements, I create a skeleton for the project:

d. Then I filled up actions for each defined stage in Jenkins file for a Laravel project:

From these codes, we can see BRANCH_NAME and CREDENTIAL_GITHUB are input variable from Jenkins project, so we need to configure some more things:

3.Refactor

Let’s do some refactor for this:

Firstly, we need to implement this pipeline for more than one project, so reuse pipeline code and keep it D.R.Y should be a good way for saving development time.

The pipeline has supported for creating “Shared Libraries” which can be defined in external source control repositories and loaded into existing Pipelines.

a. Defining Shared Library structure:

b. Phppipeline.groovy file:

 

Conclusion

There are some important things that we should remember:

I hope that I’ve shown you the most common tasks for implementing CI/CD with Jenkins. Please feel free to leave your comments below if you have any question or contact us via email for free consultation. Don’t forget to share & subscribe to our blog!