Growing Employees

How frequent releases help you satisfy and retain your best employees

Think back to the last time you released to your customers. There was probably a brief feeling of satisfaction, hopefully a validation from the customer that you delivered what they wanted, and your team learned a thing or two about how effective they are at deploying and testing the changes that were delivered with the release. Soon afterwards, the team gets to start all over again and these lessons are forgotten.

If you think about a long term relationship, when two people haven’t talked for a while they can get nervous. “Does he still remember what I said about what we were going to do?”. “I wonder if they still feel the same way about me?”. This phenomenon is also present in product development, and the longer your team goes before releasing, the bigger impact these psychological (and measurable) effects have on the profitability of your business goals.

Keeping delivery staff satisfied

When a change is delivered to the customer that meets their needs, the team gets a big boost in motivation. The team is thanked and hopefully rewarded for their efforts, and sales and marketing have a great new story to tell. During this period of “delivery afterglow”, staff are intrinsically motivated to work harder as they feel a responsibility for and purpose to their job. After a while however, staff can revert to their instincts to question how important their job really is, leading to the “I’m just a cog in a wheel” mentality. “Was what we delivered really that big of a deal?”. “I wonder if we can repeat that success again?”.

When release cycles are short enough, this feeling of satisfaction becomes constantly present and creates the environment where people love to do their job not just because of their compensation, but because of the satisfaction they get out of doing it through regular positive feedback. An environment like this is contagious – staff outside of the successful team want to learn their methods and repeat their success, and staff on the successful team are happy to talk about it with friends and potential customers.

What have you done for me lately?

From the customer point of view, they also experience similar emotions that have an impact on the profitability of your delivery efforts. If a long period of time has elapsed between when the customer got a release with changes, they may begin to wonder if you still understand their vision. “Do they know what’s changed in my market since last time we met?”. “I hope they understood what I said!”. “I wish I could talk to them more without bothering them!”. When release cycles are long, this risk of changing priorities and incorrect assumptions has a higher cost. When a manufacturing plant releases a part on to the next station that has a problem, it is often caught via quality gates when assembled as part of the next process to stop the line from moving it forward. In product development information is our inventory, and our customers are the quality gate that matters most.

If an incorrect assumption is made about a change or feature and not validated with the customer early, hundreds of other changes can be based on this incorrect assumption and they are all impacted if the customer finds them to not be valid once released to them. Engineers can lose motivation dramatically if they release a big feature that took a long time to implement only to find that it all has to be reworked. It makes both economic and behavioral sense to release more frequently to ensure that the relationship between the team and its customers is aligned as often as is reasonable.

Practice makes perfect

When releasing changes to the customer, there are delivery costs that are only incurred at the time of release. These usually include things like deployment, user acceptance testing, updating user documentation, and gathering feedback. When release cycles are long, these activities are infrequent so there is low motivation to getting better at them. If a team only releases to their customer once every 6 months, they feel the pain of these activities infrequently and so they are willing to see it as such – a necessary evil that isn’t worth the time to improve. When releases are more frequent, the cost of manual or inefficient delivery processes is more apparent and staff can more clearly see the cost of not making them as efficient as possible.

Optimizing release process costs is doubly profitable as it both reduces the cost of performing the process, and reduces the time for return on investment due to enabling more value to be delivered per release since a smaller percentage of the effort that goes into a cycle is taken up by these processes. It also increases staff job satisfaction because more time is spent delivering value that is the direct result of the innovation inherent in the creation of IT assets, not simply drudging through excessive process overhead that hasn’t been optimized due to low motivation to do so.

Motivating for excellence

A final important consideration that impacts staff retention and job satisfaction is the opportunity that frequent releases create for evaluating competence. When releases cycles are long, staff are able to report being done with tasks but this is not truly verifiable until it is released to the customer. Many organizations realize the inherent value in retaining top talent but struggle to know how best to help them grow. One of the best ways to help our employees be more effective is to have regular checkpoints during which to measure both quantitative and qualitative outcomes. An IT asset release is a perfect time to do this.

The SCRUM methodology encourages teams to hold a sprint retrospective meeting during which the team can be candid about their successes and opportunities for improvement since the last iteration. When iterations of effort are reported as “complete” at the end of each sprint but not released to customers, unchecked problems with deployment and missed alignment with customer needs is not caught and can leave a team with a misplaced perception of success. This perception is then aligned when the release actually occurs, and the reset between what was perceived and what is reality can be harsh and demotivating.

Rather than delay the inevitable, by releasing to customers more often before starting new work, leaders that evaluate their staff have a better gauge for where staff are doing well and where their skills may need help. An effective manager will use this period to both reward and compliment staff on their improvement and be courteous in helping them see where they need to improve. Though this increased confrontation with competence can initially be met with feelings of uneasiness, it soon becomes a regular part of work and employees begin to expect honest feedback and to be complimented and rewarded when they improve.

Top 5 business myths about Continuous Delivery

When a team decides to try reducing the time it takes for their ideas to get to their customers (cycle time), there are a few new technical investments that must be made. However, without business stakeholders supporting the changes in a SCRUM approach that delivers frequent releases, decisions and planning are driven by gut feel and not quantifiable outcomes. The following is a list of the top 5 myths I encounter (and often address when I provide coaching) to help staff that are not solely technically-focused when they begin adopting Continuous Delivery.

#5: By automating deployment, we will release more profitable ideas.

Automating deployment of IT assets to reduce low value activities like manual configuration and deployment (with risky error-prone manual human intervention) certainly can eliminate wasted capital as part of the process of releasing IT offerings, and is a key practice of Continuous Delivery. However, if the frequency of releases is long, the cost of delaying the availability of those releases to customers adds risk in that their viability in the market may no longer be what was theorized when it was planned.

Once release frequencies are improved, measurement of customer impact and proper work management (specifically appropriate capacity planning and calculating the cost of delay for potential features) must be done to ensure that ideas that turn out to be misses in the market stop stop being worked on as soon as they are identified as bad investments. It is this harmony of smart economic decisions with respect to investing in the idea combined with the technical benefits of building an automated deployment pipeline that transforms the profitability of an IT value chain.

#4: We must automate 100% of our testing to have confidence in automating releases to production

Utilizing automated quality checks to ensure that changes to IT assets do not break existing functionality or dependent systems is certainly a good practice. A long manual test cycle is doubly problematic: it delays releases and adds risk since many teams try to get started on new work while testing is underway. When issues are found with a release candidate build or package being tested, engineers must stop what they are doing to troubleshoot and attempt to fix the problems.

On the flip side, automating the entire testing effort has its own risks as the team can cost the business large sums by having to change and maintain tests when they make changes to the design which happens frequently in Continuous Delivery. Deciding on an appropriate test coverage metric and philosophy should be treated with importance and not included in work estimates as separate line items to discourage removal in an attempt to cut costs. Cutting quality is often the final dagger in the throat of a struggling IT offering.

#3: The CFO requires us to release everything in the backlog to report costs

Many businesses treat IT investments as capital expenditures since they can take advantage of amortization and depreciation to spread the cost of that investment over a longer time period. However, this assumes that the value in the investment provides a consistent return over the lifetime of it being used to generate revenue. A SCRUM process for delivering IT assets aligns better with being recorded as operating expenditures since a minimum viable offering is typically released with a low initial investment in the first few sprints, and the business makes ongoing “maintenance” changes to the offering as the priorities of the market and customer needs change. This is especially true today with everything moving increasingly to cloud based models for value consumption.

#2: We need a “rockstar” in each role to deliver profitable offerings

Many IT offerings that start with an idea are initially implemented with an expert in a particular technology or aspect of delivery, and the team leans on them early on for implementation and expertise. As the complexity of a solution expands, the biggest drain on the profitability of a team is no longer the availability of experts and the high utilization of people’s time – it is the time work to be completed spends waiting in queues. There are several ways to reduce wait time when work with a high cost of delay is held up in a queue. The two methods I see with the most value are to reduce the capacity utilization of team members, and to enable staff to work on more than one discipline.

When team members are highly utilized (their planned capacity is over 60%) this leaves no room for the highly-variable process of delivering IT offerings to account for unknowns that were not identified during planning or design of a cycle of implementation. If the cost of delaying the availability of an idea is high, the cost increases when the date planned for release is missed. Rather than loading resources up to a high capacity, leave them with reasonable overhead to collaborate, tackle unforeseen challenges, and help each other if they finish early.

When team members are specialized, the probability of one member being blocked from continuing by another goes up dramatically. Work to be completed spends more time in a queue wasting money and not moving closer to being made available to customers so it can realize a return. Though you will always have team members that have expertise in specific areas, resources that are willing to test, make informed product priority decisions, and help with deployment and automation are more valuable as part of an IT value stream than specialists. Use specialists when the work requires it, but scale more of your resources out across multiple disciplines for sustainability.

#1: Until we release everything in the backlog, we won’t succeed with our customers

This myth is driven by the manufacturing mindset of looking at IT offering delivery as though all features must be identified up front and misses the point of agile methods entirely. The backlog is a set of theories on what customers will find to be valuable at any given point in time. Any offering that takes more than one release to complete will have a working minimum viable product available to some audience where feedback can be gathered before it’s done.

Since the point of frequent releases is to get that feedback and let it impact the direction of the IT offering, planning to release everything in the backlog leaves no capacity for taking action on that feedback. If you only plan to release everything the business thinks is a good idea at the beginning of a project before letting customer feedback influence priorities, you are simply releasing milestones of planned up-front work – which is a classic waterfall delivery process.

Powerdelivery extension for Visual Studio 2013 released

I’ve released a version of the Visual Studio extension for using powerdelivery on Chocolatey. This extension allows you to connect to Team Foundation Servers, see which builds are present in each of your environments (Dev, Test, Production etc.), open the appropriate scripts and config files for developing the pipeline, and kickoff builds.

To install it, have Powerdelivery and Visual Studio 2013 already installed. Then run the following from the command prompt (with Visual Studio closed):

cinst PowerDelivery-VSExtension-2013

Remember you can also install this extension for Visual Studio 2010 or 2012 as well using the appropriate package.

New online help, Visual Studio extensions, and getting started video for powerdelivery

It’s been just shy of a year since I made my first commit to github to start the powerdelivery project. For those of you new to my blog, powerdelivery is a free toolkit that extends Microsoft Team Foundation Server enabling your development and IT operations teams to continuously deliver releases of your IT assets (software, CMS systems, BI solutions etc.) to your customers. It uses Windows PowerShell and YAML (yet another markup language) to provide a configuration-driven platform and can even do scaled deployment of windows services and web sites across farms and clusters.

If you’ve followed the project before but yet to use it, there have been many improvements made and defects fixed in the past month and I’ve got some exciting resources that are becoming available to make it easier to use and even more powerful.

New online help for powerdelivery

Over the past couple of months, I’ve created a basic site using twitter bootstrap to host the documentation for powerdelivery on github pages. The site is a major improvement over the wiki and has everything you need to begin using it. You can find the new online help page right here.

Visual Studio Extensions for 2010 and 2012

I’ve also created an extension for Visual Studio that allows you to view the status of each of your environments, promote builds, and add new deployment pipelines to existing Microsoft Team Foundation Server projects. The extension still has a few quirks but is stable for the most part and ready for use. You can install it from chocolatey here.

Getting started video

Lastly, I’ve created a getting started video that shows you how to get powerdelivery installed and configured, and to create your first pipeline. This video alone will not be enough to build your continuous delivery pipeline, but it’s a great walkthrough of the Visual Studio extension and what powerdelivery gives you. You can watch the video below via YouTube (watch on YouTube for HD).

Getting started with powerdelivery 2.3

Powerdelivery 2.0.6 adds pretty 2012 summary page, delivery module API, and build asset cmdlets

I’ve just pushed out another update to powerdelivery. You can get it on chocolatey (‘cup powerdelivery’ if it was already installed ‘cinst powerdelivery if not’).

Pretty Build Summary on TFS 2012

Behold the new summary page when you run your builds in TFS 2012:


The output you see above is included by default without any code needed on your part. You can however write your own messages into these sections using the new Write-BuildSummaryMessage cmdlet. This cmdlet only works on TFS 2012. When you specify the “name” parameter of the cmdlet, pass the name of a delivery pipeline code block (“Init”, “Commit”, or “Deploy” for example) to have your message show up in that section.

Delivery Module API

This is a feature I’ve been wanting to add for a while now. One of the nice things about powerdelivery is that instead of having to learn all the moving parts in Windows Workflow foundation, you just have a PowerShell script and CSV files. However, there are some things you might do over and over again in your script that you want to drive with configuration to eliminate having to place code in your script for them. Examples are deploying databases, websites, etc. There are already cmdlets in powerdelivery to do this, but I’ve introduced a new Delivery Module API that can be used to create even more powerful reusable modules for delivering different types of assets.

To create a delivery module, you need to create a regular simple PowerShell module following any of the instructions you’ll find on the web and make sure it’s available to your script (putting the folder that contains it in your PSMODULEPATH system environment variable is easiest). Pick a name that’s unique and from then on you may use that module in your scripts by using the new Import-DeliveryModule cmdlet. If you call this cmdlet by passing “MSBuild” for example, powerdelivery will try and invoke functions that match this name following the convention below:


Where “ModuleName” might be “MSBuild” and “Stage” might be “PreCompile” (for example, Invoke-MSBuildDeliveryModulePreCompile). You can name the functions in your module starting with “Pre” or “Post” to have them run before or after the actual “Compile” function in the build script that imports the module.

If this function is found it is invoked before or after the pipeline stage specified, and you can do anything you want in this function. A common use would be to look for CSV files with values you can pass to existing functions. I’ve included an initial MSBuild delivery module as an example of how to do this. It looks for a file named “MSBuild.csv” and if it finds it, will build any projects using the settings in that file.

I’m still working on this API so any feedback is appreciated.

Build Asset Cmdlets

A common operation in your build script is copying files from the current “working” directory of your build on the TFS build agent server out to the “drop location” which is typically a UNC path. To make this easier I’ve added the Publish-Assets and Get-Assets cmdlets which are quite simple and take a source and destination path. These cmdlets will push and pull between our local working directory and the drop location without having to specify a full path and should simplify your script. The build summary page on TFS will display any assets you publish.

Coming Soon

The next two things I will be completing is the integrated help for all included cmdlets (so you can get syntax help in PowerShell instead of on the wiki), and updating the existing templates other than the Blank one to match the new syntax in the 2.0 release. I’ll then be working on getting more templates and delivery modules put together to help you hit the ground running with your delivery automation.

Powerdelivery 2.0 released on chocolatey

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.

What’s new?

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:

cinst powerdelivery

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.

  1. Follow the instructions on the website for installing powerdelivery using chocolatey on your build server.
  2. 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.
  3. 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. 
  4. 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.

  5. 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.

powerdelivery now supports Microsoft Team Foundation Server 2012

The open source powerdelivery project I’ve been blogging about using to enable continuous delivery automation for your software projects has now been updated to support TFS 2012.

Creating new projects using TFS 2012 powerdelivery

To add powerdelivery to a TFS 2012 project, just pass the –tfsVersion parameter to the AddPipeline utility specifying 2012. For instance:

    .\AddPipeline.ps1 (other parameters) –tfsVersion 2012

If you are using Visual Studio 2012 as well for your developers, you will probably also want to pass the –vsVersion parameter and specify 11.0 (10.0 is the default, which is Visual Studio 2010).

Upgrading existing projects to TFS 2012 powerdelivery

If you were using TFS 2010 and want to upgrade your server to 2012, to upgrade your powerdelivery-enabled projects to use the 2012 configuration, grab the latest zip from master and add the following files to source control from the source:


Lastly, you will need to edit the Build Process Template for your “Commit” build and set it to use the PowerDeliveryTemplate11.xaml file (instead of PowerDeliveryTemplate.xaml) and edit the rest of your builds (Test, CapacityTest, Production) to set them to use PowerDeliveryChangeSetTemplate11.xaml.

Happy continuously delivering!

Deploying Microsoft Business Intelligence solutions with powerdelivery

I’ll discuss continuously delivering web and mobile applications in a later post, but since I just recently worked on one I’d like to start with guidance for using powerdelivery to deliver a Business Intelligence (BI) solution. This solution might deliver databases, cubes, packages, reports, or SharePoint dashboards like PerformancePoint.

I’ll assume at this point you have a backlog of user stories that describe business capabilities that are desired. You’ve also had your sprint planning meeting and come up with acceptance criteria for what you’re going to build in your first sprint. You desire to iteratively release pieces of acceptance tested BI functionality. You want to reduce your cycle time, and thus the time it takes to go from an idea for BI functionality, until it is delivered to users.

In a nutshell you want to release to users as quickly as possible after an idea is conceived!

Perform the following steps initially by only deploying to your “Commit” (development) build environment. Once you have it working there, you should immediately escalate it to test, and then to production to get your initial release in place even if it has no functionality yet!

Step 1: Create build account

Have your IT administrator create a user account for builds to run under. Configure Team Foundation Server to build using this account (see the TFS agent service on your TFS agent computers).

Step 2: Procure and secure environment

Identify the environments that will be used to deliver your solution. Determine the desired production environment’s physical and virtual nodes (servers or VMs), and procure a development and test environment with at least one node for each scaled point of the production environment. For example, if you have a load balancer with 5 nodes in production, have a load balancer but with just one node in development and test environments. Ideally, you should setup these computers from scratch with identical OS and middleware (SQL server for example) and lock them down only be accessed by the Active Directory build account. All future configuration changes will be made via your build.

Step 3: Open ports

Have your IT administrator open ports for the TFS agent to perform automation activities. Ports 5985 and 5986 must be open on each computer to be automated (development, test, and production database and SharePoint server computers or VMs for example). You also need to open any ports needed to perform other automation activities and send data between computers. Examples are port 1433 for SQL server, or port 2383 and 2384 for SSAS (multidimensional and tabular defaults, respectively). You may also need to open port 137 to allow UNC paths to be accessed.

Step 4: Create delivery pipeline

Next, use the AddPipeline utility to create builds for your deliverable. You want to create a build for each capability you need to independently deploy. If you have databases, SSIS packages, and cubes that all work together to provide one data mart, web site, or BI capability, you may want to keep these in a single build for simplicity of maintenance.

Step 5: Create UNC shares on environment nodes

Create a UNC share on each of your computers that will have SSIS packages, SSAS models, databases, or other assets deployed to them as files. Give write permission to the Active Directory account your build runs under to these shares.

Step 6: Record your environment configuration

Edit the .csv files for your powerdelivery build’s environment configuration and add name/value pairs for each setting that is environment specific. Include settings for things such as:

  • Database servers
  • Database names
  • Computer names
  • UNC paths
  • Tabular server instances
  • Connection strings

Tip: If you have multiple nodes in production and only one in development and test but need to automate configuration, use a PowerShell array as the value in the .csv file and loop over it in your script for each node. For example in production:


In development:


Step 7: Identify subsets of data for automated testing

As you identify source data over sprints, create views (if they don’t already exist) to abstract the data and use a database migration technology such as RoundhousE or Visual Studio Database Projects to deploy them with your build. If an existing system that one of your components is sourcing data from has millions of rows, you want to have development versions of these views that only pull a subset of your data suitable for testing. The views in your UAT and production environment will pull the entire data set.

The reason for this is to speed up builds and processing in your commit (development) environment so that automated tests can run and provide feedback faster than what would be necessary when processing the entire set of data. You will need to lean heavily on experts of the data, and business analysts to either identify a subset of data that exists, or script creation in an empty database perhaps of new data suitable for running your tests.

Step 8: Load your environment configuration

Modify your build script to create global variables for all the environment configuration settings you filled out in step 6 in the Init function of the build.

Step 9: Copy assets to the drop location

Modify your build script further by editing the Compile function. Use this function to copy any files you will need during deployment from your current directory (where TFS grabbed a copy of the source code) to the drop location. These files include dlls, SSIS packages, .asdatabase files, .sql scripts, powershell scripts, or any other files that will be deployed to the environment computers.

Step 10: Script environment modifications

If the latest version of your code requires a dependency of a configuration change, use this function to do so.

Examples of things to do here are:

  • Set environment variables. Your SSIS packages or other deliverables will pick up the correct settings for each environment.
  • Use the Azure PowerShell cmdlets to procure an Azure node or database
  • Give security permission to users on SQL databases
  • Run NuGet to install .NET dependencies (log4net, Entity Framework etc.)
  • Apply OS or middleware patches
  • Change security settings of services or file system

Step 11: Script deployment activities

In the Deploy function of your script, you will perform the steps to actually deploy the solution assets. You can only use files in the build’s drop location, so a common problem here will be to try and run something that’s in source control but you didn’t copy in the Compile function. If this happens, go back to step 9.

Examples of things to do here are:

  • Run SQL scripts
  • Deploy and/or run SSIS packages
  • Create and/or run SQL jobs
  • Deploy and/or process SSAS cubes (BISM Multidimensional or Tabular)
  • Start/stop SQL jobs

Tip: Your script is running on your TFS build agent computer. But many of the deployment utilities used for automation, such as dtexec.exe (to run SSIS packages), or Microsoft.AnalysisServices.Deployment.exe (to deploy cubes) will run on the database or other servers. Because of this, you will often need to copy files that are input for these commands to one of the UNC shares you setup in step 5.

Step 12: Script unit tests

In the TestUnits function of your script, you can run tests that make sure that individual units of your solution work independently. You might use MSTest.exe to run Visual Studio database unit tests written in T-SQL.

Step 13: Script acceptance tests

If you automate one kind of test, at least do the acceptance ones. These are what you described to the business during the sprint planning meeting that you’d show. Read my prior post on defining acceptance if you are new to it.

Because most BI solutions use scheduled batch jobs to do processing, you will need to cause jobs or any other sort of processing to run in the Deploy function in step 11 if you want them available to be tested here.

Since powerdelivery is a synchronous script, you have two options for doing acceptance testing:

Inline publishing of tests

With this approach, your script should run the SSIS packages or SQL scripts that a job normally invokes on a schedule and and wait for them to finish. You can then run your tests immediately after and automate publishing their results if you want business users that access the TFS portal to see the results of your testing.

Late publishing of tests

With this approach, you can let the build finish and wait for scheduled SQL jobs or processing to finish by monitoring the process. When it completes, run your tests using Visual Studio manually and publish them to the build they were run against.

Step 14: Automate restoring test databases from production

To make sure that any database alterations made in production are tested exactly as they will work in production, add a step to the Deploy function to take a production backup and restore it over your test databases prior to running these alterations. Only run this step while doing a test environment build. You can check for this using the powerdelivery Get-BuildEnvironment helper cmdlet.

Promoting your releases

At this point, you should get your build to succeed in the Commit (development) environment and then immediately promote it to Test, and then Production. As you plan sprints, use the knowledge you gained setting up the script to help team members estimate the work it will take to make modifications to the build to deploy and change the environment needed by their features. Include this in your estimate for user stories you deliver in the future.

When one or more team members has their feature passing acceptance tests in the Commit environment, promote that build to your Test environment and have it inspected by QA. If it is of sufficient quality, hold the sprint review meeting. If the business decides to release to production, queue a Production build and release it to your users.

5 advantages of powerdelivery over vanilla Team Foundation Server

The open source powerdelivery project for doing continuous delivery I’ve blogged about does a lot of things in a small package, so it’s natural to want to understand why you would bother to use it if perhaps you like the concepts of continuous delivery but you’ve been using off the shelf Microsoft Team Foundation Server (TFS) builds and figure they are good enough. Here’s just a few reasons to consider it for streamlining your releases.

You can build locally

TFS lets you create custom builds, but you can’t run them locally. Since powerdelivery is a PowerShell script, as long as you fill out values for your “Local” environment configuration file you can build on your own computer. This is great for single computer deployments, demoing or working offline.

You can prevent untested changes from being deployed

You have to use the build number of a successful commit build as input to a test build, and the same goes for moving builds from test to production. This prevents deployment of the latest changes to test or production with an unintended change since the last time you tested and when you actually deploy to production.

You can add custom build tasks without compiling

To customize vanilla TFS builds, you need to use Windows Workflow Foundation (WWF *snicker*) and MSBuild. If you want to do anything in these builds that isn’t part of one of the built in WWF activities or MSBuild tasks, your stuck writing custom .dlls that must be compiled, checked back into TFS, and referenced by your build each time they change. Since powerdelivery just uses a script, just edit the script and check it in, and your Commit build starts automatically.

You only need one build script for all your environments

You can use the vanilla technologies mentioned above to create builds targeting multiple environments, but you will have to create a custom solution. Powerdelivery does this for you out of the box.

You can reduce your deployment time by compiling only in commit (development)

The Commit function is only called in Local and Commit builds, so you can perform long-running compilation activities only once and benefit from speedy deployments to your test and production environment.


Get every new post delivered to your Inbox.

Join 78 other followers

%d bloggers like this: