Promotion States Overview

Promotion states provide a convenient mechanism for ensuring that the right files or other items are available to the right people at the right stage of this cycle. For example, if a software administrator creates Test and Release promotion states, files that are ready for testing can be assigned to the Test state and files that have been tested successfully can be assigned to the Release state.

In this topic:

About Promotion States

The promotion state feature permits an administrator to create promotion states and associate a view label with each state. An administrator creates a new promotion state configuration which is the basis for a new view or a reconfigured view containing only items with a specified promotion state. Administrators can also set access rights for promotion states. The view labels assigned to a promotion state are usually also used as build labels, so that they can serve as properties in change requests.

The view label for a state can be changed whenever appropriate. It can also be promoted from one state to the succeeding state. For example, although testers may always be using files in the Test promotion state, the files may be from Build 07 in one week and from Build 08 in the next. Users usually configure the project view for their job assignment by promotion state instead of by view label. For example, testers would configure their view to the Test promotion state.

Many features of the application depend on calculations involving times and dates. In particular, labels, configurations, and promotion states are all governed by time and date calculations. If the clients and the Server are not kept synchronized, a number of operations (such as checkouts, file status displays, or label creation) may fail or produce inaccurate or unreliable results.

Back to top

Understanding Access Rights for Promotion States

Each view has its own set of promotion states. Access to these states is controlled by:

• The Define Promotion Model right which is set on the View node of the Access Rights dialog box for both projects and views. See “Granting Access Rights at the View Level”. A user with the Define Promotion Model right can do anything to the promotion model.
• Access rights that govern access to individual promotion states. These are Generic Object Rights and Promotion State Specific Rights which are set on the Promotion State node of the Access Rights dialog for both projects and views. They also appear on the access rights for individual promotion states.

The rights for an individual promotion state are checked at the state level; if necessary, the checking continues at the view level and eventually the project level. If a user is granted a given right at one level, there is no need to check the next.

• When a right is granted at the view level, it applies to all states in the view, unless access is denied at the state level.
• When a right is granted at the project level, it applies to all the states in all the views within the project, unless access is denied at the state or view levels.

Back to top

Example of Using Promotion States

Suppose a software company wants to use the following promotion states to correspond with its use of the application:

Development	Developers work with the tip revisions of files. These files have no view label because they are constantly changing. Many companies do not use Development as a promotion state, because configuring a view to a promotion state, even when the view label for the state is <current>, makes the view read-only.
White Box Test	Testers check both the source code and the compiled executable file for problems that need to be fixed. The source code will have a view label to ensure that the testers are looking at an unchanging set of files. The view label will be attached to a promotion state named White Box Test. (White box testing is testing with full knowledge of what is in the source code.) The executable files are not stored in the application because they can be easily built from the source code. Testers install them from a Builds folder on the network. This folder has child folders named Build 1, Build 2, and so on. Change requests are entered against the executable files only. Developers make repairs in the current source code, sometimes reviewing the files with the view label attached to the Black Box Test promotion state.
Black Box Test	Testers install the executable file, just as they would with white box testing. However, they do not need to see the source code or use promotion states with it. (Black box testing is testing with no knowledge of what is in the source code.) Change requests are entered against the executable files only. Developers make repairs in the current source code, sometimes reviewing the files with the view label attached to the Black Box Test promotion state.
Alpha Test	End users of the software product being developed install the product executable files and test the product in their own environments. Change requests are entered by the alpha coordinator and/or the users against the executable files only. Developers make repairs in the current source code, sometimes reviewing the files with the view label attached to the Alpha promotion state.
Beta Test	Beta testing is similar to alpha testing, but the group of users is greatly expanded because the product is much more stable. Change requests are entered by the beta coordinator and/or the users against the executable file only. Developers make repairs in the current source code, sometimes reviewing the files with the view label attached to the Beta promotion state.
Release	The product is now sold in the marketplace. Users install the executable file and call product support. Product support enters change requests against the executable files only. Developers make repairs in the current source code, sometimes reviewing the files with the view label attached to the Release promotion state. The fixes go into future product releases and service packs to releases already in the marketplace.

In this example, every time the source files are used to produce a build (set of executable files) for testing, a view label is applied to the files to identify them for future reference. It is convenient to use view labels such as Build 1, Build 2, and so on, so that it is clear which source code files were used to create which set of executable files.

Over time, the build or view label associated with a promotion state will change. For example, the Release state may initially be associated with <current>, rather than a view label, because no files are candidates for release and no appropriate view label has been created. When white box testers decide that the set of files that they have examined is ready for black box testing, the view label associated with the White Box Test promotion state will be moved to the Black Box Test promotion state, and so on.

If promotion states are used, developers and testers who look at source code do not need to know that view label Build 120 is currently being checked by white box testers, that the executable files for Build 117 are currently undergoing black box testing, and other details.

Back to top