To simplify the use of our build scripts, and to make it easier for someone new to the project to work out how things work, we’ll create some convenience PowerShell scripts to launch the build. We’ll create three scripts, for three different purposes: one for moment to moment use by a local developer; one to do a release build when the project is ready for distribution; and one for our continuous integration server.

The Integration Build

Our script - imaginatively called integration-build.ps1 will be used by a local developer to do a cross check that the build is sound. This build needs to run as quickly as possible and provide immediately actionable feedback to the developer.

$here = Split-Path -parent $MyInvocation.MyCommand.Definition
$psakePath = Resolve-Path $here\packages\psake*
Import-Module $psakePath\tools\psake.psm1
invoke-psake $here/build.ps1 -Task Integration.Build

After defining $here as the folder in which the script is found, the path to Psake is found and stored as $psakePath. The Psake PowerShell module is imported and then used to trigger the build. Doing it this way ensures the build will run even on machines that don’t have Psake installed for global use by PowerShell.

The actual definition of what is involved in an integration build is deferred into the build script itself:

Task Integration.Build -Depends Debug.Build, Unit.Tests

Unlike other Psake tasks that we’ve used, this one has no block of commands to execute, just a list of dependencies.

The Formal Build

The formal-build.ps1 script will be used when the project is ready for a formal release. Typically, such a script will do more work than the integration script as it will do things (such as building NuGet packages or installers) that aren’t normally required by a local developer.

$here = Split-Path -parent $MyInvocation.MyCommand.Definition
$psakePath = Resolve-Path $here\packages\psake*
Import-Module $psakePath\tools\psake.psm1
invoke-psake $here/build.ps1 -Task Formal.Build

The only difference here is the use of Formal.Build as the target for Psake:

Task Formal.Build -Depends Release.Build, Unit.Tests

At the moment, this is trivially similar to the Integration.Build task, but this will change as we extend our automation on this project.

The Continuous Integration Build

For use on a continuous build machine, our ci-build.ps1 script will trigger on every commit, compiling the code and running all the tests to ensure that the build hasn’t been broken.

Having a continuous integration build like this serves as a backstop for the developers, ensuring that the codebase stays sound and reliable even if shortcuts are taken.

You’ll notice that the script is almost identical to those shown above, with the only difference being the chosen target task:

$here = Split-Path -parent $MyInvocation.MyCommand.Definition
$psakePath = Resolve-Path $here\packages\psake*
Import-Module $psakePath\tools\psake.psm1
invoke-psake $here/build.ps1 -Task CI.Build

And, for now, our target is the same as the Integration.Build:

Task CI.Build -Depends Debug.Build, Unit.Tests

The continuous integration build needs to run quickly, in order to give quick feedback on quality, but it can afford to a little more work in order to make that feedback easier to consume. We’ll see some examples of this later on in this series.

Prior post in this series:
Controlling build types
Next post in this series:


blog comments powered by Disqus