You’ve been squashing bugs in your code all day, and closing them in your issue manager.  Your QA team keep re-opening bugs because they don’t realise you haven’t deployed it to your staging server, yet.  In fact, they don’t really have a clue what is on your staging server.  Annoying, right?  Developers hate the extra work, QA are pretty annoyed they’re wasting their time, your project manager can’t understand why these bugs aren’t being closed, and your end users couldn’t care less but they’re eager for the next product release.

This isn’t really a problem for us any more…

This might sound like a familiar problem, and it might be one you’ve solved by emailing release notes, keeping logs on the wiki,  formal scheduled releases, or just shouting across the room.  But these processes are usually quite a manual affair, time-consuming, and in the age of continuous delivery just don’t integrate with the rest of your tools; your source control, build server, continuous integration servers are all totally disconnected from what you’re doing.

Enter /version

For a long time now, I’ve been deploying /version onto the sites I’ve built. The source is hosted on github, or you can just install the binaries from nuget.org.

Install-Package Puzzlebox.Version.Information

The principle is quite simple, output the assembly build number to the URL.  I keep this in the JSON format, so it can be read by other parts of your application and displayed with JavaScript elsewhere, if you really want.  It also means we can extend it with more properties really easily.

Here’s what our default configuration will give us.
[codesyntax lang=”javascript”]{
“WebApplicationVersion”: {
“VersionNumber”: “1.0.0.0”,
“BuildDate”: “01/04/2013 12:34:55”
}
}[/codesyntax]
This technique works really well if you’re building your releases through a CI server, such as Team City and you’re auto-incrementing that version number.  You should really tag your git/svn repo’s with the same version number, but I’ll leave that for another post.  If you’re not doing that, you can still get a lot out of this technique with the build date, alone.  The output is cached, so that load on the server is kept to a minimum.

So what else can we add to this?

Assemblies

Well, we have our main assembly here, but what about the rest?  You probably want to know which version of your data layer is deployed, or quickly find which third-party library you’ve currently got on your deployed site.  So let’s output the rest as well, we can update the configuration in the web.config with the allAssemblies property:

<version.info enabled="true" httpHandler="true" allAssemblies="true" />

[codesyntax lang=”javascript”]
{
“WebApplicationVersion”: {
“VersionNumber”: “1.0.0.0”,
“BuildDate”: “01/04/2013 12:34:55”
},
“Assemblies”: [
{
“Name”: “App_global.asax.xvytojx4”,
“VersionNumber”: “0.0.0.0”,
“BuildDate”: “01/12/2013 17:23:38”
},
{
“Name”: “Newtonsoft.Json”,
“VersionNumber”: “4.5.0.0”,
“BuildDate”: “11/20/2012 09:45:30”
},
{
“Name”: “Puzzlebox.Versioning”,
“VersionNumber”: “1.0.0.0”,
“BuildDate”: “01/04/2013 12:34:55”
},
{
“Name”: “PuzzleboxVersion”,
“VersionNumber”: “1.0.0.0”,
“BuildDate”: “01/04/2013 12:33:50”
},
{
“Name”: “System.Net.Http.Formatting”,
“VersionNumber”: “4.0.0.0”,
“BuildDate”: “07/11/2012 05:47:53”
},
{
“Name”: “System.Web.Http”,
“VersionNumber”: “4.0.0.0”,
“BuildDate”: “07/11/2012 05:47:59”
},
{
“Name”: “System.Web.Http.WebHost”,
“VersionNumber”: “4.0.0.0”,
“BuildDate”: “07/11/2012 05:48:18”
}
]
}
[/codesyntax]

Current assembly name

You can make the entry-point (and so your main web application version number) clear, by outputting that as well.  This is particularly worthwhile if you’re including all assemblies, as above.

<version.info enabled="true" httpHandler="true" includeWebApplicationName="true" />

[codesyntax lang=”javascript”]{ “WebApplicationVersion”: {
“Name”: “Puzzlebox.Versioning”,
“VersionNumber”: “1.0.0.0”,
“BuildDate”: “01/04/2013 12:34:55”
}
}[/codesyntax]
Secure /version

Lastly, you’re obviously outputting more information about your web site than you’d care to be available to the public.  The last thing you want is for this really useful information to aid any sort of attack on your site. We have two further configuration paramaters for this (and I highly recommend you secure your production sites to localOnly, as you would with any trace information.

excludeBuildDate will remove those build date times from the output, and just show version numbers

<version.info enabled="true" excludeBuildDate="false" />

localOnly will only allow access to your version information if you’re on the local machine, and not publicly accessible to the rest of the world.  You can of course disable it completely with enabled=”false”.

<version.info enabled="true" httpHandler="true" localOnly="true" />

Conclusion

As I mentioned before, this project is hosted on github, so I’d invite anyone to extend or improve. In any case, you’ll going to have a much happier QA team if you’re using it.