Keeping Automated Builds DRY
This is not the first time I came back to automated builds and re-evaluate how they are done. This time, I wanted to capture several things at the same time:
1. Specifications and Integration tests have to reside within the same project with the SUT, so that there's no need to maintain 2 separate projects structures and keep them in sync.
2. Ensure that visually we be determined if a class has Specifications or/and Integration tests (SomeClass.cs, SomeClass_Specs.cs, and SomeClass_Integration.cs)
3. Reuse the existing scripts generated by VS.NET for us
The last point is the key. Since VS.NET 2008 project files are actually MSBuild scripts. Good or bad, that's not important. What is important is that information about project and how to compile it already exists and we should be able to re-use it and not re-invent the wheel.
NAntContrib has MSBuild task. Sadly, it says that parameter is the solution file. In reality, it can be just a single project file, after all, it's just an MSBuild script. By running this task on an MSBuild file we can get all the work done for us. What we missing, is the ability to filter out Specs and Integration tests when we don't need those.
What would it look like? Example:
build –D: build.production.deployment=false
would compile all the specs/integ. Tests into the assembly
build –D: build.production.deployment=true
would not compile all the specs/integ. Tests into the assembly
How this would be done?
In nant script we would have something like this:
1: <target name="compile.app" depends="prep">
2: <msbuild project="${app.proj}">
3: <property name="Configuration" value="${build.configuration}"/>
4: <property name="OutputPath" value="${app.compile.dir}"/>
5: <property name="ProductionDeployment" value="${build.production.deployment}"/>
6: </msbuild>
7: </target>
In project file, we would have to “filter” things that are not always will go into assembly in msbuild fashion:
1: <ItemGroup>
2: <Compile Condition="$(ProductionDeployment) == 'false' " Include="**\*_Specs.cs" />
3: <Compile Condition="$(ProductionDeployment) == 'false' " Include="**\*_Integration.cs" />
4: <Compile Condition="$(ProductionDeployment) == 'false' " Include="**\Infrastructure\Testing\*.cs" />
5: <Compile Include="Properties\AssemblyInfo.cs" />
6: <Compile Include="SomeComponent.cs" />
7: <Compile Include="IContract.cs" />
8: </ItemGroup>
This would allow Visual Studio .NET to show the files, but have a conditional compiling. Reference would follow the same route (at this point they are always copied, but the result assembly is not referencing them if we set ProductionDeployment to true), I still have to figure out how to express that properly. Not sure how to apply same condition on the <Reference> elements. Ideas?
Bottom line - nant, rake, powershell, msbuild - it's all good. What is missed is the fact that we have assets we can take advantage, and not redo things that already there.