Team process preconditions for Engineering Workflow Management source control

Operation: Deliver (client): Runs before delivery of baselines, change sets, or on a component replacement. Affects all components in streams that are owned by the process area.

The Deliver (client) precondition runs on the client before the server is contacted about the delivery. This operation is appropriate for preconditions that require client state to run, such as detecting compilation errors, or whether the most recent JUnits completed.

Operation: Check-in (server): Runs before check-in of resources. Affects components that are owned by the process area. An extension point for check-in operations is also available so that you can write your own preconditions.

The following server-side preconditions are available for source control check-in operations. You can set them in either the Eclipse client or web client.

Operation: Deliver (server): Runs before delivery of baselines, change sets, or on a component replacement. Affects all components in streams that are owned by the process area.

The Deliver (server) operation runs on the server before change sets are added or removed from a component. The operation is run on the set of change sets that are being added to (or removed from) a component.

Verifies that change sets that are linked to a work item have a minimum number of approvals. The approvals are specified by role and must be complete at the time of delivery.

The precondition ensures that a minimum number of approvals are received before the associated change sets can be delivered to a stream.

Verifies that change sets have work item links and/or comments. The precondition can be configured to require change sets to have a comment or a work item/change request (OSLC link).

If a work item is required, the owner and target iteration can be verified. Although it makes sense to constrain the work item owner and iteration in development streams, this requirement is not true of integration streams, since:

• Change sets are often delivered by release engineers, so the owner identity check blocks the delivery.
• If change sets were delivered to the development stream in previous iterations, then associated work items were likely targeted to those iterations.

Ensures that you do not have incoming changes at the time of delivery. You can limit the scope of this precondition to specific components.

This precondition ensures to allow delivery only when the source stream or workspace is synchronized with the target stream or workspace. It also ensures that you have all the changes in a stream or workspace before you complete a delivery operation and you can test with the full stream content. This scenario works well in IDEs where source is built automatically after an accept operation.

Limits the roles that are allowed to deliver change sets to components in a specific stream. This restriction prevents teams that do not own a component from delivering changes to it. You can specify which repository workspaces or streams can deliver changes to a component.

When multiple teams are flowing into a single integration stream, it is useful to limit delivery privileges to the team that owns each component, rather than allow any developer to deliver to any component.

When delivering change sets, ensures that associated work items match a query.

This precondition verifies that the work items associated with each change set are listed in a work item query result. The precondition applies to all streams that are owned by the project/team area for which that precondition is set.

The query allows complex validation of a work item's fields, including custom attributes. Options on the precondition allow the process author to set whether each change set must have at least one matching work item or whether every work item must match.

Work item queries can match only work items in their process area. The precondition allows the process author to control how work items from other process areas are handled: either allowed or denied.

Prevents changes to files, folders, or symbolic links that are based on their name. The precondition can be scoped to specific components in a stream.

Items can be matched with operators (* indicating zero or more characters, or ? indicating exactly one character) or Java regular expressions. Depending on the precondition's configuration, matching items are either allowed (all items in a change set must match the pattern) or blocked (no items in a change set can match the pattern).

Regular expressions are matched in the manner of a search: the regex matches a substring of the item name. To require the entire name to match, use a caret (^) and dollar sign ($) to anchor the regex to the start and end of the string.

Limit the roles that are permitted to change specific files. The precondition can either operate in a mode where the changes to the selected files are allowed or denied.

Restricting changes to files allows teams that operate under a lock-down mode to prevent changes to portions of their streams at specific times. Process authors can use this precondition to keep plug-in dependencies stable by matching MANIFEST.MF files or limiting string changes after a string freeze.

Ensures that files contain a specific string on delivery. Only files with names that are matching a specific pattern are checked.

On teams where ownership must be asserted within source code, this precondition allows process authors to force every source file to contain a copyright string.

Ensures that change set authors do not approve their own work items.

This precondition prevents a change set from being linked to a work item with an approver who is also the change set author. The Require Disinterested Approvers preconditions on work item save prevents an approver from being added to a work item already linked to change sets with the same author. Use these two preconditions together.

Stops incomplete change sets from being associated with work items.

This precondition is useful in processes that require approvals because active change sets can be modified after the approval is granted.

Ensures that change sets cannot be linked to work items that already have approvals. This requirement prevents users from using an approved work item to deliver more change sets.

Teams that want to enforce strict process on work items (using Require Work Item Approval, for example) can use this precondition to ensure that all change sets are individually approved before flowing into a stream.

By default, the precondition blocks linking to any work item with approvals, regardless of the approval state. To allow change sets to be linked to work items in specific approval states, add them through the Allowed Link States configuration.

Prevents change set links from being added to or removed from closed work items.

Teams with a strict work item lifecycle can use this precondition to stop change sets from being associated or dissociated with a work item whose work is complete.

You can also use this precondition to add a comment to a work item when links are added/removed and to ensure that the project area of a stream contains the user who is delivering the changes.