It’s been a while since our last “really geeky” blog post; I’d say we’re overdue. For all of our .NET-based products (Geocortex Essentials, Geocortex Optimizer and more recently Geocortex Fleet Tracker) we use a homogenized development environment which relies on a number of “tools” to enable quality and efficient development. For those interested, I’ll outline the tools we’re using and the purpose they serve along with a degree of satisfaction.
Integrated Development Environment: Visual Studio 2008
This is a no brainer. For anyone developing on the .NET Framework, there simply isn’t a better development environment. Some of our developers also like to use PowerCommands for Visual Studio 2008. Of particular use are the “Collapse Projects”, “Edit Project File”, “Open Containing Folder” and “Close All” commands. A few developers have also become quite accustomed to ReSharper. I haven’t started using ReSharper (yet), but from what I hear they’re a lot like using clipless bike pedals – once you’ve started using them you can never go back.
Also, if you’re using Visual Studio and haven’t heard of GhostDoc, check it out. It saves us a bunch of time when creating, formatting and verifying our code documentation.
Source Code Repository and Version Control: Subversion (SVN)
Our products team has had a lot of experience with a few source code control tools. So far, this is the best. We’ve also used CVS, and VSS. Subversion seems to be the superset of features from both products, while providing reliability and ease of use. Our repository is a few years in running, managing hundreds of thousands of lines of code without hiccups.
We use Visual SVN to integrate Subversion directly with Visual Studio, which provides a nice way to manage files in projects. On the file system, we use TortoiseSVN which is built in to the windows shell and reduces management of a repository or working copy significantly. TortoiseSVN is a must-have when using SVN unless you love using the command line.
Automated Build Environment: MSBuild
While we use Visual Studio (VS) to routinely build our products during development, we also run an automated build on a build server separate from Visual Studio. Once projects get to a certain size there’s usually a need to integrate an automated build external to your development environment to incorporate things like documentation, help, installers, automated tests, and packaging. MSBuild serves as a good language since it’s what VS uses internally for project files and it allows us to separate generic build steps (common to all products) from those specific to one product.
Continuous Integration: CruiseControl.NET
When you’re working on a product with more than a few developers, continuous integration becomes invaluable. When a developer commits (checks in to SVN) some code they have modified, CruiseControl.NET (CCNET) detects the change on our build server and automatically runs a build informing the developer of the outcome. We’ve also configured CCNET to run nightly builds, so we always have a drop of last night’s installer.
CCNET is originally a port from the Java-based product, Cruise Control. The web-based dashboard and desktop tool (CCTray) are great ways to get a sense of how all products are doing. For example, right now all builds are running successfully, Geocortex Essentials was last build due to a developer check-in at 9:43am, and the next build check is at 10:39am (in one minute).
Unit Testing: NUnit and NCover
We use NUnit to write our unit and integration tests for our .NET-based products. It does exactly what it’s supposed to do, and it’s easy to use. A low barrier for entry was one of the main requirements when assessing unit testing technologies, and NUnit definitely holds up in that regard. The latest version (2.5) has some nice new feature’s we’ve been able to take advantage of (specifically, parameterized test cases).
NCover is a tool which provides feedback on the amount of code which is covered (executed) by unit tests. Developers can manually run their unit tests with “coverage”, and a GUI tool displays the lines of code which were run by the tests and those that weren’t. Further, it will report the percentage of code which is covered by testing which is useful for enforcing a minimum baseline for testing our products.
We currently use the version of NCover which is packaged with TestDriven.NET for its integration within Visual Studio.
Code Quality: FxCop and StyleCop
When more than a few developers are working on the same products, it can save time and increase code quality if the shared code is conformant to formatting and “best practices” standards. FxCop and StyleCop are tools which enforce coding practices, and code formatting respectively.
By integrating both tools into our continuous integration process, we’re able to reject code which does not conform to standards thus enforcing a baseline level of quality in every line of code committed to our products. What might sound like overhead initial development pays off in code maintainability, readability and overall quality.
Installer Technology: WiX (Windows Installer XML)
WiX is a language used to generate installer packages (MSI files) for Windows. Unfortunately, any installer technology can only be as advanced as the output it generates… in the case of WiX, for example, the limitations of MSI technology are the primary impediment to logical and powerful language tools. That withstanding, WiX has been doing a pretty good job for us. It’s less maintainable then we would like, but perhaps it’s the least of a few evils in the installer world.
Feature and Defect Tracking: OnTime 2009
I’ve blogged about Axosoft’s OnTime in January 2008. I’m still enthusiastic about its performance. It’s a really well maintained product and has provided us with a ton of value.
If I had to start a product development department from scratch I wouldn’t neglect any of the aforementioned tools. The more processes we can automate, the more time we can spend writing code specific to the business requirements surrounding a feature. There are other minor tools we use less frequently, or unrelated to product development specifically that didn’t make this list, but I think I’ve captured the bulk of it.
