Archive for the ‘TeamCity’ Category.

TeamCity gets thumbs up !

A fellow developer and I implemented TeamCity at work.  Before we had elaborate Nant build script, but the end result was limited.  We only got a fail / success email at the end of the build.  If you get a fail you will have to search for the failure, was it that the database didn’t build or the code ?  Not only are you bound to fail on bad check-ins but also on external factors.  Like the network drive not mounted, out of space or the local drive of the build machine itself.  It could even be an update to the build script which in many cases is harder to detect.  It could also be an UnitTest because of change in code.  Whoever is monitoring the build has to take the time to figure these things out right away and if you don’t they will snowball.

Enter TeamCity which will in most cases pinpoint the failures for you, in a easy to navigate web interface.  Not only that but there are endless useful features in TeamCity.  Such as how long each of your tests took to run with history back in time.  Before you run a build you can see the pending changes and you can even diff the changes to the files in the browser, again this history is kept through time .  Before with a single running nant script we would spit out to a text file the build success / failures to have a audit log.  To open up the audit log and figure out which build succeeded and what changes were in there, uhm just wasn’t that clean, besides not everybody remembers to tag the audit log with the relevant info.  However  with TeamCity all of that is right there on the main page, you just navigate through the configuration you want to see and all the stats are there.  Failure / success, how long it took to run, how long it took to run on the different build boxes, how many UnitTest were run etc.

Besides from that TeamCity offers pre-tested commit.  The way it works is that if your code compiles clean and the build succeeds your code will be checked into the repository.  If not you will get a failure and your code will not be checked in and your fellow developers won’t be affected by the offending bad checkins that you would have had normally in the repository.  We all know how frustrating it is when somebody checks in their code and leaves for the day just to break the build and leave everybody in a non compile state if they dared to get the latest code from the repository.  That leads to a lot of wasted time, we have all done it at some point, some more than others.  At work we are getting to the point were we can start testing the pre-tested commits, we are pretty excited about that.

TeamCity is one of those product were you take a look and you just like it at first sight.  Then you start looking deeper and you find out it’s pretty solid.  It’s true that I would have offered a couple of things out of the box, but they actually built it so it can be extended via plugins, which is always a bonus.  If  you can’t find the feature your looking for odds are that you can write a little plugin to do the task.  TeamCity works with all major repos and databases to keep it’s data.

For a full feature set you should visit TeamCity for the whole story and guess what, if you are in a small to mid size development shop it’s actually FREE.  Check the professional edition On the other hand if your a bigger shop you need to shell out some $$ it’s definetely worth it.

TeamCity Plugins

At work we have migrated our builds to run under TeamCity As with any other software there is always this one thing or two you want to be able to do that the software doesn’t support.  True to form as TC is pretty cool, they wrote it in such a way that you can create your own java plugins to extend the functionality of TC.

We have different configurations of builds for the same codebase. For example we run different build on nightly bases which is more comprehensive than the one we run during the day. The one during the day is a light version ( smoke tests ) while the nightly builds and tests everything.

As TC doesn’t support unique compile numbers across projects I created our own TC plugin to issue the compile numbers.  TC is java based and was initially developed to use for java projects. There for its only natural that the plugin needs to be created in java, TC recommends using 1.5 as TC current version is built using 1.5

The UniqueBuildNumber plugin is very simple, all it needs to do is to override the compile number as TC starts a build, any build for our purpose. To memorize the build order in case the server goes down it will read and write the compile number from a file on the server. That’s where the GUI part comes in as we want the user to be able to set the filename that the plugin should use, that will be saved as well to a datafile. In order to co-exist with TC issued build numbers, the configuration for a project using the uinque build number plugin must be set using unique identifier. Example 1.5.0. {unique}

All thats needed to install is to create xml spring load file,  you drop your jar in the TC lib directory, TC picks that up and lets spring load the class and your in business.  Once the plugin has been installed it will load within TC under the administration settings / Server Configuration.

We also needed an email plugin for our existing scripts to work well under TC.  Our old script would run twice from a .bat file in dos.  On the first run we pipe the info to a log file > build.log on the second run we would have the script read the log file and parse for build failures.  Once that’s done it would send out email with Success or Fail message, in case of failure it would list the failure in the body of the email.

Running under TC I had to get rid of the second run, the build script was modified to run only once.  To accomplish that the log file is downloaded to the TC client from the TC server and parsed for errors, then the email is sent.  The problem however is that TC will send out success / fail message itself, so the script email and the TC emails are redundant, therefor the need for an Email plugin.

The real problem here is that there is no good way of relaying information from the running script to the TC server.  The creators ( Jetbrains ) has this on their list of todo after I complained, they are really responsive to any questions or requests on their forums.  The workaround is to have the script echo information in the log and write a plugin that will monitor the log messages.

In our case once the build script detects error it will be written out to the log with a marker for identification.  Our class EmailInterceptor extends BuildServerAdapter will listen for messages and intercept the marker “EmailInjectMsg=” which is spit out by the nant build script via echo.  Once it finds that in the log it will stash it in a global variable.  Our next class EmailMsgInjector extends RunningBuildPatternProcessor will register for a marker in the email template {EMAIL_MSG_INJECTION} and once called it only needs to return the global string that was set by the EmailInterceptor.

The email template in TC can be customized with various predefined TC variables, but also can be used for our purpose as described above.

Click for the source code