CI/CD deliverables pipeline

Happy Coincidence

Structuring the Build Pipeline

The Jenkinsfile discussed below defines the entire build. The cmake-buildtest [14] repository contains the source code and the Jenkinsfile for a simple Hello World sample application.

The entire pipeline is first bound to an agent with the label docker. The idea behind this is to map the branch of the pipeline that has the longest run time to this agent without further agent labels. All steps that can be implemented in parallel are then given separate agent labels so that a new builder instance is started for these steps parallel to the instance already running (see the box "Risk of Deadlock"), and the system executes the corresponding build steps there.

Risk of Deadlock

If you allow parallel build steps, you have to pay special attention not to run into a deadlock. For example, if you have two builders, each with one build slot, and two separate jobs start, these two jobs occupy both slots. If both jobs now start parallel build steps, they are trapped in the job queue and wait infinitely because no further build slots are available. That is, you either need to ensure enough build slaves are available or use a job timeout to abort the jobs, if necessary.

The structure of the pipeline depends on the current branch in the next stage. The first stage contains a when statement that executes only if it is not the Develop or Master branch. These feature branch builds (Figure 2) are usually massively simplified. The example here refers to a special Dockerfile that only builds the demo application and launches it for viewing purposes. Most use cases only process their unit tests here.

Figure 2: The build pipeline of a feature branch (view in Jenkins).

The idea behind the other stages is that they only apply to Master and Develop builds. To do justice to the differences between a build and the Master branch, the second stage, Prepare master branch build , contains only a few new variable definitions. From here on, the helper functions described in the previous section are also used – for example, in the Git tag handling stage to prepare the release for GitHub (Figure 3).

Figure 3: The build pipeline in the Develop branch. Platform-dependent branching is clearly visible.

In the last stage, Build steps , the final build of the application, including GitHub deployment, now takes place. Calling the build is again trivial, because the actual build logic is in the corresponding Dockerfile. From there, the GitHub deployment also takes place (Figure 4).

Figure 4: The build pipeline of the Master branch for production operation.

You Have Arrived

In this article, I showed a complete sample setup with deliberately simple individual components that any admin or developer can use to build a continuous integration pipeline with Jenkins (Figure 5).

Figure 5: The release area of the example repository on GitHub.

The domain-specific language (DSL) of the Jenkins pipeline [2] proves to be a very powerful tool to cover all the needs of modern Git- and container-based software development geared toward continuous integration, as well as continuous delivery and deployment.

The Author

Yves Schumann works as Lead Software Engineer at ti&m AG in Zurich, Switzerland. As a Certified Cloudbees Jenkins Engineer, he mainly deals with build and deployment automation and the whole spectrum of tasks relating to source code versioning and tooling of relevance to software developers.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=