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 

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

Reply via email to