It is liberating to do big-time development using Visual Studio without Team Foundation Server in the room. I feel 50 pounds lighter. (Those who know me can imagine how good that makes me feel!) This article presents how I develop software for the Microsoft ecosystem using Visual Studio without using Microsoft’s flagship ALM tools. The theme is to find best-of-breed tools and combine them to get something I like, rather than force myself to use TFS, much of which I don’t like.
Let’s start with the desktop tool for editing and testing code. This is where we spend all of our time. I like to Visual Studio when building software for the Microsoft ecosystem since it’s so attuned to working with .NET assemblies. Full stop. Once that decision is made it’s time to look around for how to take advantage of the best of everything else.
There are excellent choices for integrated source control, task tracking, team collaboration, test-driven development and automated build/deployment using Visual Studio as your integrated development environment (IDE). I use these:
- Visual Studio 2010 Ultimate (IDE)
- Github for source control using the Git Extensions/Mysysgit for Visual Studio
- Mingle from Thoughtworks Studios (task tracking and team collaboration)
- Mingle Extension for Visual Studio
- Go from Thoughtworks Studios for continuous integration/delivery
- IronRuby for some of my automated testing
- Productivity Power Tools for Visual Studio
- PowerCommands for Visual Studio
Visual Studio 2010 was a fabulous integrated gallery of IDE extensions. It’s easy to load up. I try and only install the extensions I need and actually use to make life better. Here’s my list:
My Visual Studio solution has five projects.
This is the project for our .NET client API for Mingle. The highlights are:
Class libraries that wrap the the Mingle (and soon Go) REST APIs with XElement wrappers that expose .NET CLR classes for consumption.
Automated tests primarily written in Ruby using RSpec. Why Ruby, you ask? There’s a nice gem called Sinatra that features a light weight web framework useful for mocking. This makes it easy to take Mingle out of the room when unit testing.
A setup project to create an installer the binaries.stand-up
Task Management and Collaboration
I use the Mingle Extension for Visual Studio connected to a Mingle system hosted internally here at Thoughtworks. These screen shots are from a sample project showing how I query Mingle “cards” (tasks). We use a number of default queries (favorites). “My Work” lists things assigned to me and conforms to the identity of the logged in user of Visual Studio. Individual cards open into a tabbed UI for editing card details. A row of buttons across he top of the card window gives easy access to pre-defined transitions like “start development”, “start testing” and “complete development”.
Our work flow goes like this:
The backlog is what you’d expect in an agile model; it’s the list of things we want. We use a secondary category called Do, which is the list of things we are committed to deliver soon. Each of us takes things from the Do pile and moves them into a state we call Doing when we are actually working on something. I never have more than a couple of things in the Doing state. We use Ready to denote things that are ready to release – nothing more needs to be done at all. We batch things together before releasing simply because it typically makes sense not to formally release each and every story as it is completed. In our shop Done means the story is in the end-user’s hands and they concur it is what they want. Done really means DONE.
We batch things together into iterations and releases using properties of cards (tasks/stories/bugs). A nature of our group is that about half the work we do does not need to be batched into releases and Mingle gives us the flexibility to easily accommodate released-based and one-off development in the context of one Mingle project. It is very nice.
One cool feature of Mingle is something we call “murmurs”, a messaging system that can be connected with Jabber instant messaging. Murmurs quite flexible and useful in different ways, all of them important for team communication and collaboration. My team is geographically dispersed in the United States and the United Kingdom. We use murmurs to keep a running “live log” of comments, questions, observations and status. At any given moment any one of us can jump online and review the murmurs history to come up to speed on current status of a project or each other. I do this in the morning when I start work on the west coast of the United States to catch up on what my colleagues have been doing all day in their office near London.
I use the Mingle Extension for Visual Studio to give me access to a lot of Mingle from within the Visual Studio environment. The following diagram shows you the mains elements of the extension, which supports running pre-defined “favorite” queries in Mingle, drilling down into individual cards, editing and composing new cards.
We have exposed murmurs inside Visual Studio as a lightweight instant message window. You can murmur directly into the window OR from comments to individual cards (tasks). My team’s model for using murmurs has become very a easy and thorough way for us to stay current with each other over thousands of miles in real time. Because murmurs are integrated into Jabber our Jabber IM clients light up if Visual Studio isn’t running. Very cool.
This is enough for this post. Next I’ll tear into the joy of using Git with Visual Studio (instead of TFS), automated testing using a combination of MSTest and Ruby (use the best tool for job) and continuous integration using Go.
This post is from Mark Richter's blog. Click here to see the original post in full.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.