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

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

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.

Stage options:

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

Upload wheel to storage - The build gets staged in the well-known storage account for internal usage.

Use the Integration tests workflow. Multiple test jobs will run in parallel. Note success and failure. Categorize (is it transient?).

A user with admin permissions must approve the publish.

❗ 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.

If the prior steps check out, it is time to publish. Traverse to the draft release. Validate the tag that will be used to make the release is correct. Ensure release notes are captured, making any adjustments as necessary. This project uses conventional commits combined with the GitHub release note generation feature.

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.

• 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: 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 the following:

1. Arc extension versions match what is being deployed in the CLI.

   • Reference the milestone release branch to confirm alignment.

2. All expected changes are present, including:

   • New features

   • Modifications to existing functionality

   • Cloud-side and edge-side components

   • Regenerated REST clients (if applicable)

---

Q: If the release includes incrementing the Arc extension version, where is the file located that I need to update?

A: Please refer to Example from prior release

---

Q: How can I determine if the AIO 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.

---

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

A:

• If the release only updates the Arc extension version:

  • At minimum, verify that az iot ops upgrade works as expected.

• If the release includes additional changes:

  • Review the changelog to identify updated feature areas.

  • Focus testing on:

    • Newly added or modified features

    • Any functionality that lacks integration test coverage