This blog post will not reveal any secrets in AL-Go for GitHub:-)
Instead, it will explain ways for you to store secrets, which are used for AL-Go for GitHub. In almost every DevOps setup, you will have to store some keys, passwords, tokens or like. In GitHub, these are called secrets and AL-Go will look for a set of secrets by their name.
This blog post will also touch upon how you can use GitHub organizations and environments with your customer projects.
Lately we have been seeing an increasing number of people having difficulties creating Docker containers on multiple host OS’. Since Thursday, I have been diving into error reports on GitHub, looking in Telemetry and had some partners helping out trying various tests to see what the result of various changes would be.
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:
- Use Pull Requests
- Use Code Reviews
- Use automated testing
- Use Feature branches
- Use Releases and release branches
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.
On May 1st, 2002, I walked through the doors of Navision in the Offices in Vedbæk for the first time. A few days earlier rumors had started that Microsoft was going to acquire Navision, but things weren’t settled yet.
The Acquisition was formally announced on May 7th and was finalized on July 11, 2002, so my 20-year anniversary as a Microsoft employee is on July 11th, but for me, May 1st will always be the date where I started working with ERP software.
I have worked with a lot of amazing people on a ton of amazing stuff, and I am still as passionate about what I do as I have ever been.
Steve Jobs once said that we’re here to put a dent in the universe. Well, I might not have put a dent in the universe, but I definitely put a dent in the way Business Central developers are working on a daily basis.
While the Microsoft mission is to empower every person and every organization on the planet to achieve more, I can safely say that I have and am empowering developers and partners on the planet to achieve more, trying to do my part…
There are a lot of memorable moments during the last 20 years, but the one that stands out is from Convergence in Munich 2006, where Bill Gates talked about Business Solutions and had a demo of a Shop Floor control performed on stage by our GM Darren Laybourn. After the keynote, the leader of Business Solutions, Satya Nadella, called Bill over to meet and greet. Humbled to have been in the company of these great people who both then and now has really transformed how people work and how people use IT.
Nobody knows what the future brings, but I will do my utmost to make the most out of it…
Thanks for all the fish
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.
It has been a while since my last blog post and the reason behind this is quite simple: I have been busy. Busy creating AL-Go for GitHub.
AL-Go for GitHub is plug-and-play DevOps for Business Central PTEs or AppSource apps on GitHub. A tool, which does NOT require you to modify PowerShell scripts, change .yaml workflows or pipelines, but still allows you to setup and maintain full DevOps for your Business Central projects with a click of a button.
BcContainerHelper 3.0.0 just released and as something new, you will see this message when importing the module:
BcContainerHelper emits usage statistics telemetry to Microsoft
What does that mean? Can you avoid that? Who can access the emitted telemetry data? How? Can you use telemetry for troubleshooting? Can you use telemetry for other things?
This blog post will try to answer these questions.