Connect Azure DevOps

Connect an Azure DevOps Services organization to use its existing repositories in Taiga. Taiga can read the code, push working branches, open and update pull requests, respond to review threads, and merge when checks and branch policies permit it. Azure Pipelines checks and failed task logs appear in the build journey.

Prepare an account and token

Use a dedicated Azure DevOps account with access only to the projects Taiga should work on. Pull requests and review replies are attributed to that account. Create an organization-scoped personal access token for this organization. Do not use a global token: global tokens stop working on December 1, 2026. Use these scopes:

• Code: Read & write — Read repositories, push working branches, and work with pull requests and reviews.
• Build: Read & execute — Read pipeline results and task logs.
• Environment: Read & manage — Read environment deployment history. Taiga does not change Azure environments.

The account also needs repository contribution permissions, access to the pipelines and environments, and permission to complete pull requests under your branch policies. The account must not have permission to edit branch policies. Code: Read & write can otherwise let an administrator account change those policies. Taiga does not bypass branch policies. Set a token expiry and arrange to replace it before it expires.

Connect the organization

1. Open Settings → Organization → Integrations.
2. Choose Connect on the Azure DevOps card.
3. Enter a connection name and the organization URL, such as https://dev.azure.com/acme.
4. Paste the token and choose Save.

The legacy organization address https://acme.visualstudio.com is accepted and saved as https://dev.azure.com/acme. Azure DevOps Server addresses are not supported by this connection.

Taiga checks the account and repository access before saving. Access to individual pipelines and environments is checked when those resources are read. The token is stored encrypted and is never returned by the connection API or shown again in the form. The organization repository response is read with a 32 MiB limit; an organization exceeding that limit cannot be connected until its accessible repository set is reduced.

Link a repository

On a new product that starts from existing code, choose Connect repository in the import step. For an existing product, open its Settings → Integrations and choose Connect repository. Select a repository under the Azure connection name. Search by project or repository name if the list is long, and use Load more to reach later matches.

The repository must have an initial commit and a default branch. Taiga records Azure’s project and repository IDs, so renaming the repository does not redirect existing work to another repository. To change the integration branch, use Change branch on the linked repository.

Azure repositories use the coding agent runtime. The engineer runtime does not yet support them. Taiga checks pull requests, CI and review threads by polling; this connection does not install a service hook. See Review Taiga’s pull requests for feedback permissions and recovery when feedback cannot be read. Azure validates a published pull request itself. While a Taiga pull request stays a draft, Taiga queues the validation for each new head so its checks can still be read. If Azure ignores the queue request, Taiga tries again on a later poll. After the pull request is published, Azure normally starts validation itself; if a validation stays queued with no build for more than about a minute, Taiga queues it again the same way. Taiga can rerun a PR validation build. If the build has only just finished, Azure can ignore the request and Taiga reports that no rerun started, so try again about a minute later. Ordinary pipelines are retried in Azure, which preserves their runtime parameters and secret variables, and Taiga will observe the new attempt.

When Taiga does not own CI for a build, its write and push guards protect the configured Azure pipeline files and their repository-local templates, including nested templates outside the usual pipeline directories. If an executable template parameter, a dynamic template path or an unresolved repository alias prevents a complete read, Taiga cannot safely proceed with that unowned configuration. Products allowed to edit their pipelines do not require this protection discovery.

Follow deployments

The product’s Deployments page imports deployment jobs that Azure Pipelines recorded against Azure environments. Taiga imports the last 90 days on its own once the repository is linked; there is nothing to start. Azure deployment history is polled rather than delivered live. Background reconciliation picks up later changes every six hours by default, so new deployments and status changes can take that long to appear. The history shows the environment, commit SHA, status, deployment duration and a link to the Azure pipeline run. It does not yet enrich Azure records with commit messages, authored times or pull requests, so lead time from commit is unavailable. Each environment is settled from its own latest deployment-job attempts. A failure in production does not mark a successful staging deployment failed. Repeated imports update the same deployment records. Unfinished deployments are also refreshed outside the recent-history window. A busy environment may take several sync passes to refresh: Taiga saves its place and waits for the complete environment-run history before changing the outcome. Records whose pipeline runs have been deleted by Azure’s retention policy are skipped; the remaining history still imports.

Your pipeline must use an Azure environment deployment job for it to appear here. An ordinary build, a script that deploys without an environment record, and a Classic Release are not imported. Taiga imports deployment history only when the pipeline’s primary repository is linked to the product. It does not attribute deployments to other checkouts used by the pipeline.

Deployment history is read-only in Taiga. Start, approve, cancel and retry deployments in Azure DevOps. Taiga environment variables are not copied into Azure pipeline variables or variable groups. Azure Boards and task management are outside this integration.

Replace or remove a connection

Choose Check connection to test the saved token. A refused token shows Token needs attention. Choose Edit, paste its replacement in Personal access token, and save. Leaving that field empty keeps the existing token. The organization URL cannot be changed on an existing connection.

To remove a connection, first unlink its repositories from their products, then choose Remove. Removing it erases the saved credential from the connection row; revoke the token in Azure DevOps when it is no longer needed.

Refresh timing

Reality-document refreshes check the live default branch on the same backstop clock used for GitLab, every six hours by default. For operators, MAINTENANCE_GITLAB_DOCS_BACKSTOP_HOURS controls both providers; its existing name is retained for compatibility. Azure has no push hook in Taiga.