Tools for Agile Development presentation materials

by Mike Linnen 17. May 2009 18:19

In this post you will find my PowerPoint and source code I used for my presentation at Charlotte Alt.Net May meeting.  I had a good time presenting this to the group even though it was very broad and shallow.  I covered the basis on why you want to leverage tools and practices in a Lean Agile environment.  I got into topics like Source Control, Unit Testing, Mocking, Continuous Integration and Automated UI Testing.  Each of these topics could have been an entire 1 hour presentation on its own. 

Here are the links to the tools that I talked about in the presentation:

Power Point “Tools for Agile Development: A Developer’s Perspective” http://www.protosystem.net/downloads/ToolsForAgileCharlotteAlt.Net/ToolsForAgile.ppt

NerdDinner solution with MSTests re-written as NUnit Tests and WatiN Automated UI Tests http://www.protosystem.net/downloads/ToolsForAgileCharlotteAlt.Net/NerdDinner_ToolsForAgileDev.zip

CI Factory modified solution that I used for creating a CI Build from scratch http://www.protosystem.net/downloads/ToolsForAgileCharlotteAlt.Net/CIFactory_ToolsForAgileDev.zip

Using PowerShell in the build process

by Mike Linnen 8. April 2009 15:37

I have used NAnt and MSBuild for years on many projects and I always thought there has to be a better way to script build processes.  Well I took a look at PowerShell and psake and so far I like it.  psake is a PowerShell script that makes breaking up your build script into target tasks very easy.  These tasks can also have dependencies on other tasks.  This allows you to call into the build script requesting a specific task to be built and have the dependant tasks get executed first.  This concept is not anything new to build frameworks but it is a great starting point to use the goodness of PowerShell in a build environment.

You can get psake from the Google Code repository.  I first tried the download link for v0.21 but I had some problems getting it to run my tasks so I went directly to the source and grabbed the tip version (version r27 at the time) of psake.ps1 and my problems went away. 

You can start off by using the default.ps1 script as a basis for your build process.  For a simple build process that I wanted to have for some of my small projects I wanted to be able to do the following:

  • “Clean”the local directory
  • “Compile” the VS 2008 Solution
  • “Test” the nunit tests
  • “Package” the results into a zip for easy xcopy deployment

Here is what I ended up with as a starting point for my default.ps1.

image

This really doesn't do anything so far except set up some properties for paths and define the target tasks I want to support.  The psake.ps1 script assumes your build script is named default.ps1 unless you pass in another script name as an argument.  Also since the task default is defined in my build script if I don't pass in a target task then the default task is executed which I have set as Test.

Build invoked without any target task:

image

Build invoked with the target task Package specified:

image

So now I have the shell of my build so lets get it to compile my Visual Studio 2008 solution.  All I have to do is add the code to the Compile task to launch VS 2008 passing in some command line options.

image

And here it is in action:

image

Notice I had to pipe the result of the command line call to “out-null”.  If I didn't do this the call to VS 2008 would run in the background and control would be passed back to my PowerShell script immediately.  I want to be sure that my build script would wait for the compile to complete before it would continue on. 

What about if the compile fails?  As it is right now the build script does not detect that the compile completed successfully or not.  VS 2008 (and previous versions of VS) return an exit code that defines if the compile was successful or not.  If the exit code = 0 then you can assume it was successful.  So all we need to do is test the exit code after the call to VS 2008.  PowerShell makes this easy with the $LastExitCode variable.  Throwing an exception in a task is detected by the psake.ps1 script and stops the build for you.

image

I placed a syntax error in a source file and when I call the Test target the Compile target fails and the Test target never executes:

image

Now I want to add in the ability to get the latest code from my source control repository.  Here is were I wanted the ability to support multiple solutions for different source control repositories like Subversion or SourceGear Vault.  But lets get it to work first with Subversion and then later refactor it to support other repositories.  For starters lets simply add the support for getting latest code in the Compile task.

image

As you can see right now this is very procedural and could certainly use some refactoring, but lets get it to work first and then worry about refactoring.  Here it is in action:

image

As I mentioned before I want to be able to support multiple source control solutions.  The idea here is something similar to what CI Factory uses.  In CI Factory you have what is known as a Package.  A Package is nothing more than an implementation of a build script problem for a given product.  For example you might have a source control package that uses Subversion and another source control package that uses SourceGear Vault.  You simply include the package you want for the source control product that you are using.  Psake also allows for you to include external scripts in your build process.  Here is how we would change what we have right now to support multiple source control solutions.

So I created a Packages folder under the current folder that my psake.ps1 script resides. I then created a file called SourceControl.SVN.ps1 in the Packages folder that looked like the following:

image

In the default.ps1 script Compile task I replaced the source control get latest code (told you I was going to refactor it) with a call to the SourceControl.GetLatest function (Line #20).  I also added a call to the psake include function (Line #10) passing in the following “Packages\SourceControl.SVN.ps1”.  Here is what the default.ps1 looks like now:

image

So if I wanted to support SourceGear Vault I would simply create another package file called SourceControl.Vault.ps1 and place the implementation inside the GetLatest function and change the include statement in the default.ps1 script to reference the vault version of source control.  I plan on adding in support for my Unit Tests the same way I did the source control, that way I can easily have support for multiple unit testing frameworks.

Conclusion

As you can see it is pretty easy to use PowerShell to replace your build process.  This post was just a short introduction on how you might get started and end that crazy XML syntax that has been used for so long in build scripting.  I have a lot more to do on this to make it actually usable for some of my small projects but hopefully I can evolve it into something that will be easy to maintain and reliable.  All in all I think PowerShell has some pretty cool ways of scripting some nice build solutions. 

Adding Twitter Notifications to your build

by Mike Linnen 10. March 2009 21:01

I added twitter posts to the FIRST FRC Field Management System, so that interested parties could get the results of a match in near real time.  Since twitter is focused around sending small messages I thought it would be a great mechanism to notify team members when the status of the build changes.  Most build solutions have a way already to do this, but they come in the form of an email or a custom program that sits in your tray waiting to notify you.  Twitter messages on the other hand can be consumed many different ways (web, twitter client, cell phone etc).  This gives great flexibility on how each team member decides on how he/she want to monitor the build process.  In this blog post I will show you how you can add twitter build notifications to a build process.

First you should get a twitter account so you can tell your team members what account they should follow to get the notifications.  You might want to set up your twitter account as private so you can manage who is allowed to follow.  Also this brings up a good point as you should not send any sensitive data in your build message tweet because the messages are sent across the wire and anyone can intercept them.

Next go get the Yedda Twitter C# Library.  This is a C# wrapper around the Twitter API.  It is very easy to use.  You can use the binary from the project or use the Twitter class that is part of the project.

All build processes that I have used (TFS, NANT, CCNET, and MSBUILD) allow for command line applications to be called from the build script.  So we will use the Twitter.cs class found in the Yedda C# Library in a console application to expose it's capabilities of sending twitter updates.  Go ahead and create the Console application and add the Twitter.cs class to it.  Then in the Program.cs Main method write some code to parse a few command line options to pass along to the Twitter,Update method. 

image

Example command line call to the executable:

tc -user twitterUserName -password twitterPassword -message "Build 1.4.5.1 Failed to compile"

Example tweet generated from the above command line:

image

Now all you have to do is put the new console executable in a place on your build box that is accessible by the automated build and change your build script to call it with the right message.  You can make the tweet a little more informative as to why the build failed, or you can have the build tweet at certain key points of the process so you know exactly what step the build is on.  Be creative but don't send too many messages or the team members will soon ignore all build tweets as they end up being annoying.

Possibilities for improvement

  • You could make a twitter client that monitors the build tweets and it parses the message from the build and reacts differently based on if the build failed on a compiler error or a unit test.  Maybe some static analysis failed but it isn't severe enough to grant immediate attention.  The client might attempt to grab the team members attention more if the severity of the message is high enough.
  • What about a twitter client that parses the messages and controls a traffic red light.  Green is build passed.  Red is build failed. Yellow is unit tests failed.   

TwitterBuildNotification.zip (6.46 kb)

TFS Build reports partial fail even when all tests passed

by Mike Linnen 8. January 2009 09:33

I ran into a strange issue today when I was trying to figure out why my TFS Build was reporting that the build was partially successful even though every test was passing.  The normal build report really did not give any good reason why it was partially successful other than the fact that it was something related to the unit tests (I am using MS Test in this case).  So I cracked open the build log and peeled through the entries.  I noticed that when the code coverage was attempting to instrument the assemblies it reported that several of the assemblies could not be located.  Then I remembered I did some refactoring and I renamed and consolidated some assemblies. 

Well that should be an easy fix all I had to do was remove these assemblies from the test run config in the Code Coverage section.  So I opened up the LocalTestRun.testrunconfig file in Visual Studio 2008 and selected the Code Coverage section to make my changes.  As soon as I did this the config editor closed down (crashed).  Wow that was weird I never saw that before.  Hmmm I wonder what it could be.  Well here is what I did to try and locate the issue.

  1. Perhaps the Test Run Config file needs to be checked out of source control for write access.  Nope that wasn't it.
  2. Well if I cant edit it in VS 2008 then I might as well try notepad.  I removed the offending assemblies using notepad in the LocalTestRun.testrunconfig.  However once I opened up the Test Run Config editor and selected the Code Coverage the editor still crashed.
  3. Perhaps I malformed the Test Run Config xml file.  So I opened it up again in notepad and the XML looked fine.  Besides if this XML was malformed I don't think the Test Run Config editor would not open at all.
  4. Consult almighty search engine.  Wow look what I found http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=391255 and it was only reported 2 days ago.

So to be sure that I got the Test Run Config file right I removed my Database project from my solution made my edits for Code Coverage in the Test Run Config editor, then added the database project back into the solution. 

After fixing the Test Run Config file my build ran successfully.

About the author

Mike Linnen

Software Engineer specializing in Microsoft Technologies

Month List