We’re currently in the starting phase of a big new project and we’re already at a steady speed at producing the functionality that we set out to do. Actually we got a very good start, which was contributed by a lot of factors, but one important one is Microsoft Visual Studio Team System.
Before all the project members arrived at the start of construction phase, I was responsible for setting up the development environment. This included the Team Foundation Server (TFS), Build Server, Project Portal (SharePoint), development and test servers and developer workstations.
I was inspired to write this post, by a blog post from a good friend of mine, Jan-Erik Sandberg, who wrote about Rosario (the next version of Visual Studio Team System) and that it might be missing the mark for agile development.
I’m looking forward to all the great new features of Rosario, especially the new functionality for testers – but while we wait, there is plenty of functionality already in the 2008 version to go around.
From what I’ve read and heard from others using Team System, they are actually not fully utilizing it’s potential. Some are only using it for source code control – as a replacement for Visual Source Safe. Others are getting into the whole idea of Work Items and using that for bug reporting and possibly tasks, but few are actually using the whole suite of functionality. At least they are hard to find…
Team Development is a challenge no matter your programming language or application platform. You have programmers at different levels of experience and expertise, different styles of working and arranging code and files. You basically got as many different ways of doing programming as you have programmers on your team. That can be a challenge to manage!
Jan-Erik lays out a plan on what tools to use in their project organization, many of which I think he thinks, are not native to Team System and doesn’t always integrate fully. Maybe he even thinks the functionality is actually not good enough? I want to give example on what we’re doing differently and how you can actually support those tasks using Team System or Power Tools that’s made available for us.
- Cruise Control vs TFS Build
I have previously used CC.NET and it’s a great runtime for Continuous Integration, but with TFS you get a CI-engine built right into the framework, completely integrated. While the management (and editing) of the Team Build Types is not an optimal story, we’re using Microsoft Build Sidekick and Team Foundation Sidekicks by Attrice.
- NANT vs MSBuild
Since TFS Build uses MSBuild, we don’t need NANT any longer. MSBuild runtime is actually installed with .NET Framework, so all the computers have it installed. During the automated deployment cycle, we can execute MSBuild script remotely using WinRM/WinRS tools in Windows Server 2008.
- NUnit vs Team Test
All Team Editions and Professional Edition of Visual Studio has support for writing unit tests. Additionally, you have the Tester Edition and Suite Edition of Visual Studio which has the additional of manual tests, web tests and load tests. All of these tools binds together to form the foundation of your test-scripts. Testing is a lot more than just unit tests, so it’s important to have everything integrated and available. As with most features in Visual Studio Team System, you can extend the framework with custom test types to fit your purpose and need.
- WatiN vs Web Tests
- Perforce vs TFS
I have used various source control repositories and they all have their pros and cons. TFS is pretty mature for a v2.0, but compared to the older competitors they are still behind in the game. There are features you’d expect to be in a source control repository that is lacking in TFS, but it is a very modern architecture built around Web Services and a relational database (SQL Server). It’s also very extensible and event based, you can subscribe to events that happens in your repository and can do action based on those events. TFS is actually the first repository I have hooked into like that, and it’s very useful. Since source control repository is built into the whole Team System (through the Team Foundation Server), there is no reason not to use it. When programmers are checking in their changes, they can actually link those changesets with work items of tasks or bugs.
- JIRA vs Work Items (and Reports)
Have never used JIRA, only had a look at their web site. It looks like a decent tool, but I can’t see that it delivers functionality that’s not: either built into Team System, or can easily be built on top of Team System. We are using Work Items very extensively in our project. Using it to capture requirements, user stories, use cases, various types of test cases, defects (bugs), issues-management, risk-management, tasks, sprint reviews, code reviews and more!
- "MSI Generation" vs WiX
While Jan-Erik doesn’t mention their option of choice to generated MSI packages, Microsoft have a great open source project called Windows Installer XML toolset. While we’re not at the stage where we are building installation packages yet (we’re using MSBuild to deploy at the moment), we will probably be using WiX within a few weeks time.
- Code Generators
As with many software development projects, it is sometimes required to build code generators to simplify certain repetitive and tedious tasks that are prone to human errors. One of the generators we have is actually reading an Office Excel document and generating interfaces based on the specifications from the Office document. This makes it possible for non-technical resources to easily and quickly go from thoughts to implemented code.
I have a lot of other interesting details to share with you regarding Team Development on Microsoft Visual Studio Team System and I hope the above gave you some interesting information.
PS: For my Norwegian readers, don’t miss the chance to win a copy of Visual Studio Team Suite at the next NNUG (Norwegian .NET User Group) meeting! It should include the Workgroup Edition (5-user) of Team Foundation Server.
Copyright Notice: Chess photo taken from www.bigfoto.com, illustrates the need for a team to work together to complete a game (or project).