Cloud Services

DevOps Intelligence

Azure Boards and Azure Repo configuration
Published On Oct 02, 2024 - 1:07 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.

Azure DevOps Cloud

  • Name:
     The local connection name. It could be any string and is used only for reference.
  • Host:
     Azure DevOps cloud Host URL., e.g.,
    https://dev.azure.com
  • Auth Type:
     Authentication to be used for a given Azure DevOps client. It has value as
    token
     can be used for Personal Access token-based Authentication.
For creating the connection, similar steps to the above Azure DevOps configuration have to be followed:
  1. Select
    'Admin'
     in the navigation menu.
  2. Navigate to '
    IAM
    ' and choose 'Connections'.
  3. Select the '
    Add New
    ' button.
  4. Choose the '
    Add Connection
    ' option.
For API token-based authentication requirements, the following fields are necessary in addition to the common fields:
  • Token
     -
    Personal access token
    . Can be generated from -
    your profile and User settings->Personal access token->New Token
  • ProxyID
     -
    UUID for Proxy Adapter
    . Follow the provided steps given in OnPremises Proxy Adapter to integrate Proxy Adapter connected to On-Premise Azure DevOps.
While creating a new token, the
Organization
 field has to be selected as 'All accessible organizations'.
The personal access token needs permission for
Work Items
,
Code
 and
Project and Team
 fields are enough.

Azure DevOps Server

  • Name
     - Local connection name. It could be any string and is used only for reference.
  • Host
     - Azure DevOps cloud Host URL., eg.
    https://azure.server.testhost.com
  • Auth Type
     - Authentication to be used for a given Azure DevOps client. It has its value as
    token
     and can be used for Personal Access token-based Authentication as well.
For creating the connection, similar steps to the above Azure DevOps configuration have to be followed:
  1. Select
    Admin
     in the navigation menu.
  2. Navigate to
    IAM
     and choose 'Connections'.
  3. Select the
    Add New
     button.
  4. Choose the
    Add Connection
     option.
  5. Azure DevOps Server
     - Choose if the account belongs to the Azure DevOps server version.

Configuration

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