featured image Example setup of continuous integration platform

July 20, 2015 / by Daniel Huchthausen / In EcoSystem

Example setup of continuous integration platform

+++This post was migrated from our former blog about SCM-Manager Universe. It is based on the previous version of Cloudogu EcoSystem. Therefore, it is only available in English.+++

In software development there is no such thing as the holy grail, no perfect process that you can follow in each project and that ensures that everything works out smoothly. But there are tons of very helpful best practices that you can use as a guideline. One of the principles of Cloudogu EcoSystem is that you can adapt it to different software development processes, because it isn’t designed specifically for one process. To give you a better understanding of how you can use Cloudogu EcoSystem, we want to show you how we configured the platform for one of our projects.

Platform setup for Continuous Integration

The aim of our configuration is to achieve a very high quality for the software that we develop. Especially stability and performance are crucial, because it is being used in an production environment by our customer. Therefore we frequently perform tests and keep track of the results to reveal downtrends early. Also the traceability of changes is very important.

Our development methodology is partly agile. It contains parts of Scrum, like sprints and daily standups, but we are not using the traditional Scrum roles. Also we’re working with a fixed scope, because all the requirements for the first release were already defined at the beginning of the project.

In the following you will find how we configured SCM-Manager, Jenkins and SonarQube to reach our goals.

Git and GitFlow with SCM-Manager

For our project we use a git repository and we are following GitFlow. Modifications to the code are only allowed in feature branches and there is one feature branch for each feature. Whenever a feature is finished, the developer merges it into the develop branch. After all features of a release are finished the develop branch gets merged into the master branch.

Continuous Integration with Jenkins

In Jenkins we configured 4 different jobs and installed additional plugins to implement the workflow. In the following you will find a list of the configuration and a list of the Jenkins plugins we use.

Job to Build Feature Branches

After each push to the repository the build for the tagged feature branch gets triggered. The build contains these steps:

  • Compiling
  • Execution of unit tests
  • SonarQube code analysis and quality gates with sonar branch parameter
  • Integration tests

Job to Build Develop Branch

Whenever a feature is finished, it should be merged manually to the develop branch. After the merge the build of the develop branch is invoked. It contains these steps:

  • All steps from the build of the feature branches
  • Site and artifact deployment to Sonatype Nexus
  • Deploy to integration environment

Job to Execute Nightly Build

This job builds the develop branch regularly over night. The nightly build contains these steps:

  • All steps from the build of the feature branches
  • Performance tests

Job to Build Master Branch

The build of the master branch needs to be triggered manually. It contains all steps that are necessary to release a new version and to prepare the next development iteration.

  • All the steps of the build of the develop branch
  • Merge develop branch to master branch
  • Site and artifact deployment to Sonatype Nexus
  • Preparation of develop branch for next development iteration by incrementing the version

Jenkins Plugins to automate the workflow

To implement the described workflow, a few additional plugins need to be installed to Jenkins. Those plugins allow us to use external scripts and additional tools. These are the most important additional plugins:

Plugin Purpose
build-name-setter This plug-in sets the display name of a build to something other than #1, #2, #3. It allows you to distinguish the builds of the various feature branches.
conditional buildstep Allows you to wrap any number of buildsteps and to control their execution based on a defined condition (e.g. BuildParameter).
Durable Task Plugin A library that offers an extension point for processes which can run outside of Jenkins and can yet be monitored.
Email Extension Plugin This plugin is a replacement for Jenkins's email publisher.
Git server plugin Allows Jenkins to act as a Git server.
jUnit Plugin Allows jUnit-format test results to be published.
Parameterized Trigger Plugin This plugin lets you trigger new builds when your build has completed, with various ways of specifying parameters for the new build.
Release Plugin This plugin allows you to configure pre and post build actions that are executed when a release build is manually triggered.
Run Condition Plugin Core conditions to select whether to execute a build step or publisher.
Workflow: Aggregator Collects all workflow-related plugins as dependencies to make them easier to install and demonstrate.
Workspace Cleanup Plugin This plugin deletes the project workspace after a build is finished.

Quality assurance with SonarQube

Quality analysis for each branch

Thanks to the sonar branch parameter in Jenkins each feature branch gets it’s own code analysis in SonarQube. This feature can be used as a post build action.

Without using this feature the analysis result for the feature build job would be jumping between the results for the different branches. With this feature you get the results for each branch individually.

Quality Gates set the stand

For this project we specified the following quality gates and quality profiles in SonarQube:

The code analysis is based on the quality profile “Sonar way with FindBugs” for Java and “Sonar way” for CSS, JavaScript and Web. Based on these profiles SonarQube calculates, amongst others, the values for the quality gates we specified.

The yellow exclamation marks represent warnings and the red “x” stands for errors. The difference is that errors make the analysis and thereby the build fail. Warnings do only result in build warnings

Fully automated continuous integration workflow

As you can see we made quite a lot modifications especially to Jenkins, but after the initial setup and the implementation of the workflow the system works like a clockwork. The various plugins enable the unit, integration and performance tests as well as the automated deployment. In combination with the code analysis by SonarQube we instantly get feedback about the quality.

The reason why we don’t ship the Cloudogu EcoSystem configured like this is that it is a very specific configuration and the basic appliance is supposed to be universal. Hopefully you found some inspiration in our configuration.

Related posts:

Trainings

If you want to learn more about using Cloudogu EcoSystem in Agile Projects, you should check out our "Best practice in Agile and Continuous Delivery training"

Update Oct. 22nd: Updated post and adapted it to Cloudogu EcoSystem.


Daniel Huchthausen
Daniel Huchthausen

- Consultant -

When he is not exploring the wilderness, Daniel keeps himself busy with topics such as quality assurance, testing and PM methods.