microsoft
BcContainerHelper will go out of support on October 1st 2027
For more information, read this: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/al-go/algo-deprecating-bccontainerhelper
Microsoft recommends that you use AL-Go for GitHub or another managed DevOps solution for your DevOps needs instead of building and maintaining your own based on BcContainerHelper.
How many seconds does it take to run just a compile on previous, current and nextmajor for a minimal repo, without tests ?
How many seconds does it take to run just a compile on previous, current and nextmajor for a minimal repo, without tests ?
Assuming you are referring to AL-Go for GitHub in your question? Every workflow will take anywhere from a few minutes to 15 minutes depending on setup, 15 minutes is using GitHub hosted runners, containers, no caching, no nothing - everything is downloaded. a few minutes is using GitHub hosted Linux runners, compilerfolders, artifact caching - most is cached.
and then there is everything in between.
But... - rest assured that we will be working on making the performance better for the benefit of the 500+ partners who are already on AL-Go for GitHub.
Obviously 15 minutes is more than an order of magnitude too slow for "without tests".
I see I forgot to include a target; But I did say "seconds" for a reason, you apparently always run a container even when it isn't needed to run any tests. Without the container (and with an installed/cached compiler) the run times are usually 30-70 seconds on a Windows agent running on a 2019 laptop.
Just scanned down the list, found one that takes two minutes; it downloads and compiles eight repos.
Only once have I seen a (sort of) compile issue that only appeared when the C# code was loaded, and that was caught when we ran the slow pipeline (and had to be fixed by Microsoft).
I should also say thanks for this comment, I (for one) probably wouldn't have found that message with the target date for a long time.
- Without BCContainerHelper how do we run development on local machines then?
- If we are using AzureDevops (Microsoft's service by the way) then we should abandon it? With all the ticket history? With all the linkage between code and tickets?
Obviously 15 minutes is more than an order of magnitude too slow for "without tests".
I see I forgot to include a target; But I did say "seconds" for a reason, you apparently always run a container even when it isn't needed to run any tests. Without the container (and with an installed/cached compiler) the run times are usually 30-70 seconds on a Windows agent running on a 2019 laptop.
Just scanned down the list, found one that takes two minutes; it downloads and compiles eight repos.
Only once have I seen a (sort of) compile issue that only appeared when the C# code was loaded, and that was caught when we ran the slow pipeline (and had to be fixed by Microsoft).
In my response, I did write anyway from a few minutes to 15 minutes. A few minutes would be running without a container on Linux runners.
- Without BCContainerHelper how do we run development on local machines then?
- If we are using AzureDevops (Microsoft's service by the way) then we should abandon it? With all the ticket history? With all the linkage between code and tickets?
Please read the article linked in the announcement.
We do recommend that you switch to a managed DevOps solution, which includes a few for Azure DevOps as well as AL-Go for GitHub.
BTW. I do see many partners using Azure DevOps for tickets and GitHub for workflows.
Hi @freddydk ,
In the "Continuous Deployment" of AL-Go I've read the following :
"Using Continuous Deployment you can deploy your apps to an online environment continuously. "
Does this also work with OnPrem?
Hi @freddydk ,
In the "Continuous Deployment" of AL-Go I've read the following :
"Using Continuous Deployment you can deploy your apps to an online environment continuously. "
Does this also work with OnPrem?
Yes, it does require a few lines of code though.
Yes, it does require a few lines of code though.
is there anything tangible yet ? we are trying to evaluate if we are able to or should already integrate this for our CD which we are doing with bccontainerhelper and devops right now.
It says to look up the advanced section but i can't find it.
https://github.com/microsoft/AL-Go/blob/main/Scenarios/settings.md#custom-deployment
Hello Freddy, So what would you recommend considering we currently using BcContainerHelper and Azure DevOps for everything (workitems, repos, pipelines)? Should we keep Azure DevOps to manage workitems, sprints, backlog, but host the code in GitHub and switch to AL-Go? Should we keep keep Azure DevOps to manage pipelines or switch to GitHub workflows instead?
....In anxious anticipation of a private nuget feed called "freddyscontainerhelper"....
My recommendation is still to switch to AL-Go for GitHub for pipelines etc.
If you want to continue using Azure DevOps to manage workitems backlog etc - that is doable if you don't fancy the GitHub version of these things.
And sorry @mishof - not going to happen.
My recommendation is still to switch to AL-Go for GitHub for pipelines etc.
If you want to continue using Azure DevOps to manage workitems backlog etc - that is doable if you don't fancy the GitHub version of these things.
And sorry @mishof - not going to happen.
Thank you Freddy. Wish you the best....
Thank you for all your efforts, Freddy. Are there any good alternatives for downloading and running local dockers once BCCH goes to the land of legends?
My recommendation is still to switch to AL-Go for GitHub for pipelines etc.
If you want to continue using Azure DevOps to manage workitems backlog etc - that is doable if you don't fancy the GitHub version of these things.
And sorry @mishof - not going to happen.
We will figure it out. Best of luck, thanks for creating and supporting!
Had a look at AL-Go some more today ... it appears that it depends (a lot) on BCContainerHelper. Interestingly, it seems to depends on the same parts that I'm depending on. So how is that going to work when Helper goes?