Configuration Drift

Recently in my day job I encountered an issue. Our continuous integration system is setup to build a Java project which is hosted in a Git/Atlassian Stash repository.

The java project is using native libraries (*.so on linux) which are referenced by one of our third party jars.

One of our feature branches wants to use the version 8 of this third party, the rest of the branches use the version 7.

The build agents run with a LD_LIBRARY_PATH containing the folder for the version 7 of the library.

The continuous integration server that we are using - TeamCity - can set environment variables - but I am not aware of a way of telling TeamCity to set up different environment variables for the same build configuration depending upon the feature branch being build currently.

Also I would not want to enter this requirement in the build configuration, because I would have to change the build configuration every time a developer does a merge.

I mentioned this problem under the keyword configuration drift in an issue TW-18911 of the bug tracker of JetBrains.

Today I looked at Travis CI. The documentation of Travis CI explains that Travis is using Travis.yml files which are checked in in the root of the source tree of the projects to be built. And Travis.yml is taken from the branch being built. Since Travis users can specify for instance the major version of the JDK to use for the build, they can build one feature branch with Java 1.7 and another with Java 1.8, and the developer preparing the change can even have the elegance to check in the change in Travis.yml at the same time that he starts making use of Java 1.8 and maybe changing his pom.xml or build.xml to indicate that the code needs to be compiled with source=1.8.

CruiseControl has a potential solution to this type of problem if one sets up one project per module to build and per branch. CruiseControl configuration supports includes. One can make a directory structure for the project configuration where each branch's configuration is in a separate folder. That's not a great solution either as it requires some scripting to setup this file/folder structure, and it must be done in advance of actually starting builds on a branch.

Conclusion : CI systems which want to be really helpful for agile teams should allow the developers to document basic facts about the build process in the source tree itself. In TeamCity's world, that would be at least the build steps page of the configuration.

As far as I know, Jenkins is configured from a web page and the configuration of the build steps does not come from a descriptor supplied by the developers and branch dependent either.