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.
Version 2.0.1 of BcContainerHelper was shipped with a number of very exciting new featuers. This blog post will list the features and I will have to document them elsewhere.
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.