views:

50

answers:

1

Having just spent a frustrating amount of time configuring an automated build with psake the thought occurred to me why not use the language I know best to create a builder?

psake is an excellent framework to create an automated build. The trouble I always have is learning powershell to run more complex tasks. I'm sure the same can be said for NAnt, msbuild, etc.

My idea to solve this problem is create the build system for a given solution in .Net. The basic structure of the process would be this:

build.bat

rem // Set the environment for msbuild.
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat"

rem // Build the solution's builder.
msbuild.exe buildsolution.csproj

rem // Run the solution's builder.
BuildSolution.exe <task>

Project's BuildSolution

A tiny console application that:

  • References the BuildSolution framework.
  • Includes a method for each task. eg:
    • Clean
    • Build
    • Test
    • Commit
  • Registers the tasks, and their dependencies, it can run. eg:
    • Builder.RegisterTask( x => x.Clean )
    • Builder.RegisterTask( x => x.Build ).DependsOn( x => x.Clean )
    • Builder.RegisterTask( x => x.Test ).DependsOn( x => x.Build )
    • Builder.RegisterTask( x => x.Commit ).DependsOn( x => x.Test )
  • Runs the builder. eg Builder.Execute()

Test Task

Ultimately the test task will call nunit, mstest, xunit, etc but first builds the required command line. This is an example of where using .Net instead of PowerShell is a winner for me.

When I develop my applications I follow a simple naming convention of ProjectName and ProjectName.Tests. The build system searches for *.Tests.dll and includes them in the mstest command line.

The advantages of using a .Net application to construct this task is:

  • No need to learn a scripting language to find test dlls.
  • Develop with an IDE I know well and is feature rich.
  • Debug the task with an IDE I know well and is feature rich.

Summary

In addition to the advantages listed in Test Task the BuildSolution idea has the advantage that it is arguably easy for new developers to the project to understand and edit the build system.

What cons do you see for the idea of BuildSolution?

+4  A: 

From what I can tell, you're talking about rolling your own solution. I will compare this to using someone else's existing solution.

Pros:

  • It is small
  • It is simple to learn
  • It is simple to debug
  • It is easy to introduce a bug fix
  • You don't have to ask to get new features in

Cons:

  • You re-invented the wheel (this always adds cost. Whether that is as much cost is up to you to evaluate)
  • You can't hire people who already know your build system
  • You have to implement your own bug fixes (yes, you will have bugs), and can't let someone outside the company take care of it, without paying them
  • You can google your bugs on the web, because no one knows you have them
  • If it is shared across any number of teams, then you have to turn it into a real project, with milestones, backlog, bug database, etc.
  • If you decide not to make it into a central project, you duplicate code. Bug fixes will not transfer across the different copies of the code.
  • You're missing tons of features from existing build systems (e.g. integration into your IDE or other software, monitoring, built-in reporting, built in health notifications, lab management, etc)
  • You can't google if someone knows how to integrate product X into your solution, without doing extra work on your end (i.e. coding up a new feature)

Ultimately you should try to add any of your own pros and cons that you can think of. Especially consider the business standpoint. Cost both solutions in hours/dollars. Use whichever costs less in the long run, or use a hybrid approach (one in the short term, the other in the long term, and make a plan and schedule for migration).

That being said, I've rolled my own on more than one team, for more than one type of problem. I've also migrated from rolling my own to using someone else's product. I've found it to be valuable, and I think it can be the right solution in some situations, especially if you use it as a somewhat short term bootstrap.

Merlyn Morgan-Graham
Aggreed. Have you looked at CruiseControl.net?
Decker97
Excellent answer. You've hit the nail on the head that the overriding factor is the cost to the business for with either solution and without knowing that is what started my thinking on the idea. I had just spent far too long learning the required powershell commands thought there had to be a better way.
Tim Murphy
@Tim: Requirements grow, though. Once I had implemented my in-house tools, and used them in production for a project or two, I got very good idea of their abilities and pitfalls. When I went looking for replacements (instead of adding much larger feature sets to my tools), it was very easy for me to determine which features I cared about, and which I didn't. I was much better equipped to see the value of features my tools didn't have, and to quickly adopt them.
Merlyn Morgan-Graham