Classification : SEC=UNCLASSIFIED
Hi All,
A client of mine is currently trying to find a branching structure that is
supported by TFS and facilitates their release process. They have some basic
requirements that their structure needs to support.
The Requirements:
* Fixed date, monthly releases of a single large product into an
environment that they control.
* If a sub project (feature/bug fix) does not make it make by the release
date it is pulled rather than extending the release date.
* Only one version of the software is supported at a time. That is each
month, each environment is updated with the latest monthly release.
* Some sub projects are completed within a development month while others
are longer running (i.e. they forward integrate changes each month into their
project).
* They work in an agile environment and wish to avoid code freezes. They
currently achieve this by branching early.
The Background:
Currently they have the following structure:
Below PSP stands for Product Sub Project e.g. product feature or major bug
Main Line --> Integration Line --> PSP 1
--> PSP 2
--> PSP 3
--> PSP 4
So as an example, in preparation for a release PSP 1 and PSP 2 are reviewed,
tested and then reverse integrated (RI) (merge up) into the integration line.
Integrations testing goes well, sponsors sign off and the product is moved into
prod. Somewhere during this process a PSP that is releasing would usually
request a new branch to start working on next months work or even two branches
to support multiple months of work.
Main Line --> Integration Line --> PSP 1 (last month)
--> PSP 1b (current work)
--> PSP 2 (last month)
--> PSP 2b (current)
--> PSP 2c (future work)
--> PSP 3 (ongoing)
--> PSP 4 (ongoing)
Everyone forward integrates (merge down) from the integration line on stable
labels (usually a release label). No one works on the integration line directly.
The Problem:
The issue they have is what to do if a project gets pulled out of the release
at the last minute (after being merged and checked-in to the integration line).
This is usually due to problems beyond their control (e.g. no sponsor sign off
or major bug found late in testing).
How do they reliably rollback multiple merges for a single PSP out of the
integration line? Also bear in mind that there are usually multiple RI merges
per PSP for each monthly release. Rolling back large un-sequential merge
changesets seems unpredictable. Also most other branching patterns I have seen
either have too many baseless merges (only a problem in TFS) or assume non
fixed release dates that are further apart.
So I am turning it over to you. Any ideas?
Regards,
Daniel
**********************************************************************
WARNING
This email message and any attached files may contain information
that is confidential and subject of legal privilege intended only for
use by the individual or entity to whom they are addressed. If you
are not the intended recipient or the person responsible for
delivering the message to the intended recipient be advised that you
have received this message in error and that any use, copying,
circulation, forwarding, printing or publication of this message or
attached files is strictly forbidden, as is the disclosure of the
information contained therein. If you have received this message in
error, please notify the sender immediately and delete it from your
InBox.
AFP Web site: http://www.afp.gov.au
**********************************************************************
OzTFS.com - to unsubscribe from this list, send a message back to the list with
'unsubscribe' as the subject. View the web archives at
http://www.mail-archive.com/[email protected]/
Powered by mailenable.com - List managed by www.readify.net
