Seapine Labs
Personal tools

Using Labels in a Waterfall Model

From Seapine Labs

Jump to: navigation, search

The waterfall branch model is a very popular and effective way to handle web development in Surround SCM. The waterfall model is explained in more detail in the Branching Strategies article.

Changes are rebased from stage to stage until it reaches the production branch.

The advantage of using a waterfall approch (changes rebased down the tree) as opposed to a reverse waterfall (changes are promoted up the tree) is that rebase gives you more options than just rebase by the lastest version (like promotes).

The label enhancements in version 2009 leave you without an excuse to not employ the waterfall model for web development.

Contents

[edit] The use case

In this example, we will use the trigger set up in this other example and create a global label everytime a check in is attached to a defect on the development branch (Mainline).

Changes will then be rebased based on label (defect number) to the QA branch for testing. Those files are also added to the same label.

[edit] Step 1: Check in file

After changes are made to three files, they are checked in and attached to defect # 18.

Figure 1 below shows a screenshot of this process:

Figure 1 - Attach to defect on check in
Figure 1 - Attach to defect on check in


The checking proccess is finished, the label list shows that we now have a label for defect 18:

Figure 2 - Label List
Figure 2 - Label List

Further examination of the label shows that all three files are now associated with this label.

Figure 3 - Files in label
Figure 3 - Files in label

[edit] Step 2 - Rebase files

The next step is to rebase the file into the QA branch, so our QA team can verify the changes before moving them to staging.

Once the changes are verfied, they can be moved to the Staging branch. From the QA branch, Rebase Branch... is selected and the method By label is chosen. The ttp:18 label shows up as an option.

Figure 4 - Rebase dialog
Figure 4 - Rebase dialog

On the Rebase Preview dialog we can see that the only the three files associated with the label are going to be rebased.

Figure 5 -  Rebase Preview dialog
Figure 5 - Rebase Preview dialog

The advantages of rebasing by label is that you will only rebase the files associated with the label, and that it will not contain any changes made to the files after the label was applied.

[edit] Step 3 - Label rebased files

After the files are rebased on the QA branch, add them to the same label. Figure 6 below shows the Add to Label dialog.

Figure 6 - Add to Label dialog
Figure 6 - Add to Label dialog

After the rebased files are applied to our label, when we pull up the file list for the label, we can see now the files on both branches show up. This is a way that we can show that the fix for defect 18 has made it to the QA branch.

Figure 7 - Files in label
Figure 7 - Files in label

[edit] Step 4 - Repeat as nescessary

Now that the files on the QA branch are added to the label, when we are ready to rebase to the Staging branch, we'll be able to rebase based on the same label.

Once the files on the staging branch are labeled, we will also be able to rebase into the Production branch based on that label. Once those files are applied to the label, we can see in the file list that the fix for defect 18 was applied to three files and the change exists on all three branches.

Figure 8 - Files in label
Figure 8 - Files in label

[edit] What if the change fails QA?

Remember that you can remove files from labels or update the label with newer versions of files. This can help you in the scenario where the change fails the QA process.

The removal of the file from the label will have to be done manually. The batch file used in this example can not handle adding a file to a label if a previous version of the file is already associated with the label.














Issue Management Software | Source Code Control Software | Test Case Management | Requirements Management Software