RE: [OzTFS] TFS Deployer

[Geoff Appleby]

I thought I’d comment on this, even though you really only asked a couple of questions, and that I’m the team writing this thing J   > do you guys see any use in this tool? I do – but with a certain caveat. Whereas something like continuous integration is useful for just about any project, an automated deployer isn’t something I can see being as useful as often. Large, long running projects, I see as the first prime candidates. Short running or small projects – sure, you could use it, but would you really spend the time writing the deployment scripts? I’m not saying you couldn’t, but the shorter the project or less complex the deployment the harder it would be to justify spending the time writing the scripts. Of course, if many scripts are pre-written and can work without modification no matter the environment, then this isn’t an issue.   > Should we release it? Hell yeah – I want to blog about this baby J   > What do you think about our approach? Some thoughts of what you’ve mentioned there: -          Does the ‘OriginalQuality’ attribute need to be there in the mapping node? Just the fact that it, say, got to Test would be enough wouldn’t it? If there was some sense of direction in the build qualities (like, we knew that test came before prod) then we could enforce that we only deployed to test when it went UP to test, not down from prod. -          Instead of looking for $/.../Deployment as the place to seek deployment files, could it be specified in the mapping file? Add a DeploymentSourceFolder attribute perhaps. -          Maybe require the full path to the deployment script too. Instead of just naming UnexaminedToTest.ps1”, couldn’t it be “$/…/Somewhere/UnexaminedToTest.ps1”?   I just get nervous whenever I see expected paths. It’s fine if there’s no other way, but if it can be defined easily, that’s how I prefer it.   That’s my comments so far J       From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mitch Denny Sent: Tuesday, 19 September 2006 10:23 PM To: listserver@oztfs.com Subject: [OzTFS] TFS Deployer   Hi all,   We are just about to start developing a tool for TFS called “TFS Deployer”. Basically it’s a windows service that listens for build quality changed notification events from the eventing service. The idea is that when you go from say “Unexamined” to “Ready to Test” a script will execute on a specific computer.   You would then install TFS Deployer onto your test, staging and production systems and it would listen for the events and execute a PowerShell script when a transition occurs. The mapping of computers and transitions would be a file which is under version control near the definition of the Team Build Types. For example:                   $/SystemA/TeamBuildTypes/SystemAContinuous/Development/DeploymentMapping.xml   The file would look like this:                   <DeploymentMappings xmlns=”...”>                                 <Mapping                                                 Computer=”TEST1”                                                 OriginalQuality=”Unexamined”                                                 NewQuality=”Test”                                                 Script=”UnexaminedToTest.ps1” />                                 <Mapping                                                 Computer=”PROD1”                                                 OriginalQuality=”Test”                                                 NewQuality=”Staging”                                                 Script=”TestToStaging.ps1” />                                 <Mapping                                                 Computer=”PROD1”                                                 OriginalQuality=”Staging”                                                 NewQuality=”Production”                                                 Script=”StagingToProduction.ps1” />                                 <Mapping                                                 Computer=”PROD1”                                                 OriginalQuality=”Production”                                                 NewQuality=”Decomissioned”                                                 Script=”ProductionToDecomissioned.ps1” />                 </DeploymentMappings>   TFS Deployer will then read this configuration file whenever you change the build quality inside TFS, and, if the change is relevant to the machine running TFS deployer it will grab *ALL* the files in the $/.../Deployment path and run the script specified.   The script itself will have access to the BuildInfo object so that the script writer can figure out where to get the drop files from the build. The nice thing about this is that PowerShell has some good features. Like the ability to change XML files by doing something like this:   $configuration = [xml](get-content Test.exe.config) $configuration.configuration.”system.web”.compilation.debug = “false” set-content Test.exe.config $configuration.get_OuterXml()   But in addition to that, you can also automate the really challenging stuff. Anyway – do you guys see any use in this tool? Should we release it? What do you think about our approach? OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net