Test-driven Configuration Management with Maven

As an agile software developer practicing test-driven development (TDD) it is normal to write the tests first. Unfortunately, switching roles and wearing the „configuration manager hat“ it is sometimes hard to adhere to the same rules of TDD because there are tools missing which provides test infrastructure for build management. One solution might be to use the build server for such tasks.

This is an example of Test-driven dependency mangement with Maven:

We can use the versions-maven-plugin to list all available updates of plugins used in the pom.xml.

For example Maven might produce this information on an updated version of the release plugin:

mvn versions:display-property-updates
...
[08:01:04][de.timomeinen.maven:maven-parent] 
[INFO] The following version property updates are available:
[08:01:04][de.timomeinen.maven:maven-parent] 
[INFO] ${version.plugin.release}......... 2.4.1 -> 2.4.2

If we trigger a nightly build on the CI server and let the build fail on an update message, we have a nice test if there are any updates available for our Maven project.

This example uses TeamCity, but you can surely adopt it to other CI server as well.

Configure a new Maven Build Step:
teamcity-setup

And define a Build Failure Condition (Step 4):
teamcity-setup-build-failure-condition

Fail build if build log contains exact text „The following version property updates are available“ with the Failure message „Updates available“.

The result looks like this:
teamcity-01

This will let the build fail on a dependency update, gives you a nice message and TeamCity even produces a link to the part of the build log, where you can see which dependencies you can update.

That’s a nice example of what I call „Test-driven System Administration (TDSA)“.

Use JRebel to develop TeamCity plugins with more speed and fun

Regarding the TeamCity Documentation a plugin developer has to restart the server, to see code changes. JetBrains recommends to use Javas HotSwap. But as we all know (at least the JRebel fans), HotSwap has a lot of limitations. For example, it is not possible to change method parameters or introduce new methods.

JRebel is a great alternative and doesn’t have these limitations. And as it turned out, it is very simple to use JRebel with TeamCity plugin development: Just create the rebel.xml and put in the plugins resource path. The file has to reside on the top most hierarchy of the jar.

To generate the rebel.xml, just use the IDE plugins. In IDEA for example, I right-clicked on the project name and select generate rebel.xml and then I stored the generated file in the resources-directory.

Now, I can develop the Piazza plugin without restarting the TeamCity over and over again. Thank you, ZeroTurnaround!