Integration Manager

Owned by Stefan Siegl
Last updated: Oct 14, 2016 by Patrice Bouillet
2 min read

As inspectIT is highly focused on quality, we introduced a Development Process in which each feature is checked by an integration manager. During an integration a piece of work a developer created (on a Feature branch) will be integrated with the master branch of the central repository.

The integration manager checks a pull request that a contributor created. If the pull request is valid, he allows the commit to be integrated into the master branch through the GitHub UI.



In the past, it was necessary to push manually against the master branch due to rebase being not available in the GitHub UI. This is not true anymore and it is mandatory now to use the official GitHub rebase & merge action (and through reviewable) so that the pull request will be automatically identified as being integrated.



The Integration Manager is responsible for:

  • ensure that the feature is working
  • ensure that all tests are green
  • ensure that no errors are reported in static code analysis (run the ant task of Agent, CMR and inspectIT, each with the option "clean release-and-analyse")
  • ensure that the commit is correct (naming, squashing, ...)

  • ensure that the commit can be re-based on master

  • check if the realization of the feature complies with other similar realizations
  • ensure that new dependencies that are added are necessary and not already addressed by current libraries
  • ensure that when adding new dependencies (or updating existing ones), the licensing information (Used licenses in inspectIT) is updated and the new license is checked (see /wiki/spaces/ARCHIVE/pages/9109545)

Marking Pull Requests with labels

For easier collaboration, several labels are defined on the GitHub, so that proper state of the Pull Request can be marked:

In-ProgressShould be set by integration manager when the integration starts.
RejectedShould be set by integration manager when integration failed.
Comments only in ReviewableShould be set always if the pull request is coming from a NovaTec colleague or student, if it's not there it's responsibility of integration manager to add it before using Reviewable.

Old labels 

Rebased & MergedShould be set by integration manager when pull request is closed with successful merging.
Not needed anymore because GitHub (and Reviewable) now officially supports rebase & merge through the web UI.