Puzzle Answer

See the previous post for the puzzle. Here comes the answer.

So, what's the strange part in the screenshot? A-ha, you must've noticed that the build number of the server (the one in the footer of the page) is the same as... one of the running builds! How that can be? Is it a fake? Is it a bug?

Nope, thanks to the two TeamCity features: during-the-build artifacts publishing and not loosing the running builds on server restart.


One of the features of TeamCity that was present since 1.0, but is not always noticed at first glance is on-the-fly tests reporting. With it you do not have to wait till the build finishes to know what tests have passed and what have failed - you simply get the information in the real time. (The feature on its own deserves a separate post or two.)

Getting used to this real-time support users kept asking for more: why not get an artifact as soon as it is ready, not waiting for the build to finish? There were some speculations on how this can be implemented: Should we watch for the files and start uploading them as soon as they are ready? But how do we know the files are ready and written fully? Under Windows, it seems we can detect file is open for writing, but what about other platforms?
For now we ended up with a simple but working solution: build script writer should notify TeamCity that the artifacts are ready to be published.

In 3.1 we introduced TeamCity "service messages": specially formatted strings that, when printed during the build, will be detected and parsed by TeamCity to perform an action. And one of messages implemented in the first place was publishArtifacts. You just print ##teamcity[publishArtifacts 'myValuedFile.zip'] into standard output and voilà: myValuedFile.zip is being uploaded to the server in parallel to the main build process. Once we deployed the build with the feature to our TeamCity server we configured our main TeamCity build to upload installers as soon as they are ready (we are creating packages before running the tests: that proved to be useful on a number of occasions).

That's the first part of the story: we can get TeamCity distribution package while the build is still on its way. What we do next is just upgrade the server (shutdown, place the new application files, startup). And here comes another great feature: the server sate is fully restored as if there were no server restart at all. This is way more easy to describe then it was to implement, but without the feature each server restart would be a pain, which we certainly strive to eliminate.

So, here we are: a TeamCity build that builds itself. Isn't it cool? :)