Configure Azure boards for legacy customer
The procedures in this section are valid only for customers onboarded before 6 June, 2024.
The user must select the specific Organizations or Projects they wish to track using DevOps Intelligence, with tracking available at two levels.
- Organization Level - It will track all the projects comprising this organization.
- Project Level - It will track that particular project.
The presented practice is for organizations that were onboarded before 6 June 2024. If your organization was onboarded on 6 June 2024 or after, you are subject to a new process driven by a new onboarding mechanism.The configuration mechanisms that require these processes are in a transition phase driven by the fact that each tool must be individually adapted for the new mechanism, which is more efficient than the legacy mechanism. Both processes are supported until the transition of all supported tools from the old mechanism to the new mechanism is complete.
Click the following link to review the procedure for the new mechanism: Creating an application.
Organization Level Tracking
- Tool engine: Azure DevOps.
- Connection: Select the connection name in the drop-down.
- Search Organization: Selecting here will display a list of organizations the account is part of, and if DevOps Intelligence does not yet track any organization, the user can choose one and select configure to initiate tracking.
- Projects: At the organization level, tracking this field should be empty.
Project Level Tracking
- Tool engine: Azure DevOps.
- Connection: Select the connection name in the drop-down.
- Search Organization: This option will display a comprehensive list of organizations associated with the selected account, highlighting those not yet tracked by DevOps Intelligence. The user can then choose an organization and track its projects accordingly.
- Search Project: Upon selecting this option, a list of projects within the selected organization that DevOps Intelligence does not currently track will be presented. The user can then select the desired project to be tracked and select configure to initiate tracking.
After successful configuration, the table on the configuration page will display the configured settings. Refer to the sample image below for a visual representation of the configuration table.
Repository level tracking
For this type of tracking, certain selections have to be made in the system, as follows:
- Account: Refers to the account through which the tracking will be done.
- Select Workspace for Bitbucket cloud: By clicking here, a list will display showing all the workspaces that the account above selected is a part of. Select any workspace to get the list of projects and repos in it.
- Select Tracking Type: Select Repository for Repo level tracking.
- Search Project: By clicking here, a list will display with all the projects the account selected is a part of, yet DevOps Intelligence still does not track it. Select a project whose repo is to be tracked.
- Search Repository: By clicking here, a list will display all the repos that are part of the selected project and are still not tracked. Then, select any repo that needs to be tracked and select Configure.
If the configuration is successful, a window showing a table with the configuration details will appear.
The Sync Feature scans current data for visibility after configuring credentials periodically. The intervals are set as follows:
- The account Sync Interval is set to 5 minutes: Refresh current data.
- The account Delete Interval is set to 7 minutes. All deleted accounts are updated.
- The history pulled Interval is set to 180 days: Data history.
For more details, see your Delivery representative.
Release terminology in service configuration
This section outlines the terminology and format used for managing releases and severity levels in service configurations. It details the structure of release names, patterns for identifying releases and categorizing severity levels. The content also includes examples and summary tables for quick reference.
- Release formatprefix signifies the starting sequence of characters for releases, with the default value being release-.
- variable signifies the starting sequence of characters for releases, with the default value being empty.
- By default, the release format is all starting with the release-.
- When syncAll enables, or in older service configurations, the system uses the default release format.
- The release format is applicable to identify the release names in issues and the release branches.
Examples of the patterns identified with the given prefix and variable: The system can match various release patterns using the specified prefix and variable.
- For User Story fixed release is in which the User Story is done.
- For Bug fixed release is in which the Bug is Fixed and can be multiple since fixes can be .
- By default, For Azure Boards, a fixed release is identified from the Iteration Path which follows just the release format.
- Found releases
- For Bug found release is in which the Bug is Found, and can be multiple since bugs can be found in old releases.
- By default, Azure Boards found release is identified from the Tags which follows the found_ + release format.
- Severity terminology in service configuration
- The severity data from the source is mapped to the specific categories as severity1,severity2,severity3,severity4.
- By default, severity data is identified from Severity.