There’s never been a better time to get started looking at continuous delivery with PowerShell and TFS than today. Over the weekend I redesigned powerdelivery to have a cleaner syntax, and allow for quicker installation using chocolatey (a system-wide package manager for Windows based on nuget). This topic describes the redesign as well as how to upgrade older (version 1.0) powerdelivery projects.
The section below describes what’s been changed in powerdelivery 2.
Cleaner build script format
Powerdelivery 1.0 required declaring of script parameters, declaring an app name and version as variables, and adding functions for the stages of your deployment pipeline you want to support. Version 2.0 refines this dramatically by allowing you to invoke the Pipeline function at the top of your script to set the name and version, and then declare code blocks into which the code that executes in each stage goes.
Take a look at the default build template on github for an example of a the new blank script format.
Install with chocolatey
Install chocolatey following the instructions in the website, and then open an administrative command prompt. To install powerdelivery enter the following:
As new releases come out, you now only need to re-run this command to get the latest package setup and configured for use by your build server (or locally, for local builds). Note that this method of installation also has the benefit of providing intellisense in the PowerShell ISE or PowerGUI for all of the included powerdelivery cmdlets.
Environment targets secured by TFS
When you use the Add-Pipeline cmdlet to add powerdelivery to your TFS project, a security group is created that users must be placed in to trigger/queue non-commit builds. This allows IT to control who is allowed to promote builds to the test and production environment and will fail the build with an appropriate error message if you try and circumvent this.
Target TFS version auto-detected
With powerdelivery 1.0 you had to tell the Add-Pipeline cmdlet whether the target TFS server was running version 2010 or 2012. Version 2 detects this automatically and will configure the server appropriately without requiring you to specify anything.
Pipeline promotion order enforced
In powerdelivery 1.0 it was possible (though frowned upon!) to promote a commit build to production, or a test build to commit. This certainly was not intended though the limited audience using it was able to control this.
Version 2 enforces the pipeline promotion order as follows:
- Test, UAT, and CapacityTest environment builds must be promoted from a Commit build
- Production environment builds must be promoted from a Test build
Upgrading to Version 2
Upgrading to version 2 of powerdelivery is fairly straightforward.
- Follow the instructions on the website for installing powerdelivery using chocolatey on your build server.
- Refactor your build script to follow the new format. This should be self explanatory looking at the blank template. A key change is to try and use script instead of global scoped variables in your Init block.
- Locate the directory powerdelivery is installed into (for example, C:\Chocolatey\lib\powerdelivery.XXX). Find the files in the “BuildProcessTemplates” directory and upload these to your TFS project. These are the updated build process templates needed by version 2. We’re working on adding a switch to the Add-Pipeline cmdlet to allow you to do this automatically in the future.
- Remove the PowerShellModules subdirectory of your TFS project. This is no longer necessary as powerdelivery is now loaded as a module via chocolatey. If you had any other modules you were using other than powerdelivery in this directory, either install them as system-wide modules or add the following line to the top of your script:
$env:PSModulePath += “;.\PowerShellModules”
IMPORTANT: Remember to delete the “Powerdelivery” subdirectory of PowerShellModules if you choose to keep this directory.
- You may need to have your TFS administrator add users that were able to queue test and production builds to the security groups controlling who can build to each environment. If you don’t have appropriate permissions to build to an environment you will get an error message during the build that should be self explanatory for helping you figure out which group to add the user to.