Building ASCOM Platform 5.1
I’m currently involved in a project to create the next version of the ASCOM Platform – version 5.1. I’ve taken the lead role in putting together the build and deployment for the next platform release. The journey began a few weeks ago and I think it is worth just mentioning some of the technology and techniques used so far. We currently have a team of 10 developers located worldwide, working simultaneously on the code base (8 actively developing and 2 providing oversight). To get this level of collaboration working successfully, we needed to use some high-octane tools.
Our base development platform is Visual Studio 2008 and Microsoft .NET Framework 3.5 SP1 (3.5 SP1 will be a prerequisite for Platform 5.1). We’re using Subversion for version control and a TeamCity build server.
Teamwork
TiGra Networks is currently hosting a development server, consisting of:
- VisualSVN server – for source code control. VisualSVN Server is built upon Subversion 1.6 and enables developers to checkout and commit code changes over the Internet, using HTTP protocols. VisualSVN Server is a free product.
- JetBrains’ TeamCity - Distributed Build Management and Continuous Integration Server. The build server watches the SVN repository and whenever new code is committed, a build agent checks out all the changes and tries to build the code. If there’s an error, developers get immediate feedback. TeamCity can also run unit test suites as part of the build process (although we don’t currently use unit testing with ASCOM). TeamCity is a free download and is a really amazing product.
On the client side, developers can use TortoiseSVN to manage their working copy of the source. Those with Visual Studio Standard or Professional can use the VisualSVN client, which makes it a bit easier to deal with Subversion from within Visual Studio. The Visual SVN client is free for open source projects and for Microsoft MVPs, otherwise a small license fee is payable per developer. There’s also a visual studio plugin for TeamCity, which allows developers to submit private builds and have their source code changes committed automatically if the build is successful.
Subversion for Source Code Control
I’m finding Subversion (SVN) really good to work with. I’ve used a number of Source Code Control (SCC) systems over my 20-odd years as a software engineer and SVN has to be the best. It is fairly lightweight yet powerful, low friction, free and overcomes many of the limitations of other systems. SVN fully supports branched development and integrates well with Visual Studio, while making it easy to support remote developers. On the client side, SVN keeps out of the way, it does not use any file locking so it’s really transparent to the development IDE. I was so impressed with how well SVN worked for the ASCOM project that I’ve dumped my old version control system and adopted Subversion for all of TiGra Networks’ development projects.
I have the ASCOM SVN repository partitioned up into 2 main areas. All of the core platform components have limited access because the source code is not all in the public domain. Then we have another chunk of code devoted to drivers and simulators. The access here is more open as the source code is, by definition, in the public domain. The simulator developers have read-only access to all the simulator code and write access to the project(s) they are working on. This gives all of the developers very good visibility of the overall progress.
Continuous Integration
The idea of continuous integration is that all new code is immediately built and tested by a generic build agent. If a developer commits code that breaks the build, the TeamCity server will make it obvious what caused the breakage and, more to the point, who. That developer is identified as the build-breaker until they fix it.
Building the code away from the developers workstation helps to identify dependency issues and ensure that the build can be run in a standard environment. When I took over the build, there were several manual steps involved in assembling a Platform release. My goal for Platform 5.1 is to have the whole process completely automated inside Visual Studio and to not rely on any platform component being preinstalled.
Using a build server poses some challenges, especially given the security partitioning on the SVN repository. Driver and Simulator developers can’t directly reference the platform component projects and neither can they rely on components being installed in the GAC. After studying lots of resources on the ‘net, it seemed that the way forward was to create a Dependencies folder, where precompiled versions of the core platform components could be placed. These components are committed to the SVN repository where the developers can check them out and reference them. So far, the technique seems to be working.
It is really amazing what high quality developer tools are available for absolutely no cost.
What’s Next?
The next stage of the platform build is to create the Windows Installer packages, this is still work in progress. Beyond that, I’d like to add some sort of issue tracking so that we have a way for end users to report bugs and to track them to resolution.