« Previous 1 2 3 4
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.
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).
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).
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).
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.
Infos
- Jenkins: https://jenkins.io
- Pipelining in Jenkins: https://jenkins.io/doc/book/pipeline/
- Docker: https://www.docker.com
- Official Jenkins Docker image: https://hub.docker.com/r/jenkins/jenkins/
- Install slave as a Windows service: https://wiki.jenkins.io/display/JENKINS/Installing+Jenkins+as+a+Windows+service
- github-release: https://github.com/aktau/github-release
- Set up master and agent machines on Windows: https://wiki.jenkins.io/display/JENKINS/Step+by+step+guide+to+set+up+master+and+agent+machines+on+Windows
- github-release-uploader: https://github.com/starwarsfan/github-release-uploader
- cmake-builder: https://github.com/starwarsfan/cmake-builder
- Docker repository for the Uploader: http://000-000_Git_Jenkins_rls_df_ap.indd
- Docker repository for the Debian builder: https://hub.docker.com/r/starwarsfan/cmake-builder-debian
- Docker repository for the Fedora builder: https://hub.docker.com/r/starwarsfan/cmake-builder-fedora
- jenkins-pipeline-helper repository: https://github.com/starwarsfan/jenkins-pipeline-helper
- cmake-buildtest: https://github.com/starwarsfan/cmake-buildtest
« Previous 1 2 3 4
Buy this article as PDF
(incl. VAT)