Date post: | 23-Dec-2015 |
Category: |
Documents |
Upload: | clifford-spencer |
View: | 213 times |
Download: | 0 times |
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