Hi Mark,
>From a build perspective a state change is when you go from one state (Unexamined) to another (DevelopmentStaging). You can wire-up to TFS events to get notified when this happens - this is what we have done with TFS deployer. So we can effectively say: From: Unexamined To: DevelopmentStaging Execute: SomeScript.ps1 On: Server1 The interesting thing about this is that we can trigger deployments to entire farms of machines - for example: From: Unexamined To: DevelopmentStaging Execute: DeployWebCluster.ps1 On: Server1 From: Unexamined To: DevelopmentStaging Execute: DeployWebCluster.ps1 On: Server2 From: Unexamined To: DevelopmentStaging Execute: UpdateDatabase.ps1 On: Server3 TFS Deployer will go execute the scripts then call back when its done. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, 14 February 2007 12:25 AM To: [email protected] Subject: RE: [OzTFS] Release Management with TFS Mitch, When you talk about state changes, do you mean that you have a specific deployment work item that you transition, or is this integrated into the build system? I haven't dug deep into the build system yet. M ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mitch Denny Sent: 13 February 2007 12:04 To: [email protected] Subject: RE: [OzTFS] Release Management with TFS Hi Justin, I use TFS for release management every day and its one of the areas that I think that TFS really shows off how important integrate is. From a release management perspective the central concept is "The Build", or more specifically the line items under Team Build Types that are generated every time a build is performed. When you talk to developers, testers, and system administrators about which version of the code is being deployed always refer to the build number i.e. FooSetup_20070213.9, this is much better than some made up version number because it is effectively guaranteed by TFS to be unique. Once you have got everyone talking about builds you need to start defining how the builds propagate through your development, test and production environments. This is what the Quality levels are good for. I use the following: * Unexamined * DevelopmentStaging * DevelopmentAccepted * DevelopmentRejected * TestStaging * TestAccepted * TestRejected * ProductionStaging * ProductionAccepted (this is live!!) * ProductionRejected * ProductionDecomissioned What you then do is define the rules by which it can transition between those stages and who is responsible for flicking the bit. In general I think that the dev lead is responsible for the first four, the test manager is responsible for the next three, and the system administrators are responsible for the last four. In environments that I configure these have a very real impact because we are using TFS Deployer to automatically deploy things. For example - when we transition from Unexamined to DevelopmentStaging we actually automatically install the package onto a server. If we reject it (DevelopmentStaging to DevelopmentRejected) the package is actually uninstalled. Effectively the DevelopmentRejected, TestRejected, ProductionRejected and ProductionDecomissioned are parking states where it's possible to run reports to find out how many builds actually make it through testing. It just takes a little discipline to make it all work. I've got a slide deck (1.4MB) that describes how it all hangs together if you want a copy (goes for everyone - just shoot me an e-mail off-list - [EMAIL PROTECTED]). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Butcher, Justin Sent: Tuesday, 13 February 2007 4:59 PM To: [email protected] Subject: [OzTFS] Release Management with TFS Has anyone tried to use TFS for Release Management? Care to share any issues, experiences? **************************************************************** IMPORTANT The information transmitted is for the use of the intended recipient only and may contain confidential and/or legally privileged material. Any review, re-transmission, disclosure dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may result in severe penalties. If you have received this e-mail in error please notify the Privacy Hotline of the Australian Taxation Office, telephone 13 28 69 and delete all copies of this transmission together with any attachments. **************************************************************** 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 This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. 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
