Month: October 2012
We have several strategies branching, Foncton life cycle of the product, the number of people, delivery mode etc.
We can mention: Release Management or CodePromotion ..
the objective of this bill is to address one of the most complex, it is the featuring.
An application may include multiple versions while having active or corrective maintenance needs. How to do ?
Parallel developments can be implemented by several teams. How a team without negatively impacting the other?
=> Set up branches developments
However it is essential to establish a branch management policy to avoid manage conflicting versions during development, to prohibit changes to the validated versions etc.
The installation requires performing the following tasks:
1. Create a development trunk, the trunk is denominated XYZ
Note: the developments are not directly on the trunk, but are on a child branch called Service Pack.
2. Create from a new branch trunk daughter Service Pack denominated 1.YZ
Note: this branch will host the developments dedicated to the first feature.
Event Project: End of the first iteration (The development team estimates that the developments are completed).
3. Create from Service Pack 1.YZ a new child branch Fix denominated 1.0.Z.
Note: This branch contains all the developments dedicated to future bug fixes following the delivery of the target functionality.
4. Create From Fix 1.0.Z. a new child branch Release, 1.0.0 wording.
-This Branch will remain read-only.
-This Branch is the only branch deployed in production environment.
-This Branch represents an image of our delivery.
It makes it possible to trace the different deliveries made.
-It Allows for Rollback operations on version if the need arises (Avoid version conflicts files).
Event Project: Delivery of production
5. Deliver the branch Release 1.0.0 on the production environment.
6. Merge Service Pack 1.YZ to XYZ trunk
Note: At this stage all branches are at the same level of evolution.
Event Project: Bugs occurs on the Release 1.0.0
7. Treatment of bugs can be done in two ways as possible:
Judging that the version is not stable
-Conduct Fixes on Fix branch 1.0.Z.
-Create A new branch Release 1.0.1
-Livrer The Release 1.0.1 branch
-Fusionner Fix 1.0.Z to Service Pack 1.Y.Z.
-Fusionner Service Pack 1.Y.Z. to X.Y.Z. trunk
Note: You can iterate many times: 1.0,1, 1.0.2, 1.0.3 etc.
Judging that the version is stable and it is decided to fix bugs on a new delivery.
-Create From Service Pack 1.Y.Z. Fix a new child branch 1.1.Z
-Apporter Fixes on Fix branch 1.1.Z
-Create From Fix 1.1.Z. a new child branch Release, 1.1.0 wording.
-Livrer 1.1.0 branch
Event Project: An important new feature arrives
8. Create from the trunk a new child branch service pack, label 2.YZ
Reproduce the same organization …
Implementation in Team Foundation Server 11
Add the solution to Source Control