Terraform Provider for Azure DevOps

repository·main·Indexed 19 days ago

https://github.com/microsoft/terraform-provider-azuredevops

The Terraform Provider for Azure DevOps enables developers to manage Azure DevOps resources, such as projects, repositories, and build definitions, using Terraform configuration files. It supports provisioning CI/CD infrastructure, including GitHub service connections and YAML pipelines, and provides tools for building and testing the provider via Make or PowerShell.

Tokens
176.1K
Snippets
528
Records
934
Agent score
63%

What's inside terraform-provider-azuredevops

  1. Manage an agent queue with azuredevops_agent_queue

    main

    The azuredevops_agent_queue resource manages an agent queue within Azure DevOps. This is functionally equivalent to adding an Organization-defined agent pool to a specific project via the Azure DevOps UI.

    Important Note on Authorization: Creating a queue does not automatically authorize it for use by all pipelines in the project. To grant access to all pipelines, you must use the azuredevops_resource_authorization resource alongside the queue.

    resource "azuredevops_agent_queue" "example" {
      project_id    = azuredevops_project.example.id
      agent_pool_id = data.azuredevops_agent_pool.example.id
    }
  2. Manage Azure DevOps Git repositories with `azuredevops_git_repository`

    main

    The azuredevops_git_repository resource manages a Git repository within an Azure DevOps organization. It supports creating clean repositories, forking existing repositories, and importing repositories from external sources (like GitHub).

    Important: Handling Imported Repositories

    When importing an existing repository into Terraform state, running terraform plan will often detect differences in the initialization block. To prevent Terraform from attempting to re-initialize or recreate the repository, you should use a lifecycle block with ignore_changes on the initialization argument.

    Initialization Behavior

    • If initialization.init_type is Uninitialized: Changing source_type or source_url will not recreate the repository, but will instead initialize it.
    • If initialization.init_type is not Uninitialized:
      1. Updating init_type will recreate the repository.
      2. Updating source_type or source_url will recreate the repository.
    resource "azuredevops_git_repository" "example" {
      project_id     = azuredevops_project.example.id
      name           = "Example Git Repository"
      default_branch = "refs/heads/main"
      initialization {
        init_type = "Clean"
      }
      lifecycle {
        ignore_changes = [
          initialization,
        ]
      }
    }
  3. Manage Visual Studio Marketplace service endpoints with azuredevops_serviceendpoint_visualstudiomarketplace

    main

    The azuredevops_serviceendpoint_visualstudiomarketplace resource manages a Visual Studio Marketplace service endpoint within an Azure DevOps organization. This endpoint is used for packaging and publishing Azure DevOps and Visual Studio extensions to the Visual Studio Marketplace.

    Prerequisite: To use this service endpoint, you must install the Azure DevOps Extension Tasks in your Azure DevOps organization.

  4. What is a managed identity and how does it work with Azure DevOps?

    main

    Managed identities for Azure resources allow Azure resources to authenticate to services supporting Azure Active Directory (Azure AD) without storing credentials on the resource.

    Key Concepts:

    • System-assigned identity: The lifecycle of this identity is tied to the Azure resource; it is created when the resource is created and deleted when the resource is deleted.
    • User-assigned identity: An independent Azure resource that can be assigned to one or more Azure resources.
    • Authentication Flow: The client uses the Azure Instance Metadata Service (IMDS) endpoint to request an access token. To bootstrap the connection, you only need the subscription ID and tenant ID.

    Prerequisite: Before using a managed identity with the provider, you must manually add the identity to your Azure DevOps Organization as a service principal.

  5. Configure Git permission levels (Project, Repository, or Branch)

    main

    You can control the scope of Git permissions by varying the arguments provided to azuredevops_git_permissions:

    1. Project Level: Applies to all Git repositories within a project (existing or new).

      • Required Argument: project_id.
    2. Repository Level: Applies to a specific repository and all its branches.

      • Required Arguments: project_id, repository_id.
    3. Branch Level: Applies to a specific branch within a repository.

      • Required Arguments: project_id, repository_id, branch_name.
    # Project Level
    resource "azuredevops_git_permissions" "project-level" {
      project_id = "project-id"
      principal  = "group-descriptor"
      permissions = { CreateRepository = "Deny" }
    }
    
    # Repository Level
    resource "azuredevops_git_permissions" "repo-level" {
      project_id    = "project-id"
      repository_id = "repo-id"
      principal     = "group-descriptor"
      permissions   = { CreateTag = "Deny" }
    }
    
    # Branch Level
    resource "azuredevops_git_permissions" "branch-level" {
      project_id    = "project-id"
      repository_id = "repo-id"
      branch_name   = "refs/heads/master"
      principal     = "group-descriptor"
      permissions   = { ForcePush = "Deny" }
    }
  6. Authorize Visual Studio Marketplace service endpoints

    main

    You can authorize the Visual Studio Marketplace service endpoint using either a Personal Access Token (PAT) or Basic Authentication (username and password).

    Important: authentication_token and authentication_basic are mutually exclusive; you must provide exactly one.

    ### Authorize with token
    ```hcl
    resource "azuredevops_serviceendpoint_visualstudiomarketplace" "example" {
      project_id            = azuredevops_project.example.id
      service_endpoint_name = "Example Marketplace"
      url                   = "https://markpetplace.com"
      authentication_token {
        token = "token"
      }
      description = "Managed by Terraform"
    }

    Authorize with username and password

    resource "azuredevops_serviceendpoint_visualstudiomarketplace" "example" {
      project_id            = azuredevops_project.example.id
      service_endpoint_name = "Example Marketplace"
      url                   = "https://markpetplace.com"
      authentication_basic {
        username = "username"
        password = "password"
      }
      description = "Managed by Terraform"
    }
  7. Manage Azure DevOps service endpoints with azuredevops_serviceendpoint_azuredevops

    main

    The azuredevops_serviceendpoint_azuredevops resource manages an Azure DevOps service endpoint within an Azure DevOps organization.

    Important Deprecation Notice: This resource is a duplicate of azuredevops_serviceendpoint_runpipeline and will be removed in the future. It is recommended to use azuredevops_serviceendpoint_runpipeline instead.

    Prerequisite: The Configurable Pipeline Runner extension must be installed for the organization to use this resource.

    resource "azuredevops_serviceendpoint_azuredevops" "example" {
      project_id            = azuredevops_project.example.id
      service_endpoint_name = "Example Azure DevOps"
      org_url               = "https://dev.azure.com/testorganization"
      release_api_url       = "https://vsrm.dev.azure.com/testorganization"
      personal_access_token = "0000000000000000000000000000000000000000000000000000"
      description           = "Managed by Terraform"
    }
  8. Understand the repository structure

    main

    The repository follows standard HashiCorp patterns for Terraform providers:

    • azuredevops/: The core provider implementation.
      • config.go: Handles Azure DevOps SDK initialization.
      • provider.go: Exports the Azure DevOps Terraform provider.
      • data_*.go: Contains Terraform data source implementations.
      • resource_*.go: Contains Terraform resource implementations.
      • utils/: Shared utilities.
    • azdosdkmocks/: Generated mocks for the Azure DevOps Go SDK.
    • scripts/: Build and installation scripts.
    • website/: Client-facing documentation.
    • docs/: Developer documentation.
    • go.mod: Project dependencies.
    tree -L 2
    .
    ├── azdosdkmocks --------> Generated mocks for AzDO Go SDK
    ├── azuredevops ---------> Provider implementation
    │   ├── config.go -------> AzDO SDK initialization lives here
    │   ├── provider.go -----> Exports the AzDO terraform provider
    │   ├── data_*.go -------> data_*.go files contain terraform data sources implementations
    │   ├── resource_*.go ---> resource_*.go files contain terraform resource implementations
    │   └── utils -----------> Utilities used across the codebase
    ├── docs ----------------> Developer documentation
    ├── go.mod --------------> Describes project dependencies
    ├── scripts -------------> All scripts live here
    └── website -------------> Client facing documentation
  9. Avoid using Sleep for state changes

    main

    Using the Sleep function to wait for cloud resources to reach a desired state is considered bad practice because cloud deployment times are unpredictable.

    Instead, use Terraform's built-in mechanisms to handle delays in resource APIs:

    1. The retry mechanism of the schema.Resource.
    2. The WaitForState function of retry.StateChangeConf.

    These methods ensure that subsequent provider actions only occur once the resource has reached the expected state.