When you are done developing your app, it needs to be deployed to your customers if it is a PTE or to AppSource if it is an AppSource app.
Currently we don’t have any automated way of publishing your app to AppSource – that is something we are working on and some day in the future, when it becomes possible, you will get a workflow in AL-Go for GitHub which handles this automatically.
This blog post will talk about PTEs, and what features are available in AL-Go for GitHub to assist you deploying your PTEs to customers.
If you teach yourself to follow a fairly simple set of rules, you will see that the health of your project will increase dramatically, and you will be in a better place with your project development.
So, I will at the ripe age of 56 bestow upon you these 5 rules, which can be applied to any project, using any DevOps setup. In the following I will explain how to implement these rules using AL-Go for GitHub:
Like everything else these days, AL-Go for GitHub now also is available in a preview version, which you can install/apply and remove as you like. This allows you to get advantage of a bugfix or new functionality faster.
NOTE that when using the AL-Go preview version, you will have to update the AL-Go system files when you are told to, changes to the AL-Go actions might cause your version of the workflows to fail if not updated.
When developing apps for Business Central, you very frequently will have more than one app. You might split one customer specific app into multiple smaller apps or you might have a common app, which contains common functionality for all your customer specific or AppSource apps.
This blog post describes the thinking behind AL-Go for GitHub and how we recommend you setup your GitHub repository structure and why…
As explained in the first blog post about AL-Go for GitHub the next post would be all about how to migrate your repository to AL-Go for GitHub.
Whether you have a setup based on the first CI/CD Hands-On-Lab or you have the latest generation, it should be fairly easy to migrate to AL-Go and get all the benefits with that, but it is a manual process.
The following scenarios are described in this post:
From a CI/CD HOL based repo on GitHub
From a CI/CD HOL based repo on Azure DevOps
From GitHub (if you are “just” using it as a source code repository)
From Azure DevOps (if you are “just” using it as a source code repository)
From nothing (if you just have the source code on your laptop)
From nothing (if you just have some .app files, but not the source code)
Last, but not least there are some common questions you need to consider when using any DevOps setup really.
For quite some time, it has been possible to run automated tests in Docker using the Run-TestsInBcContainer function and it is my strong belief that this is used by a lot of partners today. Since 17.2, the Test Runner is available in Online Business Central Sandbox environments for installation from AppSource. From Extension Marketplace, you can install the Test Runner, open page 130451 and run your test manually. With BcContainerHelper 2.0.4 or later, you can also run tests in online sandbox environments, this blog post explains how.
There are 2 kinds of apps: AppSource Apps and Per Tenant Extensions (PTEs). These apps can be installed in two kinds of environments: Sandbox and Production. In Production, AppSource Apps are installed in the global scope and Per Tenant Extensions are installed in the Tenant Scope. In Sandbox environments you can also install apps to the development scope (like what VS Code does).
This blog post will describe how you can use BcContainerHelper 2.0.2 to install apps in any of those combinations.
When releasing the first version of Run-AlValidation in BcContainerHelper, i did a quick blog post about the function here. This blog post serves to explain some common scenarios of how to run the function. The blog post will also explain the parameters of Run-AlValidation a bit more in depth, for people to have a good chance of using the function before submitting for AppSource Validation.
On December 1st, I co-hosted a webinar about how people can make sure that their app passes AppSource Validation. Until now, I have always been preaching that people should run CI/CD and include AppSourceCop validation in their CI/CD pipeline, which is supported in the Run-AlPipeline function. But…, as I prepared for the session, it became evident that it would be really helpful to have a function, which basically does exactly the same as our validation pipeline.
For the last 2 years we have had the Hands On Lab (https://aka.ms/cicdhol) in a few iterations using Azure DevOps as the platform. Latest revision was published a few weeks ago.
There are however multiple platforms for DevOps out there and I wanted to investigate the functionality of Github, which also is part of the Microsoft family and probably the biggest provider of devops services to developers in the world.