AL-Go/Workshop/Releasing.md

Releasing the apps

Releasing an app is an integral part of DevOps and it is important to understand how you release the apps in a repository, how this affects versioning and how you can create a hotfix to an already released set of apps.

The recommended branching strategy for AL-Go for GitHub is shown here:

Every time you release a version of the apps, you increment the version of the apps at the same time. This means that a hotfix created from the release branch will still have a version number, which is lower than the next version from the main branch. Let's see this in action.

Select Actions, select the Create Release workflow and click Run workflow. Enter the following values in the form:

Name	Value
Use workflow from	Branch: main
App version	latest
Name of this release	v1.0
Tag of this release	1.0.4
Prerelease	🔲
Draft	🔲
Create Release Branch	☑️
New Version Number	+1.0
Direct Commit	🔲
Use GhTokenWorkflow	🔲

After completion of the Create release workflow, you can select Code and see that you have 1 release:

Also, you have a Pull request waiting, which increments version number by 1.0.

Merge the Pull request, delete the temporary branch and select Actions to see that a Merge Pull request was kicked off.

Inspecting the build from the Pull request, you will see that the artifacts are now 2.0.7.0, app1 is 2.2.7.0 and app2 is 2.0.7.0 (in my repository)

!NOTE

All subsequent builds from main will now be 2.x. You will also see that the annotation stating that No previous release found has now gone and all builds from main will use the latest release version for upgrade testing.

Inspecting the build step in the workflow, reveals that AL-Go for GitHub was able to locate the previous release

Now, if you at some point in time need to create a hotfix for version 1.0.6, you can simply select Code and switch to the release branch.

In the release branch, navigate to the HelloWorld.al file in the app2 app, make a simple change and commit the changes directory to the release branch

Select Actions and see that a build was kicked off in the release branch.

!NOTE

This build will use the latest released build, which has a version number lower than the one you are building as previous release and will use the version numbers from the release branch for versioning. After the build is completed, you will need to release this new build in order for subsequent CI/CD builds from main to see the new bits as a release.

The artifacts in the hotfix build looks like this:

where the branch name main has been replaced by the release branch name and if you want to release this hotfix, you can run the Create Release and specify these parameters:

Name	Value
Use workflow from	Branch: release/1.0.6
App version	latest
Name of this release	v1.0.8
Tag of this release	1.0.8
Prerelease	🔲
Draft	🔲
Create Release Branch	🔲
New Version Number
Direct Commit	🔲
Use GhTokenWorkflow	🔲

!NOTE

You must select to use workflow from the release branch. Else the create release workflow cannot locate the build in the release branch. In this case, we select to not create a new release branch. We can just create any future hotfixes from the existing release branch if needed. We can also always create a release branch from a release later.

After the release has been created we can (under Code) see that we have 2 releases:

and clicking Releases will show the content of the releases:

!NOTE

GitHub sorts the releases after the tag and sorting only works correctly if the tag is SemVer compatible (i.e. 3 tuples). This is the reason why AL-Go for GitHub forces you to enter a SemVer compatible version number in the tag when creating a new release.

OK, so that is clear, versioning and releasing, pretty smart - but what is this project concept?

---

Index  next