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

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

        ./gradlew.sh jenkinsBuild --stacktrace

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

      2. runs

         ./gradlew.sh jenkinsNightlyBuild
         
         chmod +x kieker-examples/OverheadEvaluationMicrobenchmark/executeRemoteMicroBenchmark.sh
         kieker-examples/OverheadEvaluationMicrobenchmark/executeRemoteMicroBenchmark.sh

   3. Release creation
      1. job 1: http://kieker.uni-kiel.de/jenkins/job/kieker-RC/

         1. runs

            ./gradlew.sh jenkinsBuild --stacktrace

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

         1. runs

            ./gradlew.sh jenkinsNightlyBuild

Target Scenario

• Pipeline template not only for the Kieker core but also for other projects in the "Kieker orbit"
• 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?

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

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)
• Trigger: Pull request
• Executed stages: build

Integration

Nightly Release

Release

Possible Implementations

Jenkins

Travis CI

Snap CI