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.
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:
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.
The only difference here is the use of Formal.Build
as the target for Psake:
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:
And, for now, our target is the same as the Integration.Build
:
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.
Comments
blog comments powered by Disqus