No need to fear branching

Something that I have noticed at a number of companies is there is a real fear that working with branch's is hard. Sure most of us have been bitten by working on a branch that is out of sync with its parent and has not been reverse integrated on a regular basis, and then when it comes time to merge the changes to your main line the experience can be awful. But is this experience any different to that of the developer that refuses to update their workspace on a regular basis? If you apply the same rules, but obviously not regularity, as you do in your own workspace of the regular updates then things can go very smoothly. Combine these good work habits with the work that Microsoft have done in TFS 2010 with branching and merging visualizations, and life becomes a lot easier. 


In a later post I will talk about a consistent way to structure your source that makes the setup time of any branch and its associated automated build infrastructure minimal. In the meantime I have posted a link to an excellent article on branching that is well worth a read InfoQ: Version Control for Multiple Agile Teams.

Automated testing of PowerShell

I have been expanding my library of PowerShell build scripts that I use for my work, and as such I want to ensure that they keep working as I expect them too. The obvious answer is automated tests but it was a case of how. I spent some time trying out PSUnit but to be honest I found it a bit hard, possibly just because I was unfamiliar with the framework. After a bit of digging here is the solution that I now use, and to make it harder I was using Visual Studio Express 2010.

Tools

• Visual Studio 2010 C# Express
• NUnit 2.5
• PowerShell 2 

Setup

I have a solution that contains two projects, one with my PowerShell scripts and the other with my tests just to keep things clean.

Scripts project

My PowerShell scripts are all part of a module so for my integration tests I install this module in the user directory. I am just using a build event to do this


rmdir %USERPROFILE%\Documents\WindowsPowerShell\modules\DevPipeline\ /s /q
mkdir %USERPROFILE%\Documents\WindowsPowerShell\modules\DevPipeline\
xcopy $(ProjectDir)\PowerShellModule %USERPROFILE%\Documents\windowspowershell\modules\DevPipeline

Tests project

To run tests in Visual Studio express I use the following work around after setting the project to be a Console Application rather than a library.



And then to run the command for my test I use the following class



Integration Tests


As I mentioned above I am treating these tests as integration tests and I import the module as part of the setup.

An example of the integration tests is below

Building VS2010 projects from TFS 2005/2008

An issue that I have now come across a couple of times is the ability to still use an older version TFS to build .NET 4 projects/solutions.

The solution that I have used is to to override the standard build target and call the correct version of MSBuild.exe using the Exec task.