The Azure DevOps extension puts Pipelines, Boards and Repos behind the az command

It replaces the VSTS CLI rather than sitting beside it

The Azure DevOps Extension for Azure CLI adds Pipelines, Boards, Repos, Artifacts and DevOps commands to the Azure CLI 2.0, and the readme is unambiguous about its status. The Azure CLI with the Azure DevOps Extension has replaced the VSTS CLI, and the VSTS CLI has been deprecated and will no longer be receiving new features. Users of the VSTS CLI are recommended to switch to the Azure CLI and add the extension, and a command mapping document in the doc/ directory shows the mapping between the two sets of commands. That is the right framing for anyone evaluating it, because this is a successor tool with a migration path rather than a new thing to learn from scratch. The topics the repository carries describe the same scope: agile, artifacts, azure, azure-cli, boards, cicd, devops, git, pipelines and repos.

Installing it is a version check and one extension add

The quick start is three steps. First you install the Azure CLI, and you must have at least version 2.0.69, which you can verify with the az --version command. Then you add the extension.

az extension add --name azure-devops

And then you run az login. The login step has a behaviour worth knowing, because it depends on the environment. If the CLI can open your default browser it will do so and load a sign-in page. Otherwise you need to open a browser page yourself and follow the instructions on the command line to enter an authorization code after navigating to the device login address. A dedicated get started guide is linked for detailed setup instructions, and the extension is documented separately in the Azure CLI extension reference.

The command groups and how they are organised

The usage pattern is the standard Azure CLI one.

$az [group] [subgroup] [command] {parameters}

Adding the extension adds the devops, pipelines, artifacts, boards and repos groups, and enterprise live migrations are available under az devops migrations. The help output for the devops group shows the structure, and it is worth reading because it is how you find the command you need without a web search.

$ az devops -h

Group
    az devops : Manage Azure DevOps organization level operations.
        Related Groups
        az pipelines: Manage Azure Pipelines
        az boards: Manage Azure Boards
        az repos: Manage Azure Repos
        az artifacts: Manage Azure Artifacts.

Subgroups:
    admin            : Manage administration operations.
    migrations       : Manage enterprise live migrations.

The subgroup list continues with extension, project, security, service-endpoint, team, user and wiki. The distinction the structure draws is between organisation level operations, which is what the devops group covers, and the resource groups for pipelines, boards, repos and artifacts, which are the areas themselves. There is also an invoke command that will make a request for any DevOps area and resource, and its own description warns that only JSON output should be used because the response is not fixed, with a pointer to the Azure DevOps REST API documentation.

Authentication is a personal access token per organisation

Two of the devops commands are about credentials, and they are the ones that surprise people coming from the Azure CLI's own login. The login command sets the credential, a personal access token, to use for a particular organization, and the logout command clears the credential for all or for a particular organisation. So the extension carries a second credential model alongside whatever az login established for Azure resources, and the two are stored separately and used for different things. That is not a design flaw, it is a consequence of Azure DevOps being a separate service with its own identity model, but it does mean a script that works for someone else may fail for you because the token was never set. There is also a configure command that configures the Azure DevOps CLI or views its configuration, which is where you would check that state first.

What the repository contains, and who it is for

The repository is an Azure DevOps organisation's own pipeline setup rather than a plain GitHub project, and the badges show it. The build status badge points at the Azure DevOps build definition on dev.azure.com rather than at GitHub Actions, with the branch name master, and the repository carries an .azure-pipelines/ directory for it. Alongside that there is a .flake8, a pylintrc and a .mdlrc, which are the Python linting and Markdown linting configurations, a .vscode directory, BuildTasks/ for the build steps, scripts/, doc/ with the command mapping and the migrations guide, examples/ with PowerShell scripts and Markdown documents for real workflows, a NOTICE.txt, a SECURITY.md and a CONTRIBUTING.md. The examples directory is the part worth browsing, since it holds scripts for generating a pull request report, sending a review reminder, creating work items in bulk, marking a work item stale and calculating query scheduling, which are the everyday automations people actually want.

Where this is the wrong choice

Three limits are worth naming. The first is that it is a wrapper around a REST API, so the extension cannot be smarter than the API and the invoke command is the escape hatch that proves it. If you need an operation the extension does not model, you end up calling invoke with JSON and parsing it yourself, which is where the value of the wrapper disappears. The second is the second credential model, since the personal access token per organisation is a different thing from the Azure CLI login, and a script that assumes one will authenticate everything will break the first time it touches Azure DevOps resources. The third is that the mapping from the VSTS CLI is not a compatibility layer. The readme presents it as a migration aid, which means scripts written for the old names need editing rather than just running, and the deprecated tool will keep receiving nothing while the extension keeps moving. The releases show that pace, with the extension version numbered by date, 20261015.1 following 20261012.1 and 20260902.1, each tied to a specific Azure CLI version.

Editorial conclusion

The Azure DevOps extension suits a team that already scripts against the Azure CLI and wants Azure DevOps in the same place rather than in a second tool with its own authentication model. It is the wrong tool if you are starting fresh, because the plain Azure CLI plus the REST API does the same work with fewer moving parts, and it is the wrong choice if you need the legacy command names, since the mapping is a migration aid rather than a compatibility layer. Before adopting it, read the command mapping document, because the differences between the VSTS CLI and this extension are not always one to one, and check how your scripts authenticate, since the credential here is a personal access token set per organisation rather than the CLI's own login. The last push was on 2026-10-16 and the current release is 20261015.1.

Frequently asked questions

Official sources

1. Azure/azure-devops-cli-extension on GitHub
2. License: MIT
3. Project website
4. README
5. Releases