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

        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?

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

• Problems:
  • No pipeline concept
  • How are artifacts released (no access to workspace)
  • Re-use of artifacts between stages not explicitly supported

Snap CI

• Benefits:
  
  • Explicit pipelines
  • Re-use of artifacts among stages
• Problems:
  • Cost model?
  • Configuration via VCS not possible?