RE: [OzTFS] TFS Deployer

[Mitch Denny]

Hi Geoff,   Its interesting. I think that any piece of software that has ongoing cycles of development could use a package like this because deployment is something that you just have to get write in the longer term. Even inside Readify we have a prime use case for it. For example we have a custom timesheeting front end that sits on top of Microsoft CRM which needs to be deployed to a server on a semi-regular basis. At the moment the various knobs that have to be twisted to support deployment are really in the head of only a few people, but being a consulting services organisation we tend not to have any one person on the bench for an extended period of time – so far the CRM/Timesheet system has been through about four or more developer hands.   With the original quality and new quality stuff I wanted to head down this path of being able to have some kind of simple workflow. For example – if you tried to go from Unexamined to Released then no script would fire because that wasn’t a defined transition. It would also support those people who need to do things like peal back deployments in staging environments as they go to production, and to do that you need to know what state it was in previously.   The reason for having the magic directory path is that it sits underneath the TeamBuildTypes tree and since build quality has a one to one relationship with a build instance it kind of made sense. The mapping file would be on a per build basis which also makes sense because each team project would want to manage the deployments for various builds separately.   I guess there isn’t any reason not to support full paths to the scripts, but it does introduce complexity. My idea was that the entire deployment directory would be fetched from TFS when the deployment kicked off, so any of the utility scripts and stuff that would be required could just be placed in there. Without that well known location then we’d need to build a manifest of all the files required for the deployment script (its usually a ps1 file plus an assortment of other “stuff”).   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Appleby Sent: Wednesday, 20 September 2006 2:52 PM To: listserver@oztfs.com Subject: RE: [OzTFS] TFS Deployer   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 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