Creating a new release
-
Ensure that the controller CVE scan action is green.
-
Ensure that the pre-release upgrade tests are passing.
-
Go to the releases page and draft a new release.
-
In the tag dropdown, type the name of the new tag you’d like to create (it should match the pattern of previous releases tags, for example:
v2.0.0-beta.3
). The release target should bemain
(the default). -
Use the GitHub “auto-generate release notes” button to generate a set of release notes to work with. You will need to clean this up quite a bit before actually publishing it.
-
Write a “Release Notes” section. You can edit the autogenerated section as a start. You can also look through the commits between the last release and now:
git log v2.4.0..main
-
Publish the release. This will automatically trigger a GitHub action to build and publish an updated Docker image with the latest manager changes.
-
Ensure that the action associated with your release finishes successfully.
-
Update our documentation to move resources listed under “Next Release” to the heading “Released”.
-
Update the ROADMAP to reflect the new release.
Catalog breaking changes
There may be breaking changes in a new release of ASO, either due to changes we made or changes made in the upstream service Swagger specifications. We must validate each breaking change so that we can notify customers about it.
-
Download the CRD definitions for the prior release (in this example, v2.5.0):
wget https://github.com/Azure/azure-service-operator/releases/download/v2.5.0/azureserviceoperator_v2.5.0.yaml
-
Download the CRD definitions for the new release (in this example, v2.6.0):
wget https://github.com/Azure/azure-service-operator/releases/download/v2.6.0/azureserviceoperator_v2.6.0.yaml
This will only be available when the GitHub action trigged by publishing the release has finished.
-
Produce a diff between these files and examine it.
diff -u <old> <new> > comparison.diff
Testing
Perform a simple smoke test to make sure the new release is capable of starting up and creating some Azure resources.
-
Create a kind cluster
task controller:kind-create
-
Install cert-manager
task controller:install-cert-manager
-
Create the namespace for the operator
kubectl create namespace azureserviceoperator-system
-
Ensure you have a Service Principal and export these environment variables:
- AZURE_SUBSCRIPTION
- AZURE_TENANT_ID
- AZURE_CLIENT_ID
- AZURE_CLIENT_SECRET
-
Create a secret in your cluster with the Service Principal credentials for ASO to use:
task controller:make-sp-secret
-
Download the operator from MCR.
wget https://github.com/Azure/azure-service-operator/releases/download/v2.3.0/azureserviceoperator_v2.3.0.yaml
-
Configure
crd-patterns
to use with new release.sed -i 's_--crd-pattern=.*_--crd-pattern=resources.azure.com/*;network.azure.com/*_g' azureserviceoperator_v2.3.0.yaml
We use
sed
to replace the blank setting included in the release with the one we want to use, including both resource group and network CRDs. -
Install the operator into your cluster
kubectl apply --server-side=true -f azureserviceoperator_v2.0.0-beta.3.yaml
(We need to use server-side apply because the CRD for VirtualMachines is large enough that it can’t fit in the
last-applied-configuration
annotation client-sidekubectl apply
uses.) -
Watch while ASO starts
kubectl get all -n azureserviceoperator-system
-
Create a resource group and a vnet in it (the vnet is to check that conversion webhooks are working, since there aren’t any for RGs):
kubectl apply -f v2/samples/resources/v1api/v1api20200601_resourcegroup.yaml kubectl apply -f v2/samples/network/v1api20201101/v1api20201101_virtualnetwork.yaml
-
Make sure they deploy successfully - check in the portal as well.
Create and test the Helm chart
Note: A PR that does this should be automatically generated when a new release is published. These steps are documented here in case that process fails.
- Create a new branch from
<NEW_RELEASE_TAG>
HEAD - Generate helm manifest for new release:
task controller:gen-helm-manifest
- Check the version in
/v2/charts/azure-service-operator/Chart.yaml
if matches with the latest release tag. - Install helm chart:
helm install --set azureSubscriptionID=$AZURE_SUBSCRIPTION_ID \ --set azureTenantID=$AZURE_TENANT_ID \ --set azureClientSecret=$AZURE_CLIENT_SECRET \ --set azureClientID=$AZURE_CLIENT_ID \ asov2 -n azureserviceoperator-system --create-namespace ./v2/charts/azure-service-operator/.
- Wait for the chart installation.
- Wait for it to start:
k get all -n azureserviceoperator-system
- Create a resource group and a vnet in it (the vnet is to check that conversion webhooks are working, since there aren’t any for RGs):
k apply -f v2/samples/resources/v1beta/v1beta20200601_resourcegroup.yaml k apply -f v2/samples/network/v1beta/v1beta20201101_virtualnetwork.yaml
- Make sure they deploy successfully - check in the portal as well.
- If installed successfully, commit the files under
v2/charts/azure-service-operator
. - Send a PR.
Update Resource Documentation
Any resources included in the new release will currently be listed under “Next Release” in the documentation, so we need to update the documentation to move them to the “Released” section.
- Create a new branch from
main
and check it out. - Update the setting
supportedResourcesReport.currentRelease
to the new release inv2/azure-arm.yaml
- Run
task controller:generate-types
to update the documentation. - Repeat the above steps by modifying
hack/crossplane/azure-crossplane.yml
and runningtask crossplane:generate-types
. - Commit the changes and send a PR.
Update ROADMAP
Modify the ROADMAP.md
file in the repo root.
- Add the new release to the Prior Releases section, linking to the release in GitHub.
- Remove the new release from the Release Cadence & Planning section and add a new future release to the end.
- Check that future versions are linked to the relevant GitHub milestone where possible.
Then commit the changes and send a PR.
Fixing an incorrect release
If there was an issue publishing a new release, we may want to delete the existing release and try again. Only do this if you’ve just published the release and there is something wrong with it. We shouldn’t be deleting releases people are actually using.
- Delete the release in the releases page.
- Delete the tag:
git push <origin> --delete <tag>
, for examplegit push origin --delete v2.0.0-alpha.1
.
At this point, you can safely publish a “new” release with the same name.