This page should be used to collect ideas to shape Kieker's delivery pipeline

Table of Contents

Current Situation (for the Kieker core)

1. Jenkins used with the following use cases
   1. Regular build of commits
      1. job: http://kieker.uni-kiel.de/jenkins/job/kieker/

      • runs

        Code Block
        ./gradlew.sh jenkinsBuild --stacktrace

   2. Nightly release creation
      1. job: kieker.uni-kiel.de/jenkins/job/kieker-nightly-release/

      2. runs

         Code Block
         ./gradlew.sh jenkinsNightlyBuild //// This includes the automatic test of release archives (bin/dev/check-release-archives.sh) chmod +x kieker-examples/OverheadEvaluationMicrobenchmark/executeRemoteMicroBenchmark.sh kieker-examples/OverheadEvaluationMicrobenchmark/executeRemoteMicroBenchmark.sh

   3. Release creation
      1. Operates only on the respective release branch
      2. job 1: http://kieker.uni-kiel.de/jenkins/job/kieker-RC/

         1. runs

            Code Block
            ./gradlew.sh jenkinsBuild --stacktrace

      3. job 2: http://kieker.uni-kiel.de/jenkins/job/kieker-RC-release/

         1. runs

            Code Block
            ./gradlew.sh jenkinsNightlyBuild

Target Scenario

• Pipeline template not only for the Kieker core but also for other projects in the "Kieker orbit"
• Test with different versions of Java (6?, 7, 8)
• No artifact is being rebuild. In each stage after the build stage, the build artifacts from the build stage are used.
• Does it make sense to have a stable branch in addition to master into which only those changesets are merged that passed the entire pipeline?
• Do we want to have a gatekeeper condition (threshold) on the regression benchmark?
  

Stages

• Build
  • Compiles, creates the release artifacts, runs the (fast) unit tests, maybe some smoke tests + static code analysis
• Integration Test
  • Runs the more expensive integration tests
• User Acceptance Test

How do we map the stages to Gradle tasks?

• Example pipeline from a Gradle presentation ( https://www.youtube.com/watch?v=L4ZgTCq6dLQ )
  
  • Compile / Unit Tests
  • Integration Tests
  • Code analysis
    
  • Assemble Distribution
  • Publish Binaries (using these binaries in the following steps)
  • Acceptance Tests
  • User Acceptance Tests
  • Canary Deployment
  • Production Deployment

To be able to adapt this example pipeline in Kieker, we would have to:

•   separate the unit tests from the integration tests
•  merge the gradle threshold code into master to be able to have quality gates for code analysis
•  think about a way for continouous build numbering without breaking sonatype/maven conventions (we could use the build numbering in snap-ci to do so)
  

Pipelines

Pull Request Check

• Goal: Makes sure that a pull request can be merged without conflict, can be compiled, passes the unit tests + static code analysis check and (more? we probably want to exclude the benchmarking here)
• Branch: any?
• Trigger: Pull request
• Executed stages: build

Integration

• Goal: Extensive quality control on the master branch. Automatically merge to a stable branch?
• Branch: master
• Trigger: Commit to master
• Executed stages: all except for UAT and performance regression benchmark
  

Nightly Release

• Goal: Execute all stages of the pipeline except for the UAT and uploads a SNAPSHOT release to Maven Central (automatically available there)
• Branch: master
• Trigger: Cron (once a day)
• Executes stages: all except for UAT.

Release

• Goal: Create and test the artifacts for a release candidate and upload the candidate to Maven Central (manual trigger for the actual release)
• Trigger: Manual
• Executed stages: all (particularly including manual UAT), maybe except for performance benchmark?

Possible Implementations

Jenkins

• Problems:
  
  • No explicit pipeline concept
  • Re-use of artifacts between stages not explicitly supported
  • Configuration via VCS not possible

Travis CI

https://travis-ci.org/kieker-monitoring/kieker

• Benefits:
  • Configuration file is inside the repository
  • Docker compatiblity
• Problems:
  • Very strict resource limitations currently leading to failing builds (there would have to be more tweaking to get this running)
  • No pipeline concept
  • How are artifacts released (no access to workspace)
  • Re-use of artifacts between stages not explicitly supported

Snap CI

https://orca.snap-ci.com/kieker-monitoring/kieker

• Benefits:
  
  • Explicit pipelines
  • Docker compatibility ( https://orca.snap-ci.com )
  • Re-use of artifacts among stages
  • Possibility to mark files/folders as artifacts and access them from the website
• Problems:
  • Configured directly using the snap-ci website (not configuration-file based in the repository)
  • Cost model?

https://snap-ci.com/plans:

Kieker Build Docker Containers

...

Pipelines

Our current delivery pipeline is using infrastructure as code using a declarative Jenkinsfile that is parsed by Jenkins upon receiving a manual trigger or a webhook from GitHub.

Build Pipeline

The current Jenkinsfile in the 'stable' branch can be found at: https://github.com/kieker-monitoring/kieker/blob/stable/Jenkinsfile

The figure below describes the most important aspects of the build steps (attached, you can find the figure as svg and source file (dia)):

Image Added

Pull Request (PR)

Whenever a branch should be integrated into the main development branch of Kieker, it is required to create a pull request towards the 'master' branch. To get a branch merged into the 'master', all automated checks (i.e., branch build, PR build) need to be successful and there needs to be at least one positive review by another developer. If the requirements are met, one of the Kieker developers can merge the branch into 'master'.

From 'master' to 'stable'

Whenever a commit is made to the 'master' branch (e.g., due to a PR towards 'master'), a new build is triggered in Jenkins. This build executes all build steps again to ensure that all requirements are met. If this is the case, the last two steps of that build push the current state in 'master' to the 'stable' branch and upload a snapshot of the artifacts to MavenCentral.

Feature branch

A pipeline for a branch is instantiated for each branch with a prefix KIEKER- (e.g., KIEKER-1432) and triggered for each subsequent commit.

Stages: Same as 'master' to 'stable' except for the final push.

Nightly release

Executed each night based on the stable branch. 

Stages: Corresponds to Master to stable followed by the micro-benchmark.

Nightly release artifacts are available via https://build.se.informatik.uni-kiel.de/jenkins/job/kieker-nightly-release/lastSuccessfulBuild/artifact/

Pipeline on Jenkins: https://build.se.informatik.uni-kiel.de/jenkins/job/kieker-nightly-release/

Release

Executed (manually) to create release candidates and, finally the release, from the respective release branch.

Stages: Corresponds to Master to stable

Kieker Build Docker Containers

The repository containing all the Dockerfile files: https://github.com/kieker-monitoring-docker/kieker-build

...

The most important tags right now are:

• kieker/kieker-build:base (Base image for all other containers based on Ubuntu 15.10 and the additional R dependencies)
• kieker/kieker-build:openjdk6 openjdk8 (Based on :base with openjdk-6 8 installed)
• kieker/kieker-build:openjdk7 (Based on :base with openjdk-7 installed)
• kieker/kieker-build:openjdk8 (Based on :base with openjdk-8 installed)
• kieker/kieker-build:snap-ci-build (Based on :openjdk6, assuming that the kieker repository to build is mapped to /opt/kieker inside the container and executes the Gradle wrapper with the build task by default)
  To execute it locally:

  sudo docker run -t -i -v /path/to/kieker/repo:/opt/kieker kieker/kieker-build:snap-ci-build

• kieker/kieker-build:snap-ci-nightly (Based on :openjdk6, assuming that the kieker repository to build is mapped to /opt/kieker inside the container and executes the Gradle wrapper with the jenkinsNightlyBuild task by default. In addition to the :snap-ci-build container, this container has all packages installed that are needed to run the nightly build; e.g., pdflatex, bibtex, fonts for documentation generation)
  To execute it locally:sudo docker run -t -i -v /path/to/kieker/repo:/opt/kieker kieker/kieker-build:snap-ci-nightly

Some Todos

Pipeline template not only for the Kieker core but also for other projects in the "Kieker orbit"

•  Test with different versions of Java (6?, 7, 8)
•  No artifact is being rebuild. In each stage after the build stage, the build artifacts from the build stage are used.
•  Does it make sense to have a stable branch in addition to master into which only those changesets are merged that passed the entire pipeline?
•  Do we want to have a gatekeeper condition (threshold) on the regression benchmark?
•   Separate the unit tests from the integration tests

•  Insert the call of the check-script (in the stage around the acceptance test?)
  
•  Merge the Gradle threshold code into master to be able to have quality gates for code analysis
•  Think about a way for continuous build numbering without breaking sonatype/maven conventions (we could use the build numbering in snap-ci to do so)