Code Reviews with Visual Studio

Code Reviews with Visual Studio

 

Code reviews are one of the most important development practices to improves quality, reduces bugs, and knowledge sharing.   Here is how to perform Code Reviews with Visual Studio.

In order to use code reviews with Visual Studio, you must be using TFVS (Team Foundation Version Control) within Visual Studio Online or Team Foundation

Request Code Review

Before you commit your changes, in the team explorer go to the My Work section.  Create your code review request by specifying the reviewer (who you want to perform the code review), title, area path, and description.

Code Reviews with Visual Studio

 

Code Reviews with Visual Studio

 

After submitting the code review request, you can suspend your current work while you wait for feedback from the code reviewer.  This allows you to begin work on another product backlog item.

Code Reviews with Visual Studio

 

Perform Code Review

Once a code review request has been sent to you, you can see it from the My Work section.

Code Reviews with Visual Studio

 

Opening the code review will show you the files modified so you can review with the standard diff view.  You can add comments to each file change to let the author know of any suggested changes.

Code Reviews with Visual Studio

 

Resume Work and Review Feedback

Once your code has been reviewed, you can resume your suspended work and view the feedback from the code reviewer.

Code Reviews with Visual Studio

 

Code Reviews with Visual Studio

 

Get Notified!

Once you start using the above workflow, you may want to get notified via email when someone sends you a code review request.  To do so from Visual Studio, in the Team Explorer access the Settings section.

Code Reviews with Visual Studio

 

This will open up Visual Studio online in your browser where you can manage your basic alerts.

Code Reviews with Visual Studio

 

 

 

Read More

Add a build number to your Assembly Version

TeamCity

Including the build number in your assembly version number can be a very useful feature.  Using reflection you can retrieve you assembly version number and display it appropriately in your app. Here is how to add a build number to your Assembly Version using TeamCity continuous integration server.

AssemblyInfo Patcher

TeamCity is a continuous integration server developed by JetBrains.  If you are looking at trying a new build server, I highly recommend giving it a try.   It should take no longer than a hour or two to install, configure, and build your project.

There is a built-in build feature that allows you to modify the AssemblyInfo.cs during the build process.  This feature works by scanning for all AssemblyInfo files (.cs, .vb, .cpp, .fs) in their usual file locations and replaces the AssemblyVersion, AssemblyFileVersion and AssemblyInformationVersion attributes with the values you define.

 Add Build Feature

Under your build configuration settings, add a new Build Feature.

TeamCity

Select the AssemblyInfo patcher.  Here you will be able to specify the version format by using parameters or static text.  In my example below, I’m including the %build.counter% parameter in the version format.

TeamCity

 

That’s it!  After the build is complete, the assembly outputted now contains the file version with build number.

TeamCity

Read More

Visual Studio Online Check-In Policies

Visual Studio Online Check-In Policies

Want to produce better code and more efficient development group? Start using Visual Studio Online check-in policies within your team project.

Check-in Policies are rules you can define at a Visual Studio Online team project which are enforced when a developer attempts to check-in their source code.

Note: You must be using Team Foundation Version Control (TFVC) with your project in order to use the check-in policies.  Although VSO now supports Git as a version control system for your team project, check-in policies are not supported.

One of the main reasons I started using check-in policies was to enforce associated work items to a changeset.  Having all changsets associated to work enabled me to automate the creation of a change lot during the build process.  If you are looking for better way to visualize your Visual Studio Online work items, take a look at my LeanKit Visual Studio Online Integration blog post.

Source Control Settings

From the Team Explorer, access the settings menu and select Source Control under the Team Project heading.

Visual Studio Online Check-In Policies

 

Under the Check-in Policy tab, click the Add button to select the policy you want to add.

Visual Studio Online Check-In Policies

Without any extension or power tools, Visual Studio Online provides four team project check-in policies that you can specify:

Builds
Requires that the latest build was successful for each affected continuous integration build definition.

Changeset Comments Policy
Requires the developer to provide comments with the check-in.  These comments will be associated with the changeset.

Code Analysis
Requires the developer to run Code Analysis from Visual Studio prior to check-in.

Work Items
Requires the developer to associate at least one work item with the check- in.

Code Review Policy

There is a great policy written by Colin Dembovsky (@colindembovsky) on Visual Studio Gallery that provides Code Review Policy.

Once the extension is installed you will now have a new option available to add.

Visual Studio Online Check-In Policies

Visual Studio Online Check-In Policies

 

Once this policy is added, you will be unable to check-in until a Code Review has been requested, closed, and has no “Needs Work” response.

CheckIn5

Read More

Integrate LeanKit and Visual Studio Online

Integrate LeanKit and Visual Studio Online

LeanKit and Visual Studio Online are both two great tools.  Why not use them both?  Here is a guide to integrate LeanKit and Visual Studio Online.

Although Visual Studio Online (and Team Foundation Server) provide a task board  to visualize work items and flow, I prefer to use the fully customized Kanban board by LeanKit.  Thankfully, I found out that LeanKit has created an Integration Service, which is available on GitHub.

My goal is to manage all work items within LeanKit, however I want to be able to associate Visual Studio Online Work Items to changesets (during checking) within Visual Studio.  (LeanKit/VSO ChangeLog how-to coming soon!)

Overall the installation and configuration is fairly straightforward. However, there were a couple hiccups I encountered along the way that inspired this how-to.  I also wanted to point out that main contributor to the integration service, David Neal (@reverentgeek), was very helpful in answering questions via Twitter.  Check out the source code if you’re interested, pretty nice code.

Integration Service Installation

  1. Download the latest zip/executables from LeanKit’s website here.
  2. Follow the installation guide provided by LeanKit.

Although LeanKit provides a bit of an overview on the configuration, follow these steps specifically for connecting to Visual Studio online (or Team Foundation Server).

Visual Studio  Online – Alternate Authentication Credentials

Before you configure the integration service, you must enable alternate authentication credentials to your Visual Studio account profile.  This allows you to specify a username/password the integration service can use to connect to Visual Studio Online Web Service.

When in Visual Studio Online, access your account profile to enable the alternate authentication credentials.

VSO Alternate Authentication Creds

 LeanKit – Board Settings

In your LeanKit board settings, go to the Card ID Settings section.  Here you will want to make sure that you are using the external card ID.  Do not select the auto-increment card ID setting because we want the Card ID to be the same as the Visual Studio Online Work Item #.

LeanKit Card ID Settings

Configure Integration Service

After installation, browse to http://localhost:8090 to access the web interface.  Specify your LeanKit account and credentials.

LeanKit Integration

Next, specify your Visual Studio Online account and alternate access credentials.

LeanKit Integration

The integration service is very configurable in terms of mapping LeanKit Cards to VSO Work Items and different status.  Select the LeanKit board and the Visual Studio Online Project you would like to create a mapping for.

LeanKit Integration Mapping

In the Selection tab, you will want to select the VSO Work Item States and Types that will be mapped to LeanKit.

LeanKit Mapping

The Lanes and States tab will be populated with the swim lanes and columns from your Kanban board.  Select a column or lane and then select an available state to map.  The intent here is to specify if the LeanKit card moves to that column/lane it will be updated in VSO with the mapped State.  If you define multiple states, only the first matching state will be used.

In the example below, I’ve mapped the Backlog column  to the New and To Do VSO states.

LeanKitVSO-Step5

In the Card Type tab, specify which LeanKit card types you want to map to which VSO Work Items.

LeanKit Integration Card Types

In the Options tab, specify how you want the integration service to sync.  It can sync changes bi-directional, however for my usage, I only want to push changes from LeanKit to VSO.  As mentioned above, I only want to use LeanKit for managing work items, however I want them to be in VSO so I can associate work items to changesets.

LeanKit Integration Options

Be sure to click the save button if you haven’t already.  What may not be obvious at this point is that you need to Activate your new configuration.  Click on the Activation tab, then click on the big red Activate Now button.

LeanKit Integration Activate

That’s it!

I’ve created a LeanKit Defect Card in my Product Backlog and the Integration Service has created the Bug work item in VSO.

LeanKit Test

LeanKit Test

Read More

CAP Theorem, CQRS and Eventually Consistent

First, if you haven’t heard of Eric Brewer’s CAP theorem, it basically states that you can must choose two of three:

  • Consistency
  • Availability
  • Partition Tolerance

CQRS doesn’t solve CAP issues, however it allows you to decide independently what is important on both read and write side.

For example, you could assume a systems would be ACID (Atomic, Consistent, Isolated, Durable) compliant on the write/domain site and BASE (Basic Availability, Soft-State, Eventually Consistent) on the read side.

Eventual consistency is something that requires a change of mindset.  Because of our heavy use in ACID compliant databases, thinking about possibly having stale data blows our mind.

There are two important points about I want to make about eventually consistent data.

  • The data isn’t wrong.  It’s old.  There is a big difference here.  The data you may be consuming may not be up-to-date, however it was correct at one point in time.
  • In the real world, we use stale data all the time.

A good example, from Greg Young, was if you read the newspaper/website and notice some statistics on the unemployment rate, this is obviously stale data.  If those stats were a a week old, would this matter?  How much of a difference would a week make to unemployment rate?  Probably not much. However, there are scenarios where you want to be much closer to actual, and in these cases define an SLA.

The point is, in many situations, eventually consistent data is acceptable.

Read More

TDD with Startups and Prototypes

I was watching an old video of Jim Coplien and Uncle Bob debating TDD (and other things). Uncle Bob said:

Nowadays it is irresponsible for a developer to ship a line of code he has not executed in a unit test.

At first, I did not agree with this statement.  But after reviewing it a few times, there is a keyword here that is very important:  SHIP.

A code base with a test suite that provides great coverage is useless if it does not ship.

How quickly can you get out a prototype or MVP if you are using TDD?  Would you not be better off getting a MVP out in the wild as quick as possible? Then harden it with tests AFTER you start to develop a customer base?

Never underestimate the value of a shipped software providing value to customers.

Read More

Greg Young: 8 Lines of Code

Greg Young gave a good talk titled 8 Lines of Code, discussing simplicity, dependencies, and magic.

Magic is always something I try and identify and stay away from in my own code, however I really failed to realize how much magic goes on in some of the libraries/frameworks that I often use.  Entity Framework and nHibernate come to mind.  You really should understand the magic happening in these libraries to use them.  Which is very problematic.

If you take the dependency ownership seriously, then a lot of folks developing the front-end of a “modern” web applications are in a world of hurt.  RequireJS, Knockout.js, jQuery, Bootstrap, etc, etc, etc…

Video is posted on InfoQ:

http://www.infoq.com/presentations/8-lines-code-refactoring

Read More

Microsoft Fakes (formerly Moles)

Problem: You are writing unit tests that involve a dependency on a 3rd party concrete class. Unfortunately there are no interfaces, nor are the methods/properties defined as virtual.

Solution: Microsoft Fakes (formerly Moles)

Microsoft Fakes help you isolate the code you are testing by replacing other parts of the application with stubs or shims. These are small pieces of code that are under the control of your tests. By isolating your code for testing, you know that if the test fails, the cause is there and not somewhere else. Stubs and shims also let you test your code even if other parts of your application are not working yet.

Example:

[code lang=”csharp”]

// Code under test:
public int GetTheCurrentYear()
{
return DateTime.Now.Year;
}

[TestClass]
public class TestClass1
{
[TestMethod]
public void TestCurrentYear()
{
int fixedYear = 2000;

// Shims can be used only in a ShimsContext:
using (ShimsContext.Create())
{
// Arrange:
// Shim DateTime.Now to return a fixed date:
System.Fakes.ShimDateTime.NowGet =
() =>
{ return new DateTime(fixedYear, 1, 1); };

// Instantiate the component under test:
var componentUnderTest = new MyComponent();

// Act:
int year = componentUnderTest.GetTheCurrentYear();

// Assert:
// This will always be true if the component is working:
Assert.AreEqual(fixedYear, year);
}
}
}
[/code]

Read More