|
|
|
|
|
|
|
|
|
|
- Overview
- How to?
- Defining a check-in policy
- How the check-in policy works
- Storing and handling the check-in policy
- The different conditions in detail
- "General" tab
- "Automated tests" tab
- "Code metrics" tab
- "Action plan" tab
The SCM gives you the ability to define a check-in policy. This reinstatement policy will apply to: Simply define the criteria to be met for an item to be checked back into the repository. Here are some examples: - No compilation errors,
- Elements tested at least once, etc.
These conditions can be mandatory or not. If one of these conditions is not met, the developer may need to provide an explanation. Defining a check-in policy To define a check-in policy: - On the "SCM" tab, in the "Repository" group, expand "Manage" and select "Check-in policy".
- Select the conditions the checked-in elements must meet. These conditions are grouped by theme on several tabs: "General", "Automated tests", "Code metrics" and "Action plan".
- Define the general options for the check-in policy (these options are displayed regardless of the tab selected):
- Always ignore conditions on the project (wdp): Allows you to ignore the conditions when manipulating the project file (wdp file).
- Ability to ignore the conditions.
- Required comment if a condition isn't met.
- Validate. The check-in policy is automatically taken into account for the current project.
Note: You can also define the check-in policy from the SCM administrator. To do so, right-click the project on the tree structure and select "Check-in policy". How the check-in policy works If the checked-in element does not comply with the check-in policy defined for the project: - if a comment is required, a toast is displayed.
- if one of the other conditions is not met, the following window appears: This window shows the various conditions that have not been met.
If users are allowed to ignore the conditions, they can check "Check in anyway". If a comment is required to ignore the conditions, the validation button in this window will be ungrayed only when the comment is entered in the corresponding field. The "Edit policy..." option allows you to edit the conditions of the check-in policy, if necessary. Storing and handling the check-in policy The check-in policy is stored in the "CheckInPolicy.scm" file found at the root of the project directory. This file is located in the SCM as all the project files. This file can be shared among several projects. Specific rights can be assigned to the file corresponding to the check-in policy (to allow the project manager to modify this file for example). If the "CheckInPolicy.scm" file is located in the parent directory, all the newly created projects will use this check-in policy. Tip: In the case of a branch, you can define a more restrictive check-in policy. The different conditions in detail "General" tab The different check-in conditions in the "General" tab are: - No compilation errors: To be checked in, the element must not contain any compilation errors.
- No compilation warnings: To be checked in, the element must not contain any compilation warnings.
- No compilation information: To be checked in, the element must not contain any compilation information.
- No programming standard errors: To be checked in, the element must not contain any programming standard errors.. This programming standard is defined in the "Compilation" tab of the project description window. For more details, see Project description: Compilation tab.
- The checked-in element must be associated with a task or incident: This option allows you to link the checked-in element to a task or incident in the Project Management Hub.
- A comment must be entered during the check-in operation.
- The project must have been tested (GO) at least once after making any changes: This forces the developer to test their changes.
- Always ignore conditions on the project (wdp): Allows you to ignore the conditions when manipulating the project file (wdp file).
- These conditions can be ignored: Allows the user to ignore check-in conditions (in specific cases where necessary). In this case, the "Comment required to ignore conditions" option can be enabled to require a comment if a condition is not met.
"Automated tests" tab The check-in conditions in the "Automated tests" tab are: - Each element must include at least 1 automated test.
Caution: If this option is selected, it applies to all the elements, even to the project file (".WDP") that contains the project initialization code. - No automated test with errors.
"Code metrics" tab The "Code metrics" tab is used to enter the minimum percentage level to respect for code comments. "Action plan" tab In this tab, you can define the action plan to be executed when the project is checked in. If an action plan is to be executed, specify: - the software factory coordinator,
- the port of the coordinator,
- the user and the associated password.
You can choose from the existing plans in the coordinator.
This page is also available for…
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|