With the announcement regarding the release of Microsoft Visual Studio 2010 on April 12th, I started thinking about some conversations that I’ve had with clients over the last couple of months. Many have expressed interest in getting to use the new development environment and were eagerly waiting for its release. In two cases these clients didn’t have source control systems. I would never have believed it, however I’ve seen it (or the lack of it). To make it worse, one of these is an enterprise level organization with scores of development teams, developing everything from their corporate web site to large scale EAI initiatives. Their reason for not using source control – Team Foundation Server is too complex to install and manage. And they do daily backups. Well, okay then!

Back to Visual Studio. Visual Studio is much more than just a development environment these days, in conjunction with Team Foundation Server, it’s an application lifecycle management system. It’s features include version control, build automation and work item tracking to name but a few. As far as I’m concerned, having these capabilities is essential to organisations that do a lot of in-house development. One option that I often recommend is to use a hosted solution. Let the experts take care of it! Over the past year I’ve made use Praktik Hosting for work with some of my clients, especially the small to midsize and remote clients. They have a great monthly subscription plan and have never been down. So, get Visual Studio 2010, and leave Team Foundation Server to the experts.

Microsoft, Visual Studio 2010, Team Foundation Server, Praktik Hosting

Our build server uses CruiseControl and NAnt to initiated builds. Both can be found on SourceForge.net. CruiseControl integrates with more tools e.g. NUnit, FxCop and NCover, providing builds that are well suited to your company’s internal development policies.

I recently tried to get the continuous build process working on projects with BizTalk Server 2006 and K2.Net 2003. While I’ve automated builds with BizTalk Server before, I’ve not done it with K2.Net 2003. Since you need to have a references to all of the assemblies and executables used by the programming tool used on the server, you usually need to install the application, e.g. installing BizTalk Server 2006 on to the build to get the application to build. In the case of K2.Net 2003, you can get away with installing the K2 Studio and K2 Service Manager, which works well as you don’t have to be concerned with paying for an additional license.

So how do we go about building the K2 application? A couple of colleagues of mine have built a K2 Installer using Visual Studio 2005 that will build an msi file by calling the K2 Studio. Once the installer has been built, getting it to build on the build server is no different to building any other Visual Studio project – using a NAnt call to devenv.exe.

Links:
Steve Hart: Zero Feature Release
Martin Fowler: Continuous Integration
Keith Curtis: K2 Installer
CruiseControl
NAnt

Zero Feature Release, Continuous Builds, K2.Net 2003, K2 Installer,  CruiseControl, NAnt, NUnit, FxCop, NCover