转载：Using PowerShell in the build process 使用Powershell进行build

Using PowerShell in the build process

by Mike Linnen

四月 08, 2009 06:37

I
have used NAnt and MSBuild for years on many projects and I always
thought there has to be a better way to script build processes. Well I
took a look at PowerShell
and psake
and so far I like it. psake
is a PowerShell
script that makes breaking up your build script into target tasks very
easy. These tasks can also have dependencies on other tasks. This
allows you to call into the build script requesting a specific task to
be built and have the dependant tasks get executed first. This concept
is not anything new to build frameworks but it is a great starting
point to use the goodness of PowerShell in a build environment.

You can get psake from the Google Code repository
.
I first tried the download link for v0.21 but I had some problems
getting it to run my tasks so I went directly to the source and grabbed
the tip version (version r27 at the time) of psake.ps1 and my problems
went away.

You can start off by using the default.ps1 script
as a basis for your build process. For a simple build process that I
wanted to have for some of my small projects I wanted to be able to do
the following:

“Clean”the local directory

“Compile” the VS 2008 Solution

“Test” the nunit tests

“Package” the results into a zip for easy xcopy deployment

Here is what I ended up with as a starting point for my default.ps1.



This
really doesn't do anything so far except set up some properties for
paths and define the target tasks I want to support. The psake.ps1
script assumes your build script is named default.ps1 unless you pass
in another script name as an argument. Also since the task default is
defined in my build script if I don't pass in a target task then the
default task is executed which I have set as Test.

Build invoked without any target task:



Build invoked with the target task Package specified:



So
now I have the shell of my build so lets get it to compile my Visual
Studio 2008 solution. All I have to do is add the code to the Compile
task to launch VS 2008 passing in some command line options.



And here it is in action:



Notice
I had to pipe the result of the command line call to “out-null”. If I
didn't do this the call to VS 2008 would run in the background and
control would be passed back to my PowerShell script immediately. I
want to be sure that my build script would wait for the compile to
complete before it would continue on.

What about if the
compile fails? As it is right now the build script does not detect
that the compile completed successfully or not. VS 2008 (and previous
versions of VS) return an exit code that defines if the compile was
successful or not. If the exit code = 0 then you can assume it was
successful. So all we need to do is test the exit code after the call
to VS 2008. PowerShell makes this easy with the $LastExitCode
variable. Throwing an exception in a task is detected by the psake.ps1
script and stops the build for you.



I
placed a syntax error in a source file and when I call the Test target
the Compile target fails and the Test target never executes:



Now
I want to add in the ability to get the latest code from my source
control repository. Here is were I wanted the ability to support
multiple solutions for different source control repositories like
Subversion or SourceGear Vault. But lets get it to work first with
Subversion and then later refactor it to support other repositories.
For starters lets simply add the support for getting latest code in the
Compile task.



As
you can see right now this is very procedural and could certainly use
some refactoring, but lets get it to work first and then worry about
refactoring. Here it is in action:



As
I mentioned before I want to be able to support multiple source control
solutions. The idea here is something similar to what CI Factory
uses. In CI Factory
you have what is known as a Package. A Package is nothing more than an
implementation of a build script problem for a given product. For
example you might have a source control package that uses Subversion
and another source control package that uses SourceGear Vault. You
simply include the package you want for the source control product that
you are using. Psake also allows for you to include external scripts
in your build process. Here is how we would change what we have right
now to support multiple source control solutions.

So I created
a Packages folder under the current folder that my psake.ps1 script
resides. I then created a file called SourceControl.SVN.ps1 in the
Packages folder that looked like the following:



In
the default.ps1 script Compile task I replaced the source control get
latest code (told you I was going to refactor it) with a call to the
SourceControl.GetLatest function (Line #20). I also added a call to
the psake include function (Line #10) passing in the following
“Packages/SourceControl.SVN.ps1”. Here is what the default.ps1 looks
like now:



So
if I wanted to support SourceGear Vault I would simply create another
package file called SourceControl.Vault.ps1 and place the
implementation inside the GetLatest function and change the include
statement in the default.ps1 script to reference the vault version of
source control. I plan on adding in support for my Unit Tests the same
way I did the source control, that way I can easily have support for
multiple unit testing frameworks.

Conclusion

As
you can see it is pretty easy to use PowerShell to replace your build
process. This post was just a short introduction on how you might get
started and end that crazy XML syntax that has been used for so long in
build scripting. I have a lot more to do on this to make it actually
usable for some of my small projects but hopefully I can evolve it into
something that will be easy to maintain and reliable. All in all I
think PowerShell has some pretty cool ways of scripting some nice build
solutions.