Nightly Build is a Warning (or Horror)

Photo credits: insidethemagic

I think, Nightly build is an anti-pattern for Continuous Integration. If you are integrating continuously, then you shouldn't need a nightly build, that would be too discrete :(

If you already have a per-commit continuous integration setup, you shouldn't need the so called nightly build unless there's something bad about the code.

Often times, builds taking >10 minutes are put in the bucket of nightly builds.
Some people put batch processing related tests under such nightly builds. A colleague told me they used nightly build to clean up resources (disk space, recreate the database etc.) on a nightly build - to ensure the apps worked fine on a fresh state.

Under most circumstances, a nighly build means something long running. That in itself can be an indication of poor performance.

But what I have seen is, when such nightly builds are broken - they are rarely looked after or cared for. Because, first thing in the morning, who the hell wants to look at that broken nightly build? Even if someone takes a look, since its long running, it might well eat up all morning to actually try/fix/commit changes and see it go green again! Since it takes longer to make the build green, people keep delaying it for later... meaning

it becomes generally acceptable to let the nightly build stay in RED. 

And once people get used the redness of the nightly build, they start ignoring it, inevitably.

So, here's what I would do:

Avoid nightly builds altogether.
Avoid nightly builds altogether.
Avoid nightly builds altogether.
Otherwise, make one person from the team responsible for the build (rotate people).

CruiseControl.Net (CCNet) configuration example for NCover

CruiseControl.Net is a great continuous integration tool for .Net projects. It not only continuously builds your software but provides some really helpful reports to monitor your project's progress.

In agile world, we all speak of self-testing code or test driven development (TDD). If we really want to ensure our code has enough test coverage, we need to use some tool to ease our lives and NCover is a good one for this purpose. To learn more about NCover, please visit this.

When integrating to CCNet, you can use a similar configuration in ccnet.config as shown below to show NCover reports for your project-

\par ?? <\cf3 msbuild\cf1 >\par ?? <\cf3 executable\cf1 >\cf0 C:\\WINDOWS\\Microsoft.NET\\Framework\\v3.5\\MSBuild.exe\cf1 \par ?? <\cf3 projectFile\cf1 >\cf0 CISample.sln\cf1 \par ?? <\cf3 buildArgs\cf1 >\cf0 /p:Configuration=Debug\cf1 \par ?? <\cf3 targets\cf1 >\cf0 Rebuild\cf1 \par ?? <\cf3 timeout\cf1 >\cf0 300\cf1 \par ?? <\cf3 logger\cf1 >\cf0 C:\\Program Files\\CruiseControl.NET\\server\\ThoughtWorks.CruiseControl.MsBuild.dll\cf1 \par ?? \par ??\par ?? \par ?? <\cf3 nunit\cf1 >\par ?? <\cf3 path\cf1 >\cf0 C:\\Program Files\\NUnit 2.4.1\\bin\\nunit-console.exe\cf1 \par ?? <\cf3 assemblies\cf1 >\par ?? <\cf3 assembly\cf1 >\cf0 CISample\\bin\\Debug\\CISample.dll\cf1 \par ?? \par ?? \par ??\par ?? \par ?? <\cf3 exec\cf1 >\par ?? <\cf3 executable\cf1 >\cf0 ncover.console.exe\cf1 \par ?? <\cf3 baseDirectory\cf1 >\cf0 CISample\\bin\\Debug\\\cf1 \par ?? <\cf3 buildArgs\cf1 >\cf0 nunit-console CISample.dll //xml coverage.xml //ea NUnit.Framework.TestFixtureAttribute\cf1 \par ?? \par ??\par ?? \par ?? <\cf3 exec\cf1 >\par ?? <\cf3 executable\cf1 >\cf0 NCoverExplorer.Console.exe\cf1 \par ?? <\cf3 baseDirectory\cf1 >\cf0 CISample\\bin\\Debug\\\cf1 \par ?? <\cf3 buildArgs\cf1 >\cf0 coverage.xml /xml /r:ModuleMethodFunctionSummary\cf1 \par ?? \par ??\par ?? } -->

10 <tasks>

11 <!-- Task for MSBuild -->

12 <msbuild>

13 <executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>

14 <projectFile>CISample.sln</projectFile>

15 <buildArgs>/p:Configuration=Debug</buildArgs>

16 <targets>Rebuild</targets>

17 <timeout>300</timeout>

18 <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>

19 </msbuild>

20

21 <!-- Task for NUnit -->

22 <nunit>

23 <path>C:\Program Files\NUnit 2.4.1\bin\nunit-console.exe</path>

24 <assemblies>

25 <assembly>CISample\bin\Debug\CISample.dll</assembly>

26 </assemblies>

27 </nunit>

28

29 <!-- Task for NCover -->

30 <exec>

31 <executable>ncover.console.exe</executable>

32 <baseDirectory>CISample\bin\Debug\</baseDirectory>

33 <buildArgs>nunit-console CISample.dll //xml coverage.xml //ea NUnit.Framework.TestFixtureAttribute</buildArgs>

34 </exec>

35

36 <!-- Task for NCoverExplorer -->

37 <exec>

38 <executable>NCoverExplorer.Console.exe</executable>

39 <baseDirectory>CISample\bin\Debug\</baseDirectory>

40 <buildArgs>coverage.xml /xml /r:ModuleMethodFunctionSummary</buildArgs>

41 </exec>

42

43 </tasks>

You see that there are two NCover related <exec> nodes. The first one generates the coverage.xml. Then using this first one you can create actual report to present specifying the desired level of details of the report.