Using Git with Visual Studio ALM: Why Visual Studio ALM?

In this blog entry, I want to give reasoning for using Visual Studio ALM 2013. The “case study” here is based on a client that uses Visual Studio and Git, but does not utilize any unified system for Application Lifecycle Management (or ALM). This is the intro for a series of video posts on how to do this.

This particular post uses the words “Visual Studio ALM” as a high level concept. As I drill down in later entries, you will start to see different products and parts of products coming out of this larger concept. The point here is using “Visual Studio ALM” is much like using analogies. It is a good way to start the conversation to get the idea nailed down, but breaks down eventually. As a takeaway, understand that much of what “Visual Studio ALM” will mean, in the context of this series, is “Team Foundation Server”.

ABC123 Company

The series here is going to focus on a fictional company, ABC123, which produces childhood content for websites. The company has a website, some web services and offers content services, as well as a child health advice line, for a wide variety of partners.

The development team uses Git for their source repository, a decision made both due to familiarity of one of the senior developers and the open source nature of the repository. They have adopted OnTime for time tracking and a consulting company helped them utilize the tool for Agile project management. They also use Trello in some groups to facilitate a more Kanban type of approach to Agile project management, but this team still enters time into OnTime. JetBrain’s TeamCity has been picked up for build management, which is set up in a continuous integration model. There is no continuous delivery at the time, but the concept is being considered for adoption.

The Project Management Office (PMO) handles both portfolio management and tasks in Excel initially and the tasks are then placed into OnTime and/or Trello for the development team to work on. The PMO also uses Microsoft Project to track projects.

Due to the use of a variety of programs, most which are not commonly used in the marketplace, the learning curve for new developers is rather high.


Here are some recommendations given to ABC123.

  1. Move from a server farm to a virtual environment utilizing multiple VMs.
  2. Implement Visual Studio ALM
    Some specific pieces of “Visual Studio ALM” I would like to implement are:
  • TFS Integration with Excel and Project (Long Term Project Server is a possibility)
  • Lab Management
  • Work Item Tracking
  • Agile Reports
  • GIT Integration

Recommendation 1: Use a Virtual Environment

This first recommendation is not part of the series, but I am including it as virtualization is mandatory on some levels. Lab management requires virtualization to work, so you have to work with virtual machines on this level at the very least. To create labs that more closely mimic production, virtualization is advised in the production environment.

I am under the belief we will eventually move more and more of our stuff to the cloud, either private or public. Technically, the cloud is possible on physical machines, but you find it more commonly done virtually, as it allows you to more quickly expand your cloud, or clouds. This is a topic far beyond the scope of this entry, but the takeaway is you are likely to virtualize your environment(s) at some time, and biting it off prior to cloud implementation will allow smaller steps over some type of “big bang”.

Enough said on this one.

Recommendation: Adopt Visual Studio ALM

This recommendation is for a variety of reasons, but most of the reasons fall into three buckets.

  1. Consolidation of toolsets to make it easier to accurately track projects
  2. Integration with common Microsoft products, including Visual Studio, which is currently used for development in the company.
  3. Open new scenarios

The first reason is focused both on a) flattening the learning curve for new developers, saving the company money and b) allowing additional scenarios that are difficult under the current toolset and environment.

The second reason is to enable the team to use the tools they currently use and eliminate the need to enter the same information into multiple tools.

The third reason focuses on the fact that the current reporting story is rather thin. There is limited reporting on productivity and few, if any, reports on different parts of the development process. There are manual processes for other types of reporting (for example, determining what items were checked in for a particular user story.

Features to Use in Visual Studio 2013 ALM

In future posts, I am going to illustrate many, if not all, of the following features The only one I am not sure I can illustrate, at least at this time, is lab management, but I will work to set up an environment once my powerhouse computer is returned from Dell support.

NOTE: These are the same features mentioned earlier

  • TFS Integration with Excel and Project (Long Term Project Server is a possibility)
  • Lab Management
  • Work Item Tracking
  • Agile Reports
  • GIT Integration
    Integration with Excel and Project

    The PMO should not have to change tools or enter work into multiple tools. Conversely, the developers should be able to see the work items without leaving Visual Studio. Visual Studio ALM allows project managers to enter in user stories and tasks into TFS repositories from tools like Excel and Project. The data can be pulled out at any time into these tools, altered, added to and checked back in so team members can start working on them.

    There are some scenarios that would benefit from the use of Project Server, but this is a longer term recommendation. Most of the functionality needed can be facilitated by using Project with Team Foundation Server 2013.

    Lab Management

    Lab management is useful to set up a test environment that can be reset easily when a new build is released. The ultimate goal is to facilitate continuous integration and continuous delivery scenarios. The diea here is to have the environment reset before a build is pushed and then run all tests in an environment that is similar the production environment. This does not have to be the testing environment, as it can be a developer test environment separate from environments like SIT (Staging Integration Testing).

    Work Item Tracking

    Under the current setup, ABC123 has a hard time tracking what has been changed in their code or relating code to particular user stories and tasks. While this may not seem very important, understanding the motivation for change helps you avoid breaking new features when fixing bugs in old features, and visa versa. The benefit of using Visual Studio ALM here is source is related to tasks and user stories, so you have the ability to run a variety of reports to see how change occurs.

    Agile: Reports and Features

    Currently ABC123 has very few reports. The tool they are using has a basic burndown chart with an estimated completion date, and whether or not the team is on track to its expected end date. It also contains a user productivity report that states all of the time logged in the tool. To gain further metrics is a manual process.

    Now, the word “reports” here is rather generic. The types of information I am talking about here are things like the following list. The items that can easily be determined today are shown with an asterisk. Items with a plus are items that can be determined today, but take a bit more work. Other items (bolded) require manual reporting.

    • Burndown (Scrum)
      Release Burndown*
      Sprint Burdown*
      Individual Burndown+
    • Cumulative flow  (Kanban)
    • Blocked work items and tasks
    • User work log*
    • User productivity in team
    • Velocity*
    • Code Coverage+
    • Code Quality Metrics
      This is not an all inclusive list, but covers a bit of the important features needed for ABC123 IT staff to complete projects.
      NOTE:: All of the items are technically possible today, if enough effort is put in.
    GIT Integration

    The company has no desire to move away from Git for source control and there is no reason they should. But, it would be nice to have the majority of the Git functions completely integrated into Visual Studio and to have the ability report on code in the same reporting system the project is tracked. In addition, it would be nice to be able to track what pieces of code were check-in with different tasks, work items and/or user stories. Visual Studio ALM is useful in all of these scenarios.


    This blog entry focuses on the scenario for the rest of the series. From this point on, I am going to focus on a variety of topics, including:

    • Setting up GIT on user machines
    • Creating/adapting projects to use TFS with GIT
    • Agile project management with Visual Studio ALM
    • Next in series: Setting up GIT on WIndows
  • Peace and Grace,

    Twitter: @gbworld

  • Options in Visual Studio 2013

    This blog entry is a transcript of a video. You can view the entire contents of my Visual Studio videos on YouTube.


    In this video, I would like to cover a few of the options in Visual Studio. On the screen now, you can see the Visual Studio Integrated Development Environment, or IDE. If I click on the Tools menu and then Options, I can bring up a dialog box.

    The default location, when it opens, is the General Options for the Environment.


    In the newer versions of Visual Studio, you have the option to change your theme.


    The default theme for both Visual Studio 2012 and 2013 is the light theme.


    If I click on the menu, I see I can choose the Dark or Blue theme, as well. I will select the blue theme, as it is new for Visual Studio 2013. Personally, I think this theme adds a bit, especially in the offset of the toolboxes, but is not that much different from the light theme.


    I can also open the options and choose the Dark theme. If you want to reduce eye strain in lower light environments, this is a good theme to use.


    Task List

    Still under Environment is another nice feature that I don’t find utilized very often. That is the task list settings.


    One great use for the settings here is to add your own tokens. As I try to push quality, one token I like to add to the list is ADD TESTS. While TODO will cover this in many environments, I find adding this tag and giving it high priority puts the point across that the team should be focused on ensuring they are writing tests first and ensuring proper code coverage. I add the //ADD TEST comments during code reviews, as test coverage is part of the review.

    I have also found that adding team members’ names can be useful in some instances, especially with distributed teams.

    One more environment thing. If you want to see videos, like I have on my front page, you have to turn them on. This is done by clicking the Download Content every checkbox under Startup.


    Projects and Solutions

    If I move out of Environment and down to Projects and Solutions I can show you the next thing I change. Since my development machines are not shared, I want to place my code in a common place. My location is C:\projects. I keep the templates in their normal location, however, as I see no reason to dink too much with these templates.


    Project Options

    If I am on a project using Visual Basic, which is rare, I also like to click on the Visual Basic options and turn Option Strict on. I am not sure why Microsoft chooses to turn this of, but it is rare I do not use Option Strict when using VB.


    Source Control

    The main option with Source Control is choosing your source control plug in.


    This is necessary if you are using something other than Team Foundation Server. In Visual Studio 2013, the only other built in option is Git. There is one other setting that you sometimes have to use here. If you are set up to use a proxy server, there is an option to use a proxy server for file downloads.

    Text Editor

    One option I always set here is on All Languages. I used to make sure Line numbers was set here for everything, but almost everything includes line numbers.



    There is a nice feature under Debugging called Symbols. While you rarely have to use this in day to day operations, this option allows you to download the .pdb, or program database, files so you can debug into the .NET framework code. This was released in the Visual Studio 2005 timeframe, if I remember correctly, and I actually caught a bug in the framework using these symbols. Someone had already logged the bug and I found a hotfix, but it certainly saved some time for the team on developing.


    To use this, you click on the checkbox and specify a folder. You can also add your own symbol cache in your organization to debug code that is published from other teams by clicking on the folder icon above the locations box.


    On a note similar to symbols is the Package Manager options. If you are using nuGet in your organization, you will want to look at the ability to add your own package source.


    Click on the plus sign and add the repository here.


    That pretty much covers the options I have used with any regularity. A few are a bit obscure, like the symbols or Package Manager settings, but there are some nice ones you should find useful.

    Peace and Grace,

    Twitter: @gbworld