USM - IT BRANCHING PRESENTATION

Branch copying a codeline to create a new one codelines evolve independently //depot/main/... //depot/rel1/... Source Target

Merge propagating changes from one codeline to another //depot/main/... //depot/rel1/... Source Target

Best Practices (c’td)  Have a development Codeline –evolves forever –ultimate destination for almost all changes - both maintenance fixes and new features - and –represents the primary, linear evolution of the software product  Use Project Codelines –branched from the mainline, –work that occurs in project branches is either propagated back to the mainline or abandoned

Best Practices (c’td)  Use Release Codelines –Reserved for testing and critical fixes, –Insulated from development –Includes only approved changes –Eventually all changes submitted to the release lines get merged into the mainline.

Best Practices (c’td)  Branch only when necessary  Don’t copy when you mean to branch –Copying is when you copy a set of source files from one codeline and check them in to another as new files. –Copying incurs all the cost of branching - additional entities and increased complexity - but without the benefit of branching support.

Best Practices (c’td)  Give each codeline a policy –Dev codeline is not to be released. –Release codeline should limit changes to approved bug fixes. –Integrate only from release line to dev line.  integrating from dev to release has the potential to introduce unintended changes into the release line.

Best Practices (c’td)  Branch instead of freeze –branch the codeline early enough so that developers can continue their work  Make original changes in the branch that has evolved the least since branching –Change release codeline and integrate into dev line.

How QA will use Vault to Build  QA build Approach –First - we build from the development or main trunk –Then - we branch the code and build from development

Building From Development Trunk  Step 1: QA locks Dev so that no changes can be submitted while the build is in process.

Building Dev, cont.  Step 2: QA Gets latest code from dev Trunk  Step 3: The code is built.  Step 4: After a successful build the code is labeled. –The label is then locked and can only be edited by an administrator.  Step 5: Once the code is finished being labeled the branch is then unlocked.

Release Candidate Builds  Get the tips from the dev branch and then create a release branch.  The release branch is named after version information. –Ex. _

Release Candidate Build, cont.  After the branch is created the code is synced, built, and labeled –Just like it is for a dev build.  The RC branch is not locked right away. –QA performs bug fix builds for a period of time on the RC branch. –No new enhancements are to be added to the branch unless a DR is submitted.

Integrating into Branches  If you have changes that need to be made to the release that was branched, integrate those changes into both the release branch and the Dev Branch. –There are times when you need to integrate into 3 branches. NOTE: Forgetting to integrate to the main trunk and branch(es) is a common mistake.

Locking Branches  At code freeze build, the release’s branch is locked. –Developers are no longer able to submit changes to the branch. –The branch will be unlocked for developers only for approved deviation requests.

Unlocking a Branch  When a branch is unlocked: –You will receive an unlock request from QA informing you that a branch has been unlocked for you. –You will be told the build that will be done to include your changes. –You will receive instructions on how to notify QA when: 1.You are done making your changes 2.You are ready for QA to do the DR build for the release

Complete Process