Transcript Unattended BizTalk Deployments

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-toresolution
 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.
2.
3.
Automated deployment script
Automated build
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.
2.
3.
Write your own
Use what is in the BizTalk 2006 box
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.
2.
3.
Automated deployment script
Automated build
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.
Calls
Runs
SolutionA.sln
BuildDefinition\
TFSBuild.proj
Team Foundation
Server
Build Agent
SolutionB.sln
msbuildm.exe
msbuild.exe
Compiles
msbuild.exe
BuildDefinition \ TFSBuild.proj
Build Initiated
from TFS
Prepare build
agent and create
build number
Sync Sources
Compile and
Analyze
Calculate Code
Churn
Calculate Code
Coverage
Update Work
Items
Execute Tests
Produce Build
Report
Copy to Drop
Publish Results to
TFS
Notify Event
Subscribers
 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
Feature
TFS2005
Create Build
5
Start / Queue Build
5
View Build Definitions
View CompletedBuilds
TFS2008
Feature
TFS2008
5
8
Delete Build Definition
8
5
8
Edit Retention Policy
8
5
8
5
8
Edit Build Triggers
8
5
8
5
8
Assign Build Agent (UI)
8
Delete Build in UI
View Queued Builds
View Build Reports
5
8
5
8
Build .NET 2.0 project
View Build Log
5
8
5
8
Build .NET 3.5 project
Edit Build Quality
5
8
5
8
Postpone Build
Open Drop Folder
5
8
5
8
Manage Build Qualities
Stop/Cancel Build
8
Manage Build Agents
Pass command line arg
8
Edit workspace map
5
TFS2005
Visual Studio 2005 Team Explorer
8
8
8
5
8
8
5
8
8
5
8
5
8
8
5
5
8
8
5
8
Visual Studio 2008 Team Explorer
8
 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)
$/
Product/
Trunk/
Releases/
SolutionA
Version1
Project1
Project2
SolutionA
Project1
Project2
1.
2.
3.
Automated deployment script
Automated build
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
Developer Machine
2 – Update Build Quality
In “Build Store” UI
TFS Event
Subscription Store
TFS Build Store
User running
Team Explorer
3 – Build Quality Change Event
4 – Subscriber
Information
TFS Event Service
5 – Build Quality Change Event
6 – Deployment Mapping File and
PowerShell Script
TFS Version
Control Store
Target Machine
1 – Subscribe to build quality
change events
TFSDeployer Service
7 – Create Power Shell Instance
and run script
PowerShell Instance
• 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