Scott Colestock

Motivating friction-free deployments• (Haven’t I been talking about this already?)

Demo first ! Automated deploy scripts (review) Automated builds Unattended deployments from the

build store

Sources of “per bug/feature” friction:• Check-in conflict resolution• Build instability (no CI)• Excessive branch isolation• Packaging (no automated MSI/other)• Physical deployment to target environment

Friction means I have more “work in progress” at any given time (evil)

Minimized friction means faster time-to-resolution

Deployment friction stems from lack of fully automated deployment process• Reliably bring a set of nodes from

“unconfigured” state to “live with your app”• Fully scripted; manual steps removed or reduced

Deployment friction stems from the “last mile” requiring human intervention• Fully packaged, fully scripted…but if a remote

desktop window is still required, you’re not done

When deploying your app requires:• Someone on your team to invest time…• Someone outside your team to invest

time… You will naturally do fewer

deployments QA staff can sometimes be idle… You iterate to problem resolution

more slowly!

Web applications and some “click-once” thick clients can reach friction-free status• Projects have a completely different feel• Pace is extremely fast

Integration projects traditionally do not reach this state, except in shops that have invested heavily

Can be addressed with a “tool chain”

1. Automated deployment script2. Automated build3. Unattended deployment

Idea is to capture all aspects of your deployment in script:• NAnt, MSBuild, VBScript, CS-Script, PowerShell –

you choose. For BizTalk solution, this means all

aspects of BizTalk solution – but also anything “out of band”• Queue creation• Virtual directory / app pool creation• File system ACLs• Registry entries• Non-BizTalk assemblies in GAC

Deliver metadata to BizTalk Management Database• Schemas, Maps, Pipelines, Orchestrations –

assemblies all interrogated• BTSTask.exe / • One time per BizTalk group• Lee Graber: “analogous to regsvr32.exe”

Deliver assemblies to the GAC• All assemblies containing schemas, maps,

pipelines, orchestrations• All .NET components you will call

Deliver Binding Files• Define physical ports (Send Port Groups/Send

Ports, Receive Ports/Receive Locations)• Associate orchestrations with host definitions• Tie logical orchestration ports to physical ports• Tie orchestration roles to parties

Ancillary components…• Custom functoids to [BtsInstallDir]\Developer

Tools\Mapper Extensions• Custom pipeline components to [BtsInstallDir]\

Pipeline Components

Virtual directories / App pools• BTSHttpReceive.dll or SOAP proxy• Appropriate permissions…

Vocabulary & Policies File drop / pickup directories (& perms) SSO Affiliate applications MSI for packaging & delivering

1. Write your own2. Use what is in the BizTalk 2006 box3. Leverage the BizTalk Deployment

Framework• http://www.codeplex.com/biztalkdeployment• Intended to provide near-identical process

for developer workstation deployments and server deployments

• Intended to allow all setup steps to be circulated among devs purely through version control

Get full sample from Codeplex • Run the sample• Spend some time with the documentation• Install NAnt according to docs Follow naming conventions for solution name,

project names, directory names for ease of use…

Get “core” zip file for Deployment Framework from same location

Expand core zip “on top” of your projects current directory structure

What do you get?• DeployTools/DeployResults/EnvironmentSettings• WiXSetup directory Create a YourProject.sln.deploy.build file…

1. Automated deployment script2. Automated build3. Unattended deployment

Pick a build engine:• TFS Team Build• Cruise Control• Final Build• Etc.

This talk focuses on Team Build… No matter what you pick, be aware:

• BizTalk’s compiler can only be invoked by DevEnv.exe (Visual Studio) Whereas most server build engines use the standalone

compilers• DevEnv has a command-line execution mode• Your build server will need both Visual Studio and a

“dev tools only” install of BizTalk

“Visual Studio 2008 Team Foundation Server Build” - official name

Core feature of TFS - you don’t buy it on its own

Industrial strength build automation in Team System

Provides the “F5” experience for your team (on server)

F5 - Mitch Denny

Team Build uses MSBuild engine Consists of:

• MSBuild tasks for Team System components (code retrieval from version control, testing, code churn calculations, update work items etc.)

• MSBuild project file (.proj), initially created via GUI, that defines build options.

Team FoundationServer

Build Agent

BuildDefinition\ TFSBuild.proj

SolutionA.sln

Calls

CompilesCompiles

Runs

BuildDefinition \ TFSBuild.proj

Ability to kick off a build on demand via Visual Studio UI or from the command line

New Continuous Integration support and GUI management of builds in 2008

Support for scheduled builds Retention policies per build, per outcome Build notifications via email or tray app

Team Foundation Server 2008 can be used in your BizTalk projects

Visual Studio 2005 / Team Explorer 2005 is required for BizTalk development• Until BizTalk 2006 R3 ships

Team Explorer 2008 (or VS2008) can be installed stand-alone or side-by-side• Required to create new build definitions

5

5 8Visual Studio 2005 Team Explorer Visual Studio 2008 Team Explorer

5 8

5 8 5 8

5 8 5 8

5 8 5 8

8

5 8 5 8

5 8 5 8

5 8 5 8

5 8 5 8

8

8 8

8

8

8

8 8

5 8 5 8

8

8

5 5 8

8

8 5 8 8

5

5

Build definitions in Team Build 2008 have two components:• Configuration data in the Team Build

database• TFSBuild.Proj file in version control

TFSBuild.proj file for a BizTalk project can be reused across projects

Only variability is solution name, build configuration, and “BranchPath”

(Walkthrough)

1. Automated deployment script2. Automated build3. Unattended deployment

All deployments (dev/qa/production) should start by referencing a “build number”• Build numbers should uniquely identify a “bill of

materials” (via assembly version, or version label in source control)

• Basic level of deployment traceability• Consider naming MSI to include build number

Team Build applies build number to every build generated• Applies label to source repository• Build script can include a “BuildNumber.txt” in

MSI

Team Build in TFS surfaces completed and failed builds in the “Build Store” UI within Team Explorer

• “Build Store” UI is purely informational

• What has completed, what has failed

• Wouldn’t it be slick to use that UI to indicate you want a build to be

deployed?

• (Yeah, we saw that already)

Open source project (CodePlex) originally developed by Readify

TFSDeployer.exe service runs as an agent on the servers within desired environments (Dev, QA, beyond?)

Listens to “build quality change” events from Team Foundation Server

Runs appropriate script in response

TFS Application/Database Server

Target Machine

TFS Build Store

TFS Event Service

TFS Event Subscription Store

Developer Machine

User running Team Explorer

2 – Update Build QualityIn “Build Store” UI

TFSDeployer Service

1 – Subscribe to build qualitychange events

3 – Build Quality Change Event

4 – Subscriber Information

5 – Build Quality Change Event

PowerShell Instance

TFS Version Control Store

6 – Deployment Mapping File and PowerShell Script

7 – Create Power Shell Instanceand run script

• DeploymentMappings.xml exists per build type…• Lives underneath build definition in version control• Maps server names to quality transitions and a script!

Ability to control transitions based on account

Scripts can be secured with digital signatures

Possible to sign deployment mappings Can work across domains See

http://traceofthought.net/misc/tfsdeployersetup.htm

for documentation...

“Natively” kicks off Powershell scripts when DeploymentMappings.xml indicates events should trigger deploy

Experienced Powershell developers are still rare so…delegate!

A small Powershell script can transition control to a VBScript, CS-Script, MSBuild, etc.

DeploymentMappings.xml is expanded slightly to contain attributes for:• Application name• Flag for management database deploy• Environment settings file• Staging directory• Installation directory

Script has a relatively simple job…• Get information from DeploymentMappings.xml• Undeploy the old build, by calling

ServerUndeploy.bat (part of Deployment Framework)

• Uninstall the old MSI• Copy the new MSI from the build server, and

install it• Deploy the new build, by calling ServerDeploy.bat

(part of Deployment Framework)• Log everything for monitoring…

What about deploy-time configuration?• DeploymentMappings.xml will reference an

“environment” file that contains most info• Sensitive info can be stored on the nodes you

are deploying to, in a file ACL’d to TFSDeployer account

• Or alternately, sensitive info can go into a special SSO affiliate application

• Some aspects – like application pools – can be rigged for one-time creation.

Team Build template will be released soon standalone (traceofthought.net)

MSBuild file invokeable from PowerShell released soon (traceofthought.net)

All packaged together as a sample – perhaps extending the existing “Deployment Framework” project

Remove friction wherever you can… Remove deployment friction through:

• Automated deployment scripts Candidate: Deployment Framework

• Automated builds Candidate: Team Build in TFS

• Unattended deployment machinery Candidate: TFS Deployer