Things have appeared quiet over the last few weeks, but in reality I have been hard at work in a special kind of hell normally reserved for Dev-Ops type people.
I was going to be using my time fixing bugs and getting Ancient Armies ready for the next stage of development. However, I kind of got myself side-tracked….
I had always known that my development environment lacked one very crucial piece of functionality…
The ability to create reproducible and traceable builds along with their associated releases.
Up until now, if I wanted a release, I would fire up Visual Studio and hit build. Next I would run the installer for Ancient Armies, then away I went.
However, this process had a number of issues:
- I could not reliably reproduce an exact build or release from the past.
- I didn’t really know what code changes were in my releases.
- Ancient Armies itself lacked any formal version numbering – which exacerbated point number 2 above.
All of these issues are critical. If one does not know which code changes are in a particular version of the game, then one cannot test the game.
To resolve the above, I decided that I would create an automated build and release management process. After a little research and a personal recommendation, I decided to integrate a tool called TeamCity into my development environment.
What does TeamCity actually do?
A build from within the TeamCity tool.
It allows me to configure and manage the build and release process. With it, I can build a particular version of Ancient Armies, automatically obfuscate the binaries, create installers, run automated tests and then deploy the installers to my NAS system!
That’s a bit of a mouthful!
The best part is that it all happens automatically the minute I commit anything to my remote master. It’s like magic! Write some code, commit it, wait around a minute or two, then miraculously I have a new build directory created on my NAS drive complete with an obfuscated and unobfuscated installer – all this without lifting a finger! 😎
Having the ability to be able to instantly recreate any version of Ancient Armies cannot be underestimated and will be especially useful during the Beta phase of development.
TeamCity also integrates exceedingly well with my JIRA issue tracking system:
The TeamCity dashboard in JIRA.
In the above screenshot I can instantly see that I have built 20 versions of Ancient Armies, of which the last two builds went well. I can even click on the individual blocks to get detailed information with regard to each build.
The key principal with these builds and releases is that they are versioned. In the above screenshot, the current version is build number 20. This allows traceability through issues, code and the final finished components.
TeamCity also integrates tightly with JIRA issues:
The new Team City fields within Ancient Armies’ JIRA issues.
In this case, I can see that this fix (AA-230) went into build number versions 10 or later. This means that I now know precisely which versions of Ancient Armies have this fix in! And more importantly, which versions do not!
The new functionality also allows me to kick off a build from here, or to initiate one when the issue is closed or resolved.
All of this was simply not possible before.
I can even view the specific builds that incorporate code changes from the issue being viewed:
The TeamCity tab of the JIRA issue shows all the builds that incorporate changes for that issue.
The versioning created by the build process automatically flows through to the installers and then on to the final components. The screenshot below shows the file properties for the Ancient Armies game executable:
File properties of the game components now display the file version number from the build.
From the screenshot above I can instantly see that this version of the game was created by build number 20!
Prior to the introduction of this release system, I would have had no idea which version this executable was, or which fixes were incorporated into it – all versions of the game were statically fixed to version 1.0.0!
In addition, the game itself is now aware of its new auto-generated version number:
The about window from the Ancient Armies game.
Just by viewing the About Window for any part of Ancient Armies I can immediately see the dynamic version number for that component. In this case it originated from build number 20.
When it comes to testing, any issues found can now be reported against a very specific version number. This number can then be used to determine which changes went into that release so as to target any diagnostic work.
This all sounds like really good stuff, but there was a rather large fly in the ointment…
It turned out that the installer technology that I was using for my game could not be built by MSBuild. As a result it could not be incorporated into the build and release process. This is a huge flaw. It’s fine having an automated build and release process, but if you cannot build and release the installers for the game, you are pretty much wasting your time!
I was a little shocked. I was using Microsoft technology in my installer, so the last thing I expected to be doing was re-writing it due to future incompatibilities.
There was a hint of trouble ahead from within Visual Studio 2015 itself. Its complete lack of native support for the installer technology that I was using should have rang a few alarm bells…
I searched high and low for a replacement technology. I had found that most commercial installers can cost upwards of £500 and were usually priced in the thousands! Far too rich for my pocket.
In the end I did find an open source technology, one that is even used by Microsoft itself: The WiX Toolset.
This toolset is a double edged sword. It is exceedingly powerful – much more powerful than the technology that I was using, but alas very complex and lacking any kind of wizard or UI design tools. Everything is done by creating low level XML code – not exactly very friendly!
I found myself continuously banging my head on the wall trying to bend the WiX Toolset to my needs. Even the simplest of tasks devoured a disproportionate amount of my time. In addition, the whole toolset follows a multitude of hidden and non-obvious rules, all of which are set to trip-up the unwary.
I think it would be fair to say that the WiX learning curve was exceedingly steep and incredibly precipitous. In retrospect I might have picked a simpler toolset like Inno, but alas, we are where we are…
With much persistence and having written nearly 400 lines of XML code, I now have a world class installer for Ancient Armies. More importantly, this installer can now be built from the command line, which means that it can be incorporated into the automated build process.
Over the next few screenshots I will take you through the differences between the old and the new installers. The old one is on the left, whilst the new one is on the right.
First up, the introduction page:
The introduction page from both installers. (Click for larger version)
Straight away one can see that the new installer on the right looks much more like a standard installer. In addition, and rather importantly, it automatically picks up the build version number from the build process. Here we can see that it is the installer for version 188.8.131.52 of Ancient Armies. This build labelling was simply not possible with the older installer on the left.
Incidentally, the rather alarming legalese text at the bottom of the old installer is not mine, it’s automatically incorporated by the installer itself with no option to turn it off.
Next up is the licensing page:
The licensing page from both installers. (Click for a larger version)
There isn’t much of a difference here other than the ability to print the license agreement on the new one. The new one’s title bar also indicates the specific version of Ancient Armies that is to be installed.
Clicking the next button results in the options screen:
The options page from both installers. (Click for a larger version)
Here the differences are very pronounced. The new installer on the right is much more advanced in that it allows one to pick exactly which components are to be installed. In this case, the Main Game (not optional), the Editors and/or Telematics.
The older installer is an all or nothing affair – you cannot choose your components.
Clicking the next button takes you to the pre-install screen:
The confirm installation page from both installers. (Click for a larger version)
Here, both installers are very similar, though the new one on the right makes it absolutely clear that you are about to perform an install and it warns you that Admin privileges will be requested by the icon shown on the button.
Clicking next takes one to the installation itself:
The progress page of both installers. (Click for a larger version)
The new installer on the right wins again. Its progress information not only shows a progress bar (not currently visible), but it will also tell you what it is doing at any particular time. Alas, it runs so quickly that I couldn’t capture this. In addition, its progress bar takes third party installations like Direct-X into account.
The old installer on the left provides no real feedback other than progress and even this is flawed as it always hangs at the end whilst Direct-X and other third party software is being installed.
Once the installations are completed one is taken to the final screen:
The final page from both installers.
Note that the new installer on the right tells you precisely which version of Ancient Armies you have just installed. This is simply not possible with the older one on the left.
In addition, if one looks at the Windows Applications Management Window, one is now presented with the version number there too:
Windows Applications now show the correct and dynamic version number of the game.
As a result one is never in doubt as to precisely which version of the game is installed.
Writing the new installer using the WiX toolset took an inordinate amount of time and effort. Despite the frustrations, I think the end result was worth it.
I now have a modern contemporary installer that can pretty much do anything.
However, the real story here is that I can now produce automated builds and releases from end to end with dynamic version numbers incorporated into all the finished components. This new capability should not be underestimated!
Had the old installer technology worked with the build process, the whole build and release process would have been configured in a matter of hours. Instead it took me around two weeks of continuous tweaking, two weeks that could have been spent coding.
This is the one downside of home development, one has to wear many hats and be multi-skilled. These additional hats can and often do take one away from the core software development effort. The only silver lining, is that from a professional standpoint it does make me a well rounded developer.
Whilst I’ll look back at this period of development work as not particularly pleasant, at least it is now done and dusted. Time to look forward to some real game development!