Branch Per Release
Development starts in the Main (or it is sometimes called the Trunk) branch. When a feature or change is requested a branch is created to the 1.0.0-Candidate (or sometimes the V1) branch. After a period of time, when the software is considered ready, it is built to the Test environment. It is then released into Production with the code in the final Production build getting a label to indicate which versions of which files were in that version. This is also known as "tagging". Once built into Production, a "tag" branch is created to the 1.0.0-Release.
Code-Promotion Branching
Development starts with just the Main branch. When the development team is ready to test the application with the business, it pushes the code to the Test branch. While the code is being tested, work on the next development version is carried out in the Main branch. If any fixes are required during testing, they can be developed on the Test branch and merged back into the Main branch for inclusion in the next release. Once the code is ready to release, it is branched again from Test to Production. When the next release cycle comes along, the same is done again. Changes are merged from Main to Test, then Test to Production.
Code-promotion branching works well in environments that have a single version running in Production, but have long test-validation cycles that do not involve all of the development team. This allows development to continue on the next version in Main while testing and stabilization of the build occurs in the Test branch. It also makes it trivial for the development team to look at the code currently on each system. Finally, the branch structure makes it easy to create an automated build and deployment system using Team Foundation Build ( http://msdn.microsoft.com/en-us/vstudio/ff637362.aspx ) that can automatically update the QA/Test environment as code is pushed to the QA branch.
No comments:
Post a Comment