Prerequisites: A completed "Register a customer sandbox environment for Continuous Deployment using S2S" scenario
-
On github.com, open Actions in your project and select Create Release. Choose Run workflow. Enter
v1.0as name and1.0.0as tag of the release, type+0.1in new version number and then choose Run workflow.
-
When the create release workflow completes, choose the Code section to see the releases.
-
Choose the release (v1.0) and you will see the release. The release notes are pulled from all changes checked in since the last release. The auto-generated release note also contains a list of the new contributers and a link to the full changelog. Choose the Edit button (the pencil) to modify the release notes. At the bottom, you can see the artifacts published, both the apps and the source code. A tag is created in the repository for the release number to always keep this.
-
Under Pull requests you should also see the pull request created for the updated version number.
Note
In AL-Go for GitHub every release should be followed by an update to the version number in order to be able to create hotfixes for the release and not clash with version numbers in the main branch.
-
Inspecting the pull request reveals that it just changes the minor version number in the main branch. Under the conversation tab, merge the pull request and delete the branch.
-
Under Actions you should now see that a new CI/CD workflow have been started.
-
After the CI/CD workflow finishes, you can inspect the workflow output to see that the latest release was used as a baseline for the upgrade tests in the pipeline. You will also see that the new build, just created was deployed to the QA environment automatically.
