Blue Prints‎ > ‎

Praqmatic Jenkins Pipeline

One of the more popular concepts on automated build servers are the concept of build pipelines. The concept is also one of the corner stones in continuous delivery which these days is a must know and do in agile software development. Yet it seems that none of the very popular Jenkins CI build server plugin really support the concept to full extend and in a flexible manner.

Inspired by, or extending, the existing plugins for Jenkins we need to solve this challenge once for all.
By taking on this project you will be introduced to some of the most modern software development concepts that every one talks about. You will be developing in Java, contributing to the largest CI build server community - the Jenkins CI community - and you will gain a lot of community respect from a working solution.

User scenario

When setting up a build pipeline on Jenkins the following process, workflow or features are needed. Some of these are already supported by one or several of existing plugins, but no one have them all and work around must be deployed.
Our scenarios for a pragmatic build pipeline include:
  • overall visualisation: an overview of all steps must be available for both users and viewable on large wall displays
  • historic overview: the last N pipelines must be viewable (users and wall displays)
  • split and join: as some steps in the pipeline may take long time, we need to support those to be split in several jobs, thus a pipeline process must be able to split into several sub pipelines, and join again later. A join should be able to depend on one or more of the jobs joining
  • dependencies: each step depends on another step (basic principle), but the dependency must be flexible and include build results, binaries, promotions and a selection of other objects in the Jenkins model
  • manual steps: the manual steps, that may be part of build pipeline, must pause that specific line and be able to resume from there later on. Even though other pipelines are triggered

Design proposal

We suggest to start with a research of the current solution, and that we give an introduction to the current limitions.

A technical investigation of the current plugin might the be done to find out if a new plugin is needed or current solution can be brought to work.

Estimate

We estimate that students that are unfamiliar with continuous delivery concept and Jenkins CI plugin development would spend 4-600 hrs on an assignment like this.
A professional implementation done by Praqma is estimated to 100 hrs

References

Contact

Call Lars on +45 20 87 25 30 or mail to him on lak@praqma.net if you are interested in this Blue Print.

Comments