Cloud Services

DevOps Intelligence

Azure Boards and Azure Repo configuration
Published On Nov 05, 2024 - 1:34 PM

Azure Boards and Azure Repo configuration

Learn how to configure DevOps Intelligence to collect data generated by Azure Boards and Azure Repo, extending the single pane of glass DevOps Intelligence affords in your hybrid IT estate.
A configured Azure DevOps connection is essential for successful data extraction from Azure Boards in the context of DevOps Intelligence. Similarly, the requirement is to set up an Azure DevOps Cloud and Server connection to enable effective data integration from Azure Boards and Azure Repos.
Anticipate future support for the following Azure tools as integral elements of our expanding DevOps Intelligence offering:
  • Azure Pipelines
    : This powerful tool enables you to build, test, and deploy using CI/CD that is language, platform, and cloud-agnostic. It offers seamless connection capabilities with GitHub or any other Git provider for continuous deployment.
  • Azure Test Plans
    : These tools instill confidence in your testing and shipping process. Utilize manual and exploratory testing tools to ensure robust product delivery.
  • Azure Artifacts
    : This feature allows you to create, host, and share packages within your team and effortlessly add artifacts to your CI/CD pipelines with a single click. The integration of these advanced tools extends the robustness of our DevOps Intelligence platform and ensures streamlined operations and superior output quality.
  • Access Rights
    : The connection should possess read permissions for the specific projects and work items we intend to synchronize, ensuring the necessary access for data retrieval.
The following items are prerequisite to integration:
  • Azure DevOps Account: User must have an active Azure DevOps account. If user don't have one, user can sign up for free on the Azure DevOps account website.
  • Organization Membership: Ensure that Azure DevOps account is part of at least one organization. User need to be a member of an organization to access its projects and repositories.
  • Access Policy as Platform Administrator and DevOps Intelligence Administrator: Ensure that the user creating the connection has the necessary access policies. The Platform Administrator role is required to create and manage connections effectively. The DevOps Intelligence Administrator role is also required to create and manage configurations.
DevOps Intelligence currently supports Azure DevOps APIs with version 7.0. Ensure that your Azure DevOps account is on a compatible version to ensure optimal functionality.

Integration of Azure Boards and Azure Repo with DevOps Intelligence

The process for onboarding Azure Boards comprises the following steps, each of which is a multistep procedure:
  1. Create a Personal Access Token.
  2. Create a connection.
  3. Configure the application.
  4. Onboard the Azure Board technical service.

Create a Personal Access Token

Use the following procedure to create a Personal Access Token:
  1. Navigate to Azure DevOps homepage.
  2. Click
    Access User settings
     →
    Personal access token
     →
    New Token
    .
  3. Ensure the Organization field is set to All accessible
    organizations
    .
  4. Grant
    Read
     permissions for
    Work Items
    ,
    Code
     and
    Project and Team
     fields.
  5. Alternatively, for full access, choose
    Full Access
     to use the same PAT for pulling data from all Azure APIs.

Create a connection

To pull data from Azure Boards, you must establish a connection between DevOps Intelligence and GitHub Actions. Use the following procedure:
  1. Click on
    Settings
     →
    IAM
     →
    Connections
     →
    Add New
     →
    Add connection
    .
  2. Select
    Add Connection
    .
  3. For Azure Boards Cloud and Azure Boards Server:
    1. Provide a local connection name.
    2. Set the Host as the Azure DevOps cloud Host URL
    3. Choose Authentication type as 'token'.
  4. For Azure Boards Server (server as host), use the toggle switch to set the host information to
    Azure DevOps Server
    .
  • When the sync-all is enabled, all the organization and repositories for which the user has access will be synced.
  • When the Archive is enabled, the connection is archived for future use.

Configuring DevOps for Azure boards, recent customers

The procedures in this section are valid only for customers onboarded 6 June, 2024 or after. Procedures for legacy customers are provided in the subsequent section Configure DevOps Intelligence for GitHub, legacy customers.
Having created a connection, you must now configure the application.Use the following procedure:
  1. Click
    Settings & Utilities
     →
    Application Configuration
    .
  2. Select an existing application or create a new application.
  3. Navigate to
    Add Tools
     step.
  4. Select the phase as
    Plan
    .
  5. Click
    Add Tool Configuration
    .
  6. For Tool engine select
    Azure Boards
    .
  7. Complete the configurations, presented in the following tabs:
    1. Release
    2. Work Item Format
    3. Bug Formats
    4. Bug Severity
    5. Bug Status
  8. Click
    Add Configuration
    .

Onboarding the Azure Board technical service

You must now onboard the technical service. Use the following procedure:
  1. Navigate to DevOps Intelligence →
    Settings & Utilities
     →
    Application Configurations
    .
  2. Click on Overflow menu for the chosen application and click on Onboard Technical Service.
  3. Select the plan for which you want to configure Azure Board. Note It would display all the phase for which this tools has been configured for the application.
  4. For
    Tool engine
    , select
    Azure Board
    .
  5. For
    Connection
    , select the appropriate connection name from the dropdown list.
You must also select tracking for organizations and repositories.
Organization tracking
For Organization tracking, use the following procedure:
  1. Select an existing application or create a new application.
  2. Navigate to the "Add Tools" step.
  3. For
    Phase
    , select
    Plan
    .
  4. Click
    Add Tool Configuration
    .
  5. For
    Connection
    , select the appropriate connection name from the dropdown list.
  6. Select the Organization you want to track.
Leave the
Projects
 field unpopulated.
Repository Tracking
For Repository tracking, use the following procedure:
  1. Navigate to DevOps Intelligence →
    Settings & Utilities
     →
    Tools Configuration
     →
    Add Configuration
    .
  2. For
    Tool Engine
    , select
    Azure DevOps
    .
  3. For
    Connection
    , select the appropriate connection name from the dropdown list.
  4. From the
    Organization
     field, select the Organization containing the repository you want to track.
  5. From the
    Project
     field, select the repository you want to track.

Deleting the Azure Board technical service

The administrator may, at will, delete the GitHub technical service. Use the following procedure:
  1. Navigate to DevOps Intelligence →
    Settings & Utilities
     →
    Application Configuration
    .
  2. Expand the application to view all associated phases.
  3. Click the Overflow menu against the
    Plan phase
    .
  4. Click
    Delete Technical Service
    .
  5. For
    Tool engine
    , select AzureBoard.
  6. Select the Organization and Repository.
  7. Click
    Delete
    .

Configuring Azure Boards for DevOps Intelligence, legacy customers

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: Application configuration: recent customers

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.
  1. Release Format
    • prefix
       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.
  2. 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.
  3. 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.
  4. 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
      .
Do you have two minutes for a quick survey?
Take Survey