Working-Sets #14296583/HEAD / v13626 |
Tags:
Working Sets
Working-Set feature replaces and extends usability and feature sets of Branching feature. Branching feature is no longer supported and removed in codebeamer 21.04 version.
Working-SetsTable of Contents
IntroductionThe definition of a complex product contains dozens of components. A component usually consists of dozens of specifications like Requirements Specifications, Test Specifications, Design Specification and others managed in multiple codebeamer trackers. For each of the trackers, the right version or variant has to be selected to result in a consistent component. Usually, users will work in the context of a specific component and are interested only in specification versions relevant in that context. Considering the number of specifications involved in a complex project the user will not be able to work efficiently if he additionally has to consider different versions and variants of specifications. Working-Sets are supposed to fill that gap by enabling the grouping of different specification versions and providing a context to work in to the user.
The main concepts of Working-Sets are:
See Working-Set Use Cases for more information on high-level Use Cases supported by Working-Sets. License and PermissionsBranching license is required to be able to use the Working-Set feature.
Your license must include the Working-Set option to access the Working-Set feature. Codebeamer defines two Working-Set related project permissions:
Creating Working-SetsHow to Create Working-Sets
Working-Set creation runs in the background. This means that the created Working-Set is not available immediately, but you will receive a notification email and a pop up message will be shown in the browser.
You can create a Working-Set from two places (but only if you have the Working-Set - Admin project permission).
This will show you a popup editor dialog like this:
The fields of this form:
Name of the Working-Set also used to name the baseline of the Working-Set See baseline section.
When all set click on Next (Select Trackers) to navigate to Trackers Selections Window:
Selecting trackers:
Click 'Next (Done)' to navigate to the summarize page:
Working-Set creation runs in the background. This means that the created Working-Set is not available immediately. User will receive a notification email and a pop up message will be shown in the browser:
If any error happens during creation user will be notified also via email and pop up message.
ValidationBefore creating or extending the Working-Set codebeamer will validate that:
Background jobBoth Working-Set creation and extensions run in the background. The Working-Set is unavailable until the job is done. When the job is finished a notification email and a pop-up notifies the user. By default Working-Set jobs run sequentially, one after another.
In case of a server restart, the background job can recover from an inconsistent state. Before running the job it checks if it was running before and if so, it cleans up the inconsistent state and starts the process from the beginning. Baseline creationDuring Working-Set creation/extension two type of baselines are used:
Migrating Existing Branches / Orphan branchesIn previous versions of codebeamer, it was possible to create branches without Working-Sets. As of now, branches can be built by creating a Working-Set only which must be associated with another Working-Set to be accessible for the users. To continue working with existing branches, assign them to an existing or a new Working-Set.
E.g. If there is an orphan branch of a Tracker (e.g.: Tasks) the does not belong to any Working-Sets, it can be chosen if the parent Tracker is selected.
In this case, the already existing branch is used and behaves as an included Tracker, therefore, no new branches will be created for that. If there are more than one orphan branches belonging to a Tracker, only one of them can be chosen to be included.
Having the branches migrated into Working-Sets, only new Baselines are usable. To be able to use old Baselinescreated for the branch, running the relevant one of the following scripts is necessary:
Reference RewritingDuring creation of a Working-Set references to items and the corresponding configurations will be rewritten according to following rules. Despite the fact you can configure references outside of working-sets, currently you can select reference items only within the current working-set. Included Trackers
Shared Trackers
Excluded Trackers
Using Working-SetsNavigating between Working-SetsYou can navigate between Working-Set using the combo-box in the header of the codebeamer user interface.
Selecting a Working-Set will open the same page in the requested Working-Set. The header will use the color configured for the Working-Set to simplify distinguishing different Working-Sets.
When switching between Working-Sets, a warning pop up message is shown like the one below:
You can also change Working-Set in an item details view if and only if the item being viewed has a corresponding version in the Working-Set to be switched to. In this case the item shown will also be switched to the version of the target Working-Set. BaselinesScreens that do include the Working-Set selector show the selected baseline as part of the selected Working-Set.
The actions for the baseline such as leaving the baseline or opening the "Baselines and Branches" dialog can be reached by opening the Working-Set selector.
BadgesTrackers that are not branched in the Working-Set but shared with the Default Working-Set or the parent Working-Set are marked with the Shared badge.
References that are pointing to items that are not part of the current Working-Set are highlighted with a yellow background. Following such references will usually lead to switching to the Working-Set containing the target item.
Most views listing item, for example table view use a badge to indicate the Working-Set that does contain the item right next to the name. Modifying Working-SetsEditing Working-Set PropertiesSelect the Working-Set to be edited using the combo-box and hit the icon next to the combo-box:
Select 'Edit''' to edit Working-Set properties:
Update Working-Set dialog:
The fields of this form:
Renaming the Working-Set also changes the name of the Working-Set baseline. See baseline section.
Click 'Save' to save changes or 'Cancel' to close the dialog without saving. Adding new Trackers to Working-SetsNewly created or previously excluded trackers can be added to existing Working-Sets. Generally all trackers have to be created in the "Default Working-Set", the option to create trackers in any other Working-Sets is disabled.
Select the Working-Set to be extended using the combo-box and hit the icon next to the combo-box:
Select 'Add Trackers''':
'Add Trackers' dialog:
Modifying already added trackers:
Adding new trackers:
Click 'Next (Done)' to navigate to summarize page:
Select 'Update Working-Set' to save modifications or 'Previous' to return to the previous page.
Adding new trackers to the Working-Set runs in the background. This means that the created Working-Set is not available immediately. User will receive a notification email and a pop-up message when the job is done
Deleting Working-SetsSelect the Working-Set to be deleted using the combo-box and click the gear icon next to the combo-box:
Select 'Delete':
Confirm delete by 'Yes, delete' or select 'Cancel' to return:
Copying Configurations into Working-SetsSince Codebeamer release HUSKY, the configurations of any parent working-set can be copied into the derived working-sets. It is highly recommended to edit the configurations of the default working-set and copy it to all the relevant derived working-sets.
To be able to copy configurations into working-sets, the following permissions are required:
If any of the permissions is missing, the Copy Configuration function is disabled. To copy the configurations into working-sets,
When performing a configuration copy, all the settings on the Permissions, State Transitions and Fields tabs are copied into the selected working-sets.
The Copy Configuration function can be applied within the whole working-set hierarchy. If a working-set has only one child working-set, by selecting the child working-set to copy a configuration into, its parent working-set gets automatically selected to ensure consistency. In case more children working-sets are available within a parent working-set, the user can select which child or children working-sets should the configuration be copied into. Clearing the selection of a parent working-set removes the selection of the child or children working-sets as well.
Once the relevant working-sets are selected and the user clicks Copy, a background job performs the configuration copy.
Since working-set external references are not allowed in working-sets, the field configurations and values of the reference fields are updated accordingly after the configuration copy is executed. For example, a reference field in the default working-set collects the references from the default User Story. After copying its configuration into, for instance, Working-Set 1.2, its reference field gathers references from the Working-Set 1.2 User Story.
Limitations:
Reviewing and Merging ChangesWorking-Sets can be used to work on different versions or variants of specifications in parallel without interference. When working on the same specification in different Working-Sets in parallel it is essential to efficiently identify and merge changes implemented on the different Working-Sets.Modifications in Working-SetsInitially (after creating the Working-Set) the items on the Working-Set are the exact copies of the original items. Whenever you update or create an item either on the Working-Set or the parent you will get notification badges on the document view. An example:
The possible badges are:
Clicking on the Updated badge will show the actual differences in a dialog, and you can use this dialog to merge the items one by one:
These badges are cleared after merging between the Working-Set and its parent. Merging Working-Set Trackers
You can merge to a tracker or branch only if you have the Working-Set - Admin permission on the target
In some cases, it is useful to get the changes from a Working-Set tracker to another tracker. An example: the quality team finds a bug in a variant and verifies that the same bug exists in other variants too. Instead of fixing the bug in each variant, it might be useful to fix it in only one of them and apply the fix to the other variants. This is one case when merging is useful. Every tracker included in a Working-Set (i.e. not shared) is associated with a branch of that tracker in the background. The merging process consists of the following steps:
Selecting a branch to mergeIn codebeamer, you can merge between any parent-child branches. You have two options for starting a merge:
Alternative way to merge branchesYou can also start a merge through the "Baselines and Branches" dialog, which can be opened using the button in the action bar of a tracker page.
You can see the above page when selecting the "Branches" tab. Here you can see all the branches (even those not associated with a Working-Set) of the current tracker. You can select two branches for merging (any two can be selected independently from the current branch, but the current is selected by default). If one branch is selected, the other branch must be an ancestor or a descendant branch (the other ones will be disabled). The merging can be started by clicking the "Merge branches" link. Executing the mergeOn the merge dialog, you can see all the differences between the selected branches.
The dialog shows the different field values and the badges. To see and merge relevant changes only, choose from the following Filters:
Updating Downstream References during a MergeWhen working on Working-Sets you might add new downstream references to some items. In some cases it makes sense to update these references during a merge so that they also reference the master or parent item. For example you find a bug related to a user story on one of your branches. You fix the user story and decide to merge the fixes to the Master branch. Since the bug is also present in the Master version you would like to update the bug during the merge as well. To make this process easy we added a New Downstream References section to the diff page:
This section shows all the Downstream references of an item that point to the branched version but not to the Master/parent item. You can select some of the checkboxes to update those references. You can also update these references without selecting any other changes of the branch item. There are some restrictions:
Skipping fields during mergeThere are some fields that might change frequently but are not as important so that you want to merge them every time. For such fields you can check the Omit merge option on the field configuration page.
If this option is checked then the fields are shown in a separate group. Of course you can open this group and click the apply button for them as well.
|
Fast Links
codebeamer Overview codebeamer Knowledge Base Services by Intland Software |
This website stores cookies on your computer. These cookies are used to improve your browsing experience, constantly optimize the functionality and content of our website, furthermore helps us to understand your interests and provide more personalized services to you, both on this website and through other media. With your permission we and our partners may use precise geolocation data and identification through device scanning. You may click accept to consent to our and our partners’ processing as described above. Please be aware that some processing of your personal data may not require your consent, but you have a right to object to such processing. By using our website, you acknowledge this notice of our cookie practices. By accepting and continuing to browse this site, you agree to this use. For more information about the cookies we use, please visit our Privacy Policy.Your preferences will apply to this website only.
Note that user-behavior analytics are being captured on this server for the purpose of improving the Codebeamer user experience.