As mentioned in this blog post, the Invoke-ScriptInBcContainer has undergone some serious changes in BcContainerHelper 3.0.9, which just shipped.
This blog post will describe some details about how this function works.
The function takes a containerName, a scriptblock and an argument list as parameters and will execute this scriptblock inside the container.
I recently learned that some partners have had had issues when running build pipelines on Azure DevOps with multiple DevOps agents on the same host using Containers with process isolation. 1-2 years ago, we did a number of fixes to support multiple agents on the same host, and I thought that had fixed things, but apparently this was not true.
Hopefully the fixes, which are going into BcContainerHelper today will fix this once and for good.
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.