Publishing the IoT CLI Extension

Steps

Identity Target Release Branch

Ensure target release branch is up to date with expected payload. Note the commit.

Here is a GitHub method to compare the dev branch to a previous release.

Ensure:

• HISTORY.rst is updated with this release's changelog
• azext_iot/constants.py contains the correct version number
• azext_iot/azext_metadata.json has the appropriate minCliCoreVersion and isPreview tags set:

{
    "azext.minCliCoreVersion": "2.67.0",
    "azext.isPreview": false
}

Run Integration Tests

Our integration tests for this extension run in our internal ADO instance, please ensure you are targeting the correct branch in ADO.

Multiple test jobs will run in parallel against multiple versions of python (as of this edit, 3.9 - 3.13).

There are also options to run against different core CLI versions - min, released, and msi (windows installer).

Note success and failures. Categorize (is it transient?) and compare to previous runs if unsure.

Note: you can also run these as part of the release pipeline - but ensure you have created a PAT token with permissions to queue builds from ADO, and update the ADO_PAT secret on this repository.

Produce Secure Build

Use the Build and Publish Release workflow to produce and stage a secure build and exercise min quality gates (linters, unit tests, command table eval). Choose where the build gets staged. Make sure the correct branch for the release is selected.

Pipeline options:

Continue release if pre-checks fail - This is a break-glass option to continue a build in case there are failures in linter / unit test steps. This should not be used unless running tests or otherwise necessary.

Stage github release - The build and related artifacts (sbom) are used to produce a draft github release.

Run integration test step - This will trigger our ADO integration test pipeline to run a full set of tests (4+ hours) as part of this workflow run. This can be done outside of this pipeline, just ensure it runs against the same commit.

Approve Build

A user with admin permissions must approve the publish.

Smoke Tests

❗ Optional but recommended.

Once release pipeline runs successfully, you should be able to get the draft build from generated draft release (Draft release should be auto generated after running release pipeline. The link can be found in the draft github release job->create release step). Download the draft build, install and use to exercise a range of scenarios via CLI. This is generally a team effort.

Publish draft release

If the prior steps check out, it is time to publish. Traverse to the draft release and select edit. Validate the tag that will be used to make the release is correct. Ensure release notes are captured, making any adjustments as necessary - please see previous releases for examples of how to format the release content.

Please also ensure that the wheel (.whl) and SBOM are attached to this release, and that you select latest or prerelease appropriately.

Update the extension index

Congrats on publishing the new CLI version!

To enable this version to be picked up with az extension add --name azure-iot-ops [--version] ... the metadata for this release must be merged with the index located in the Azure CLI extensions repo.

Example from a prior release.

Steps to Generate index.json Automatically

• Clone the Azure CLI extensions repo(azure-cli-extensions) and navigate into it

• Create and activate a virtual environment

• Install azdev using pip install azdev

• Set up the repo as your extensions workspace

• azdev setup -c EDGE -r . (this will setup the current repo as your 'extensions' repo)

• (if you already set up azure-cli locally, use azdev setup -c ../azure-cli instead)

• Run the index update command azdev extension update-index [link_to_whl_from_github]

Q&A

Q: How can I ensure the target release branch is up to date with the expected payload?

A: As the release manager, you should maintain a clear record of what payload is expected in the release.

• Please validate that all expected changes are present, including:

  • New features

  • Modifications / fixes to existing functionality

  • Regenerated SDKs / REST clients (if applicable)

---

Q: How can I determine if the IoT CLI extension version needs to be incremented?

A:

• Check the current version in the release branch:

  • If the version has already been released, it definitely needs to be incremented.

• Align with the team: Confirm with the team whether an extension version update is required based on changes in this release.

Breaking changes should always bump minor versions, since this extension's major version is always 0.

---

Q: Which areas should I focus on during smoke testing?

A:

• Review the changelog to identify updated feature areas.

• Focus testing on:

  • Newly added or modified features

  • Any functionality that lacks integration test coverage

  • Updated / new RP API-versions