What's New: AL Go for GitHub (2023 release wave 2)

Overview

The session walks through what changed in AL Go for GitHub, the DevOps solution for Business Central development on GitHub. It covers settings levels, version tracking and upgrades, code signing with HSM-stored keys, and deployment changes such as a deploy to environment name setting and custom deployment scripts for non-SaaS targets.

It then covers build speed and cost: the compiler folder feature, building on Ubuntu runners without containers, and caching of Business Central artifacts. It ends with the GH token workflow option, a BCPT test result viewer that is still a draft pull request, and ways to customize AL Go through indirect template repositories. The presenters say they have not decided between templates and forks.

Key points

• Three settings levels: repository-wide (template URL, schedules, runners, environments), project-wide (.AL-Go folder per project), and workflow-specific settings such as for test next minor/major. These are recapped, not changed.
• Upgrade with the Update AL Go system files workflow. It needs a secret named GH token workflow with a personal access token that can modify workflows. The version (e.g. 3.2) is shown in the initialize workflow output.
• Code signing: AL Go supports private keys in HSM key storage in Azure Key Vault, needed because certificate providers must deliver keys in hardware modules from July 1st.
• Deployment: a DeployTo setting (for example deploy to QA) replaces secret-based environment naming and covers environment type, branches, projects, sync mode, runs on and continuous deployment. Continuous deployment can be set true or false for any environment, including production.
• Custom deployment: setting a non-SaaS environment type runs your own .github/DeployTo.ps1 script with passed parameters. Microsoft does not provide these scripts. A custom GitHub runner inside a firewall is optional.
• Linux build without containers needs do not publish apps and use compiler folder set to true, plus runs on and GitHub runner set to Ubuntu latest. Do not publish apps disables running tests. A build went from about 14.5 minutes to 4 min 42 s, then 3 min 38 s on a rebuild thanks to cached artifacts.
• A pull request status check job can serve as the required status check in GitHub branch protection, so you do not have to reference matrix jobs.

Features

AL objects mentioned

As heard in the captions. A name that matches one object page by exact type and name links to it; the others stay as named.

• other “deploy to custom” at 18:17
• other “deploy to Q&A” at 18:38
• other “ALOps settings” at 18:38
• other “pull request handler” at 19:43
• other “run pipeline” at 23:26
• other “BCBT baseline.json” at 35:35
• other “BC container partial script” at 39:49
• other “custom job/my job” at 39:12
• other “custom job/prepare deploy” at 40:13

Quotes

• 0:19 “AL Go for GitHub is the plug-and-play DevOps solution for Business Central development on GitHub”
• 0:59 “You don’t need any knowledge in Docker, PowerShell, or YAML, or anything like that. You don’t need a dedicated DevOps engineer”
• 4:01 “There are three types of settings in AL Go for GitHub really. There’s repository wide settings”
• 7:45 “AL Go for GitHub version 3.2”
• 8:34 “Every time you have a CI CD or build running, there’ll be a job called check for updates”
• 10:35 “what we did in AL Go for GitHub was to add support for HSM key storage in Azure Key Vault”
• 13:25 “the real way of of doing this going forward is to create a new setting called deploy to an environment name, meaning deploy to”
• 15:11 “you can set it to true or false, no matter whether it’s a it’s a production environment or a um or a sandbox environment”
• 15:50 “the reason for that is really another newcomer in in this version, which is custom deployment”
• 23:56 “a new functionality that allows AL Go to build apps without containers, and allowed GitHub to cache artifacts”
• 24:07 “GitHub hosted runner Linux runners are half the price, and uh they are 33 approximately percent faster than the Windows runners”
• 26:55 “pulling generic image takes 4 minutes creating a container takes 7 minutes. So, 11 minutes of these 14 or 12 minutes actually goes for”
• 27:30 “this build actually took 4 minutes and 42 seconds. So, it’s quite a bit faster, 12 minutes faster than the other build”
• 27:30 “we do not publish apps, use compiler folder, runs on Ubuntu and GitHub runner Ubuntu click actions and we’ll see that this build actually”
• 29:17 “for a free skew of of GitHub, there’s like 2,000 minutes included for free of of of runners. Uh that is that equals to”
• 31:03 “GitHub says that triggering a workflow from a workflow is not possible using the GitHub token. Uh meaning that if we run a workflow”
• 34:00 “there’s no promises, no dates. I know that it looks like everything is done, but we might still like pull the plug and say”
• 36:41 “I think 80% of partners would not need to, like, change anything. Uh they’d be able to use AL Go for GitHub as is”
• 39:12 “I’ve integrated this job into my CI/CD pipeline”
• 41:19 “added settings will also be transferred to the repo by update AL Go system files. If you already set the settings in this file,”
• 42:46 “if there is already a a a job with the same name in the repository that it comes from the indirect repository, it will”
• 42:58 “if you have like new jobs that are not named the same as as as jobs that are that are from AL Go or”
• 43:55 “you just you decide when you want to uptake new changes to that, and these changes can then be be transferred to uh to”
• 44:08 “you could also have a fork of AL Go. Uh there are different ways of doing that and and we’re not sure whether we”

Disclaimers in the video

• 7:45 preview: If you are running the preview version, that would the template URL would be github.com microsoft AL Go PTE at preview
• 24:30 coming-later: At some point in time, in a future version of AL Go for GitHub, these things will be set behind the scenes
• 25:47 other: do not publish apps will in effect disable running tests, which is the reason why we didn’t like default these things
• 34:00 preview: there’s no promises, no dates… we might still like pull the plug and say we’re not going to ship this at all
• 35:01 coming-later: it’s a feature that that we might add soon
• 37:28 subject-to-change: there actually is a PR open now, and whether we’re going to merge it or or include this functionality, I don’t know
• 44:08 other: we’re not sure whether we are going to select one or the other. If you’re seeing this listening to this video, uh have a look at the functionality. Give us some some some feedback on whether you think this is a good idea or whether we should just go with forks

Presenters (as heard): Freddy Nielsen, Freddy.