Sept. 10, 2024
Episode 338: In the Dynamics Corner Chair: Efficient Development with AL-Go for GitHub
Listen as Freddy Kristiansen discusses the BCContainerHelper and AL-Go for GitHub as tools to help partners develop efficiently for Microsoft Dynamics 365 Business Central. These tools aim to provide managed solutions, allowing partners to focus on customer value instead of building their workflows and pipelines. Freddy discusses the importance of automated testing, continuous integration/continuous deployment (CI/CD) workflows in app development, and the ability to deploy apps to different environments, such as Sandbox and Production.
Connect with Freddy on LinkedIn (https://www.linkedin.com/in/freddykristiansen/)
Learn more about AL-Go on GitHub (https://github.com/microsoft/AL-Go)
#MSDyn365BC #BusinessCentral #BC #DynamicsCorner
Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/
00:00 - Deep Dive Into Microsoft Dynamics
13:27 - Streamlining DevOps With ALGo for GitHub
19:56 - Managing CI/CD Workflows on GitHub
30:24 - ALGo for GitHub Deployment Workflow
37:22 - Navigating ALGo and Dynamics Conferences
WEBVTT
00:00:00.980 --> 00:00:07.953
Welcome everyone to another episode of Dynamics Corner, the podcast where we dive deep into all things Microsoft Dynamics.
00:00:07.953 --> 00:00:20.393
Whether you're a seasoned expert or just starting your journey into the world of Dynamics 365, this is your place to get insights, learn new tricks and understand what is ALGO.
00:00:20.393 --> 00:00:22.045
I'm your co-host, chris.
00:00:22.981 --> 00:00:23.746
And this is Brad.
00:00:23.746 --> 00:00:27.768
This episode was recorded on August 28th 2024.
00:00:27.768 --> 00:00:32.911
Chris, chris, chris, algo, who's Al?
00:00:32.911 --> 00:00:36.781
I was going to say do you know how to spell ALGO, who's Al?
00:00:36.781 --> 00:00:37.804
And where did he go?
00:00:37.804 --> 00:00:39.289
Yeah, where did Al go?
00:00:39.289 --> 00:00:51.734
Yeah, with us today, we had the opportunity to speak with someone who is all about ALGO, to hear some valuable insights on how ALGO can be used to make your life a little more efficient.
00:00:51.734 --> 00:00:54.308
With us, today, we had the opportunity to speak with Freddie Christian.
00:01:11.126 --> 00:01:14.022
I'm just getting the chair Perfect.
00:01:18.468 --> 00:01:19.599
Oh, my bird is flying away.
00:01:19.599 --> 00:01:22.284
Where's it going?
00:01:22.284 --> 00:01:27.332
So this one is measuring how the air quality is.
00:01:27.332 --> 00:01:30.081
Oh wow.
00:01:30.081 --> 00:01:35.072
When it sits on top of the like upwards, the air quality is fine in here.
00:01:35.072 --> 00:01:40.012
If it's hanging down and dying, it symbolizes that the air is bad.
00:01:40.012 --> 00:01:41.885
When it sits like that, it needs power.
00:01:41.885 --> 00:01:43.469
Oh, okay.
00:01:44.501 --> 00:01:49.227
What's good to say is if we're talking with you and the bird starts to go down, I'll start to get afraid.
00:01:49.748 --> 00:02:02.489
I need to get one of those, so that's like it's a thing from back in the days where they actually had canaries in the mines yes, yes and when they like passed out, they knew it was about time to get up.
00:02:04.936 --> 00:02:08.945
That's exactly what I was thinking about the canary in the mine I need to get one of those.
00:02:08.945 --> 00:02:11.146
I don't know if I want one of those.
00:02:11.146 --> 00:02:13.328
I don't know if I want to know the air quality.
00:02:13.328 --> 00:02:18.633
Maybe I just want to just go and not know.
00:02:18.633 --> 00:02:21.526
Well, I won't keep an eye on it then, because it needs power.
00:02:21.526 --> 00:02:23.730
Good afternoon, thank you for talking with us.
00:02:23.730 --> 00:02:25.520
Good afternoon, thank you for talking with us this afternoon.
00:02:25.520 --> 00:02:34.149
I've been looking forward to speaking with you, always about something that's of great interest to me and many others I know as well.
00:02:34.149 --> 00:02:39.889
But before we jump into it for those that may not know, can you tell everyone a little bit about yourself?
00:03:08.759 --> 00:03:09.302
I am Freddy Christensen.
00:03:09.302 --> 00:03:28.395
My official role is a principal product manager, but the title that I like to tools that we have for DevOps and Docker and basically trying to help partners develop in as efficient way as possible without spending time on TDS and other things that they may be able to avoid spending time on right.
00:03:30.221 --> 00:03:37.633
No, that is true, and I like the technical evangelist term because I know you have been working with the product for a long time.
00:03:37.633 --> 00:03:52.609
Even back in the early days when I started out, I saw some information circling from you as well, so I do like the term and I do follow everything that you promote and push, which is good.
00:03:52.609 --> 00:04:04.762
One of the things that I wanted to talk with you about is you talk about with partners working with the latest tools so that they can become more efficient with the development and not have to do some of the tedious work.
00:04:04.762 --> 00:04:20.100
You tedious work with Docker and then also with the GitHub repositories as well, but as far as a dock is concerned, you work with the BC Container Helper tool.
00:04:20.100 --> 00:04:26.392
So can you tell me a little bit about BC Container Helper, what it's used for and what its position is?
00:04:27.060 --> 00:04:45.752
Yeah, so back in the days, I think, around Tech Days 2017, so that's seven years ago we launched the first way to run Business central and containers.
00:04:45.752 --> 00:04:56.622
At tech days that year me together with to be a svenster and the guy called jacob vanak and we had a session where we demonstrated these things.
00:04:56.622 --> 00:05:16.865
The problem was that running containers would require you to like, create this docker run statement that that easily would fill out the screen with different parameters and other things, and we really did not want all AL developers to be Docker experts.
00:05:16.865 --> 00:05:25.228
So we created this PowerShell module called bc-container-helper that was supposed to make life easier.
00:05:25.228 --> 00:05:35.105
And well, I think the first version of that, nav Container Help, was shipped back in 2018, and a number of versions of that Later.
00:05:35.125 --> 00:05:54.634
That became BC Container Helper and it's a huge pile of cool functionality that partners can use really of cool functionality that partners can use really Really unstructured, in the way that it's kind of the only shipping vehicle I've had to.
00:05:54.634 --> 00:06:05.208
Whenever there's something like, how do we publish to an online environment, well, I'll just ship that in VC Container Helper, and then it's easier because that module is always used by people making DevOps and stuff like that.
00:06:05.208 --> 00:06:12.192
So we're looking to change stuff in that sense, but we can talk about that later.
00:06:12.192 --> 00:06:15.208
The module is fairly big today.
00:06:15.208 --> 00:06:20.192
It has a lot of functionalities, has over 2 million downloads.
00:06:20.192 --> 00:06:23.379
That doesn't mean that we have 2 million AL developers, obviously.
00:06:23.379 --> 00:06:29.653
It means that it's frequently downloaded in DevOps pipelines and workflows.
00:06:29.653 --> 00:06:40.896
So in a good day you'll have several thousand downloads of the module from pipelines probably no, it's great.
00:06:41.261 --> 00:06:47.425
It is a tool that I personally use daily as well and I use it in a number of fashions.
00:06:47.425 --> 00:06:49.350
I think, as you had mentioned, it's a great tool.
00:06:49.350 --> 00:06:53.567
There is a lot to it and I do appreciate.
00:06:53.567 --> 00:06:59.451
I've been using it for many years and it has gotten easier because, as you had mentioned, there's two aspects of it.
00:06:59.451 --> 00:07:05.045
It is the PowerShell aspect of it and then also the Docker aspect of it PowerShell aspect of it and then also the Docker aspect of it.
00:07:05.065 --> 00:07:14.276
And becoming a Docker expert is a little difficult, I think you can say at some points using Docker Desktop versus Docker Engine and the like.
00:07:14.276 --> 00:07:20.428
So it gets a little challenging when you're just trying to develop and publish.
00:07:20.428 --> 00:07:30.740
So having the tool set to make it easier does help expedite and become a little bit more efficient with development does help expedite and become a little bit more efficient with development With the containers and the images.
00:07:30.740 --> 00:07:43.694
How is that structured as far as being able to pull down versions of Business Central or Nav, and also, how far back can we go to create containers for versions of Business Central or Nav?
00:07:43.694 --> 00:07:48.891
I know early on I used to be able to work it with Nav from the images.
00:07:49.360 --> 00:07:51.127
Yeah, so one thing is what's supported.
00:07:51.127 --> 00:07:52.865
Another thing is what's possible, right?
00:07:52.865 --> 00:08:00.425
Yes, supported is obviously the versions of NAV and Business Central that we support today.
00:08:00.425 --> 00:08:07.815
I actually don't know if we is there still support for the latest nav version, or is that our support today, I can't remember.
00:08:07.815 --> 00:08:11.324
But anyway it should work and it should work all the way back to.
00:08:11.324 --> 00:08:20.305
I know people who have created Docker containers with nav 2013,.
00:08:20.305 --> 00:08:23.670
Maybe even nav 2009 R2.
00:08:23.670 --> 00:08:33.289
But obviously it's not something that I do a lot to support or maintain or anything like that.
00:08:34.081 --> 00:08:43.147
There's only one Docker image really out there, like you can find in the Docker Hub or in the Microsoft Container Registry.
00:08:43.147 --> 00:09:03.186
You can find Docker images and you'll find one Docker image that matches the operating system, and every month we will ship a new Docker image that matches the supported Windows versions Right now Windows Server 2016, windows Server 2019, and Windows Server 22.
00:09:03.186 --> 00:09:05.000
I actually think Windows Server 2019, and Windows Server 22.
00:09:05.000 --> 00:09:15.183
I actually think Windows Server 2019 is no longer supported, but as long as the Windows team will ship updates to that, I will ship updates to.
00:09:15.183 --> 00:09:27.985
We will ship updates to the generic image, so if anybody is using Windows Server 2019, they'll be able to get a matching image of the Business Central generic image.
00:09:29.399 --> 00:09:36.894
In the beginning we created images for every single NAV slash Business Central version.
00:09:36.894 --> 00:09:42.244
The problem we had there was that we had to redo that every month when there was a new Windows version.
00:09:42.244 --> 00:09:50.572
We had to redo like the entire matrix of supported nav PC versions, times the different Windows versions.
00:09:50.572 --> 00:10:05.412
And back then Docker also shipped containers for all the intermediate versions and it became like a huge matrix and I had computers running for multiple days to create those things.
00:10:05.412 --> 00:10:13.994
And we changed that and instead of creating these fixed images, we create one generic image to rule them all.
00:10:15.861 --> 00:10:43.107
And then we, instead of shipping the Business Central bits in containers, we ship that as artifacts and these artifacts are then stored in a storage account and that storage account can be accessed either from BC Container Helper by getting a BC artifact URL, or you can also just download it with a normal invoke rest method, if you want to do that, from PowerShell or whatever.
00:10:43.107 --> 00:10:57.633
And the artifacts are split in two there's an app part and a platform part, or a localization part and a platform part, and the localization part is then multiplied by the different countries that we ship.
00:10:57.633 --> 00:11:21.047
So you'll be able to download a US version of a specific version of Business Central and there'll be a manifest file in that and inside of that manifest file there'll be a pointer to what platform this Business Central localization version runs with and then you can download that and you'll have the bits to create the container with.
00:11:23.873 --> 00:11:27.485
So, yeah, it's all magic.
00:11:27.620 --> 00:11:39.249
I know it sounds like all magic, because I can just create a new container, put in the version that I'm looking for and the country that I'm looking for, and I can see it download the artifact and the images and it creates a new business central implementation for me.
00:11:39.701 --> 00:12:03.207
And, as you had mentioned, there are a number of tools available within the BC container helper PowerShell script, I guess, say, or commandlet um everywhere from creating containers, uh, pulling out um runtimes of libraries or apps, if someone wanted to create a specific runtime for a version and the artifacts as well.
00:12:03.207 --> 00:12:06.474
And the earliest I've been able to use it was 2015.
00:12:06.474 --> 00:12:17.153
I haven't tried anything before 2015, but I was able to use BC Container Help with the pull-down image and load a container from a CD, or not from a CD, but from a DVD download of 2015.
00:12:17.153 --> 00:12:23.309
And it worked quite well if you just load the prerequisites into the system.
00:12:23.309 --> 00:12:37.630
You had mentioned and I had seen you post and talk about BC Container Helper and some changes that you're going to make or have been made to it in conjunction with ALGO, and you alluded to that a few moments ago.
00:12:37.630 --> 00:12:40.105
Can you explain a little bit about that?
00:12:41.570 --> 00:12:49.010
Yeah Well, it's not changes per se, it is changes.
00:12:49.522 --> 00:13:20.078
So what we're going to do is, since there are functions for all kinds of things in Container Helper and we want to structure that in a better way, and to do that we will take the functions that are needed to create containers or whatever and put them in probably one PowerShell library Some of the functions that are used to, let's say, publish to online environment.
00:13:20.099 --> 00:13:26.647
We'll probably put that into GitHub Actions maybe, or in another PowerShell library, I don't know, but really take.
00:13:27.519 --> 00:13:55.514
So with ALGo for GitHub, which is the tool that we shipped a few years ago, we're kind of seeking to be able to do everything that partners need from a DevOps solution, and back in the days with Container Helper, container Helper was really used to give partners a module so that they could build all of the things that they would use in a DevOps solution.
00:13:55.514 --> 00:14:06.504
But it's suboptimal to have three or four thousand partners sit and create their own workflows and their own pipelines and their own mechanisms to like upgrade and all of these things.
00:14:06.504 --> 00:14:22.666
It's better to have a managed solution where, like, everything is handled in that one, and that means that we're going to look at AL go for GitHub and see what functions of BC container helper is.
00:14:22.666 --> 00:14:42.965
That one using it is creating containers for development environment, it's creating online environments and all kinds of things, and we're going to take these functions out of container helper and put in other PowerShell modules or in GitHub actions, other things, so that eventually, algop for GitHub will no longer need BC Container Helper.
00:14:44.769 --> 00:14:46.956
And what's the future then of BC Container Helper?
00:14:46.956 --> 00:14:54.131
Well, it will be set on hold or on whatever, I don't know.
00:14:54.131 --> 00:14:55.660
I'm not going to maintain it anymore.
00:14:55.660 --> 00:15:13.827
When all the functionality that is needed for people's devops solutions are available in other locations, then the need for BC container helper would only be to to really work with these old CLL containers or the things that are not not really needed today.
00:15:13.827 --> 00:15:29.192
And the idea there is to stop supporting VC container helper at the day where, basically, the cutoff day is, when ALGo no longer needs VC container helper.
00:15:29.192 --> 00:15:37.701
But rest assured, we're not going to just move all the functionality into ALGo and force everybody to use a ago.
00:15:37.701 --> 00:15:40.032
That's not the that's not the purpose.
00:15:40.091 --> 00:15:50.568
The purpose of this exercise is really to to make sure that we have something that we can support and and work with, and, and we will.
00:15:50.568 --> 00:16:03.787
We will suggest people that they use what's called a managed DevOps solution, which I include, include ALGo for GitHub, I include ALOps, I include Alpaca and there might be more.
00:16:03.787 --> 00:16:24.994
The reason for that is that partners of varying sizes can really focus on providing customer value instead of developing workflows and pipelines and all of these things, and we're, of course, working with partners to make sure that ALGo supports as much as this is possible.
00:16:24.994 --> 00:16:35.304
Waldo is probably doing the same on ALOps and Cosmo is doing the same on Alpaca, ending up having these three really good solutions for these things.
00:16:35.304 --> 00:16:36.326
Really good solutions for these things.
00:16:36.326 --> 00:16:40.029
Obviously, algo is free, so that one.
00:16:40.029 --> 00:16:43.494
If you want a solution that doesn't cost you anything.
00:16:43.494 --> 00:16:46.197
Algo for GitHub is one solution.
00:16:46.197 --> 00:16:53.269
Allops has a price tag on it and Alpaca has the same.
00:16:53.269 --> 00:17:00.033
Alpaca and Allops are both on Azure DevOps and ALGo is only on GitHub.
00:17:00.033 --> 00:17:08.753
So that's some of the things that people or partners should think about when they select what solution to use.
00:17:14.440 --> 00:17:46.232
I had a survey not long ago where I asked people what kind of DevOps solution they use, and approximately 50% of all partners are still using something they built themselves, and I'm kind of to blame for that as well, because the thing that they built themselves they built that after a hands-on lab that I provided back in the days, which was kind of the first approach to this and creating a hands-on lab to teach people how to do this.
00:17:47.340 --> 00:17:52.613
We could just see that people were spending way too much time on maintaining and handling and all of these things.
00:17:52.613 --> 00:18:07.830
So that's the reason for for, instead of maintaining and expanding a hands-on lab for these things, we started creating ALGo for GitHub instead, and I'm using that ourselves as well.
00:18:07.830 --> 00:18:39.792
The BC Apps repository, with the system app and all of these things, is using ALGo, and also the Business Central Apps private repository, where we have the pilot of the base application on GitHub, is also powered by ALGo for GitHub and obviously we had to add features to ALGo for supporting these things, and we're also working with Alpaca and other partners to have their requirements and make sure that we support all of the things that they need.
00:18:41.154 --> 00:18:49.213
That's good, and we're talking about AL Go for GitHub, which is a set of templates within GitHub.
00:18:49.213 --> 00:18:51.047
Can you maybe talk a little bit more?
00:18:51.047 --> 00:18:52.346
We talked about managed solutions.
00:18:52.346 --> 00:19:00.143
We mentioned AL Ops, alpaca and AL Go, but maybe a little bit more of what that exactly is For someone that may not know we're talking about.
00:19:00.143 --> 00:19:12.025
I know I talk with a lot of partners, even customers, that are working with their own PTEs, that are looking for ways to manage those extensions and make sure that they're compatible with the newer versions, and you know they run into some challenges.
00:19:12.025 --> 00:19:21.769
But maybe you can break down AL Go in terms that someone can understand its position and what it is exactly doing and how it's of benefit.
00:19:22.960 --> 00:19:34.731
Yeah, so ALGo for GitHub is a plug-and-play DevOps solution for business-central apps, either PTEs or AppSource apps.
00:19:34.731 --> 00:19:44.205
There's no real built-in support for on-premises solutions, but I know multiple partners who are using that for that as well.
00:19:44.205 --> 00:19:54.444
It's not something we are focusing on, but what we are focusing on is if you are a customer, if you are a partner, that are building a PTE.
00:19:54.444 --> 00:20:14.740
Typically, I don't know how things are in various places, but if a customer asks a partner to create a PTE for them, one option could be to have it in a shared repository where the customer actually can see what's going on and the code ownership is for the customer.
00:20:14.740 --> 00:20:24.067
So the customer would basically give the partner access to a repository that they would create and then the partner would create the code.
00:20:24.067 --> 00:20:37.143
The way to create the repository is really to use akams, slash ALGOPTE and say, yes, I want to create a repository, this is my repository, and then invite the partner to this repository.
00:20:37.143 --> 00:20:39.684
I want to create a repository, this is my repository, and then invite the partner to this repository.
00:20:39.684 --> 00:20:45.470
Now the partner can add the code and already at that time workflows and pipelines and release pipelines.
00:20:45.470 --> 00:20:52.856
Everything is set up just by running that simple URL and the only thing you need to do is basically add the code.
00:20:59.500 --> 00:21:01.743
Obviously there can be dependencies.
00:21:01.743 --> 00:21:08.217
That requires the partner to do some setup, but all in all should be fairly simple At least that I think.
00:21:08.217 --> 00:21:28.432
And to set up, and some of the things we're working on now is NuGet support, so that if you have a dependency on other apps, then you can really just specify a NuGet feed from that partner or maybe get symbols from Microsoft to use when you build the apps.
00:21:28.432 --> 00:21:48.491
So trying to make it as easy as possible for people to just always have CI CD set up out of the box without having to ever change a YAML file, change a PowerShell script or maybe install Docker locally.
00:21:48.491 --> 00:22:04.010
Eventually we want to have it integrated to GitHub Codespaces as well, so you can go into your repository and say edit in Codespaces and it's going to open VS Code for you right there in your browser and you can edit that and you can test it out in an online environment or stuff like that.
00:22:04.010 --> 00:22:10.970
All of that should be like plug and play and really you can do that almost on your TV if you have a keyboard right.
00:22:13.560 --> 00:22:17.123
Development has sure changed for this application over the years.
00:22:17.123 --> 00:22:28.005
I go way back to the old cal days of I started working with version 1.1 and the changes that have come around over the past 20 something years are impressive.
00:22:28.005 --> 00:22:44.246
So aogo is a set of templates to help manage and deploy extensions that some that are created for Central, whether they're apps for AppSource or if a customer has a PTE, or even if a partner is doing a PTE for a customer Templates might be a wrong word.
00:22:45.521 --> 00:22:46.105
Say again, please.
00:22:46.105 --> 00:22:48.486
Okay, templates might be a wrong word.
00:22:48.486 --> 00:22:50.420
It really is a starting point.
00:22:50.420 --> 00:22:58.799
It is a template per se, but it also contains a workflow called update algo system files, meaning that it's really the same as updating your Windows.
00:22:58.799 --> 00:23:05.205
So when you install Windows, you get monthly update of Windows and you always have the latest version.
00:23:05.205 --> 00:23:23.236
And that's one of the things that's built into ALGo for GitHub that we release versions continuously and people can upgrade their current workflows to the latest version just by running that script and applying whatever stuff they have in their own repository.
00:23:23.236 --> 00:23:34.173
But typically a template would be a starting point and then you're kind of off to yourself to then maintain it afterwards.
00:23:35.382 --> 00:23:46.722
Okay, I understand, and then with the algo within the workflows, the workflows will do things such as check for changes or breaking changes with compatible versions.
00:23:46.722 --> 00:23:50.782
Is any, are there any configurations that need to be done for that, or is that all part of the base setup?
00:23:50.782 --> 00:23:53.369
After you do the initial part of the base setup.
00:23:53.871 --> 00:24:00.480
but so if you just add code to algo for github GitHub it will build the code whenever you check in changes.
00:24:00.480 --> 00:24:10.605
There's a pull request handler set up so that if you create pull requests then you'll have to do code reviews and stuff like that and then you merge the pull request.
00:24:10.605 --> 00:24:11.468
It's going to do a build.
00:24:11.468 --> 00:24:19.961
If you don't have any releases, it doesn't know what old version to check for the moment.
00:24:19.961 --> 00:24:29.885
You then create a release of your app, algo will automatically check for compatibility with the latest released version of your app, like inside the repository.
00:24:29.885 --> 00:24:36.772
So there you will have breaking change checked all the time.
00:24:36.772 --> 00:24:38.172
Also, if you write.
00:24:38.102 --> 00:24:38.766
That word gives me nightmares.
00:24:38.766 --> 00:24:39.107
Checked all the time.
00:24:39.107 --> 00:24:40.232
Also, if you arrive, that word gives me nightmares.
00:24:40.232 --> 00:24:41.638
By the way, I'm just letting you know.
00:24:41.638 --> 00:24:43.907
I hear breaking change and I just cringe.
00:24:48.605 --> 00:24:55.807
And also, if you have a test app, it will automatically run the test app and show the results of the test.
00:24:55.807 --> 00:25:16.443
If you have BCPT tests, like performance test toolkit tests, they can be set up to run automatically as well within either all your builds or on a daily scheduled test to see whether your app regresses in performance.
00:25:16.443 --> 00:25:25.009
And also, with the latest feature, page scripting and stuff like that we're also looking to implement that.
00:25:25.009 --> 00:25:43.794
So basically, you'll be recording your page scripting tests in the recorder and then the YAML file that comes out of that, you'll check that into your repository and we know that this is a page scripting thingy and just execute that test and show the results as part of your pipeline.
00:25:45.519 --> 00:25:54.928
That's the way that we want to implement these new functionalities is by saying how can we make it as easy as possible for people?
00:25:54.928 --> 00:25:57.009
I mean, typically you'd have to.
00:25:57.009 --> 00:26:06.678
Okay, what code do I need to write in order to run these page scripting tests against my container or my service tier or whatever?
00:26:06.678 --> 00:26:27.616
All of that you don't know, but then we'll make sure that the tests get executed whenever you are running CI, cd or test current or test next major or whatever.
00:26:29.300 --> 00:26:33.153
You had mentioned a point where you could run and check.
00:26:33.153 --> 00:26:37.230
You have and you have your builds run daily to check or you can have it run at intervals.
00:26:37.230 --> 00:26:38.973
Is there a configuration for that?
00:26:38.973 --> 00:26:42.721
And then also with that you mentioned algo is free.
00:26:42.721 --> 00:26:51.790
I know it's a free uh to use on github, but is there a cost to run those workflows regularly, like within github itself?
00:26:51.790 --> 00:26:57.617
Like what type of license or what type of github setup does someone need to have because you can have variant versions of GitHub?
00:26:58.119 --> 00:27:06.203
Yeah, so on GitHub, everything that is public is free and everything that is private has a cost attached to it.
00:27:06.203 --> 00:27:12.442
So if you have a public repository, you can run as many workflows as you want and it doesn't cost you a dime.
00:27:12.442 --> 00:27:22.223
If you have private repositories, based on the school you buy, you can have the basic one.
00:27:23.009 --> 00:27:25.309
I can't remember what it's called.
00:27:25.309 --> 00:27:30.640
So there's two schools for developers and there's three schools for companies.
00:27:30.640 --> 00:27:41.739
The schools for companies is GitHub Enterprise, github Teams I can't remember what the free one is, but let's just say GitHub Free.
00:27:41.739 --> 00:27:56.397
In GitHub Free, you get 2,000 minutes of GitHub actions for free and after that you pay per minute to use your runners.
00:27:56.397 --> 00:28:04.605
You can use self-hosted runners if you want, if you prefer that, so you can set up a few runners and attach those to your AL go.
00:28:04.849 --> 00:28:05.914
That becomes a setup.
00:28:05.914 --> 00:28:07.715
That's something you need to do.
00:28:07.715 --> 00:28:21.583
Obviously, you can find documentation on how to do that, but whether you will save money on that or you'll save money on actually using the GitHub hosted runners, I don't know.
00:28:21.583 --> 00:28:43.623
We are working on making sure that all the builds are running on Linux, so whenever you are building stuff, we are running Linux, which is faster than the Windows runners and it's half the price, so you can actually get a lot of builds done by using a Linux runner.
00:28:43.769 --> 00:29:03.650
The problem is that when we want to run tests, we kind of need a Windows agent, because we need to create a Docker container to run the tests in, and we're investigating various ways of handling that to see whether we can run the test in an online environment.
00:29:03.650 --> 00:29:07.500
If you have a sandbox you don't need, then maybe you can use that.
00:29:07.500 --> 00:29:18.230
It actually speeds up things quite dramatically because you don't need to ever create a container and everything can run Linux if you do that.
00:29:18.230 --> 00:29:41.817
So these are some of the things that we are working on making as smooth as possible so that people can save money and time important with the changes and with technology and with the updates coming readily.
00:29:41.836 --> 00:29:53.295
for Business Central, with the monthly updates as well as the twice a year waves, ensuring that the extensions are compatible and you won't have any of those breaking changes or other issues is important, as well as making sure your tests run properly.
00:29:53.295 --> 00:29:55.078
To me that's important.
00:29:55.078 --> 00:30:13.721
I'm a big advocate for testing and test scripts because I have found countless errors I don't want to say countless, but I found a number of errors with changes that have been made that if the tests weren't there nobody would have caught, or that have even gone through a code review in a sense, when someone is reviewing it.
00:30:13.721 --> 00:30:15.695
So those tests are helpful.
00:30:15.695 --> 00:30:22.441
So having the capacity to be able to do that easily for each pull request is important.
00:30:23.770 --> 00:30:24.472
We will run.
00:30:24.472 --> 00:30:29.661
So in AL Go you'll have a set of artifacts that you develop on.
00:30:29.661 --> 00:30:46.434
So typically you'd have, like I'm developing on, if I say I want to be compatible with version 23, I'll be developing on version 23, because then I'm sure I don't like use 24 features and suddenly become incompatible with the version that I'm working on.
00:30:46.434 --> 00:30:58.644
So if you're working on, let's say, version 23, this, this is the artifacts that you have a development container on and that is the, the artifacts that is used for the CI-CD builds and the testing and all of that.
00:30:58.644 --> 00:31:10.339
Then there are three other workflows that are supplied by ALGO one called Test Current, one called Test Next Minor and one called Test Next Major.
00:31:10.339 --> 00:31:17.896
Test Current will actually say, okay, you are developing on version 23, but the current version is 24.4.
00:31:17.896 --> 00:31:30.022
So I'll run that workflow, maybe on a daily schedule or maybe on a weekly schedule or whatever, and test your code against the current version of Business Central.
00:31:30.022 --> 00:31:38.019
And the next major and the next minor will do the same, just with the next minor, meaning 24.5, and the next major would be 25.0.
00:31:38.632 --> 00:31:44.371
But all are available today as artifacts, Inside artifacts.
00:31:44.371 --> 00:31:51.865
You don't need this token or this key to unlock the inside artifacts.
00:31:51.865 --> 00:31:55.199
The workflows can automatically get them.
00:31:55.199 --> 00:32:09.441
You don't even need to accept the insider agreement because you never see that workflow, You're just running a test against it and you'll never get a container that actually works with that.
00:32:09.441 --> 00:32:42.286
So these things are automatically supported out of the box to make sure that, like you'll see errors that you normally would see three or four months from now, if you're running the next major build and seeing there's a problem in that one and that kind of, I'm hoping that people will will run these on schedule so that they kind of are more ready for when we ship the next major and everybody are then faster to get to the next version.
00:32:43.332 --> 00:32:44.309
No, it's important.
00:32:44.309 --> 00:32:53.760
I see a number of customers receive those warnings when they have an update try to be applied and it says you know, we can't apply the update because your extension is incompatible.
00:32:53.760 --> 00:32:56.144
And this will help extensions incompatible and this will help.
00:32:56.144 --> 00:33:13.577
It's a proactive approach and preventative approach that, as it reduces the risk of interruption to someone receiving an update or into their business central system where if they don't update it, it has it, you know it doesn't get republished after they go outside of their window uh, one part of the algo which you were talking about.
00:33:13.577 --> 00:33:22.821
So with the AL, go for GitHub, it can automatically deploy the apps to an environment as well.
00:33:22.821 --> 00:33:23.345
Is that correct?
00:33:23.345 --> 00:33:28.938
Will it automatically invite you to a sandbox, or both sandbox and production, or can you target?
00:33:28.938 --> 00:33:30.060
You can do both.
00:33:30.690 --> 00:33:40.336
You can also set up continuous deployment to a production environment by default.
00:33:40.336 --> 00:33:51.420
If you point out that you want to deploy to an environment automatically and you don't state anything in settings, it will reject.
00:33:51.420 --> 00:33:55.919
If it's a production environment, it will do it if it's a sandbox environment.
00:33:55.919 --> 00:34:09.512
But you can go into settings and say deploy to prod if that's the name of my production environment, say continuous deployment equals true, then we will also do continuous deployment to the production environment.
00:34:09.512 --> 00:34:15.420
Not sure many customers and partners are ready for that one, but it's possible.
00:34:15.420 --> 00:34:19.222
I mean it's possible.
00:34:19.222 --> 00:34:23.094
I mean it's not something that I should block from not happening by default.
00:34:23.094 --> 00:34:24.893
It is not happening.
00:34:24.893 --> 00:34:29.235
So we're not going to override any customer's apps just by accident.
00:34:30.409 --> 00:34:46.835
But if someone has a workflow that's stable and they want to reduce the risk of whomever is going to load extensions into their environment, they can go through this process and at least have it monitored, checked or the workflow there, and then the sandbox environment can go before.
00:34:47.617 --> 00:34:51.478
Because I do know it's also important to see that there's two types of apps.
00:34:51.478 --> 00:34:52.916
There's PTEs and AppSource apps.
00:34:52.916 --> 00:35:02.757
We cannot deploy an AppSource app to a production environment from a CI-CD pipeline because we can do it to a sandbox environment.
00:35:02.757 --> 00:35:08.461
There we'll deploy it as if we were using VS Code and deploying it into the dev scope.
00:35:08.461 --> 00:35:12.581
But you cannot deploy an AppSource app into the dev scope in a production environment.
00:35:12.581 --> 00:35:17.615
So in a prod environment you have to install it in the right way.
00:35:18.250 --> 00:35:26.016
And if it's an AppSource app, then we do support publishing to AppSource directly from ALGo for GitHub.
00:00:00.980 --> 00:00:07.953
00:00:07.953 --> 00:00:20.393
00:00:20.393 --> 00:00:22.045
00:00:22.981 --> 00:00:23.746
00:00:23.746 --> 00:00:27.768
00:00:27.768 --> 00:00:32.911
00:00:32.911 --> 00:00:36.781
00:00:36.781 --> 00:00:37.804
00:00:37.804 --> 00:00:39.289
00:00:39.289 --> 00:00:51.734
00:00:51.734 --> 00:00:54.308
00:01:11.126 --> 00:01:14.022
00:01:18.468 --> 00:01:19.599
00:01:19.599 --> 00:01:22.284
00:01:22.284 --> 00:01:27.332
00:01:27.332 --> 00:01:30.081
00:01:30.081 --> 00:01:35.072
00:01:35.072 --> 00:01:40.012
00:01:40.012 --> 00:01:41.885
00:01:41.885 --> 00:01:43.469
00:01:44.501 --> 00:01:49.227
00:01:49.748 --> 00:02:02.489
00:02:04.936 --> 00:02:08.945
00:02:08.945 --> 00:02:11.146
00:02:11.146 --> 00:02:13.328
00:02:13.328 --> 00:02:18.633
00:02:18.633 --> 00:02:21.526
00:02:21.526 --> 00:02:23.730
00:02:23.730 --> 00:02:25.520
00:02:25.520 --> 00:02:34.149
00:02:34.149 --> 00:02:39.889
00:03:08.759 --> 00:03:09.302
00:03:09.302 --> 00:03:28.395
00:03:30.221 --> 00:03:37.633
00:03:37.633 --> 00:03:52.609
00:03:52.609 --> 00:04:04.762
00:04:04.762 --> 00:04:20.100
00:04:20.100 --> 00:04:26.392
00:04:27.060 --> 00:04:45.752
00:04:45.752 --> 00:04:56.622
00:04:56.622 --> 00:05:16.865
00:05:16.865 --> 00:05:25.228
00:05:25.228 --> 00:05:35.105
00:05:35.125 --> 00:05:54.634
00:05:54.634 --> 00:06:05.208
00:06:05.208 --> 00:06:12.192
00:06:12.192 --> 00:06:15.208
00:06:15.208 --> 00:06:20.192
00:06:20.192 --> 00:06:23.379
00:06:23.379 --> 00:06:29.653
00:06:29.653 --> 00:06:40.896
00:06:41.261 --> 00:06:47.425
00:06:47.425 --> 00:06:49.350
00:06:49.350 --> 00:06:53.567
00:06:53.567 --> 00:06:59.451
00:06:59.451 --> 00:07:05.045
00:07:05.065 --> 00:07:14.276
00:07:14.276 --> 00:07:20.428
00:07:20.428 --> 00:07:30.740
00:07:30.740 --> 00:07:43.694
00:07:43.694 --> 00:07:48.891
00:07:49.360 --> 00:07:51.127
00:07:51.127 --> 00:07:52.865
00:07:52.865 --> 00:08:00.425
00:08:00.425 --> 00:08:07.815
00:08:07.815 --> 00:08:11.324
00:08:11.324 --> 00:08:20.305
00:08:20.305 --> 00:08:23.670
00:08:23.670 --> 00:08:33.289
00:08:34.081 --> 00:08:43.147
00:08:43.147 --> 00:09:03.186
00:09:03.186 --> 00:09:05.000
00:09:05.000 --> 00:09:15.183
00:09:15.183 --> 00:09:27.985
00:09:29.399 --> 00:09:36.894
00:09:36.894 --> 00:09:42.244
00:09:42.244 --> 00:09:50.572
00:09:50.572 --> 00:10:05.412
00:10:05.412 --> 00:10:13.994
00:10:15.861 --> 00:10:43.107
00:10:43.107 --> 00:10:57.633
00:10:57.633 --> 00:11:21.047
00:11:23.873 --> 00:11:27.485
00:11:27.620 --> 00:11:39.249
00:11:39.701 --> 00:12:03.207
00:12:03.207 --> 00:12:06.474
00:12:06.474 --> 00:12:17.153
00:12:17.153 --> 00:12:23.309
00:12:23.309 --> 00:12:37.630
00:12:37.630 --> 00:12:40.105
00:12:41.570 --> 00:12:49.010
00:12:49.522 --> 00:13:20.078
00:13:20.099 --> 00:13:26.647
00:13:27.519 --> 00:13:55.514
00:13:55.514 --> 00:14:06.504
00:14:06.504 --> 00:14:22.666
00:14:22.666 --> 00:14:42.965
00:14:44.769 --> 00:14:46.956
00:14:46.956 --> 00:14:54.131
00:14:54.131 --> 00:14:55.660
00:14:55.660 --> 00:15:13.827
00:15:13.827 --> 00:15:29.192
00:15:29.192 --> 00:15:37.701
00:15:37.701 --> 00:15:40.032
00:15:40.091 --> 00:15:50.568
00:15:50.568 --> 00:16:03.787
00:16:03.787 --> 00:16:24.994
00:16:24.994 --> 00:16:35.304
00:16:35.304 --> 00:16:36.326
00:16:36.326 --> 00:16:40.029
00:16:40.029 --> 00:16:43.494
00:16:43.494 --> 00:16:46.197
00:16:46.197 --> 00:16:53.269
00:16:53.269 --> 00:17:00.033
00:17:00.033 --> 00:17:08.753
00:17:14.440 --> 00:17:46.232
00:17:47.340 --> 00:17:52.613
00:17:52.613 --> 00:18:07.830
00:18:07.830 --> 00:18:39.792
00:18:41.154 --> 00:18:49.213
00:18:49.213 --> 00:18:51.047
00:18:51.047 --> 00:18:52.346
00:18:52.346 --> 00:19:00.143
00:19:00.143 --> 00:19:12.025
00:19:12.025 --> 00:19:21.769
00:19:22.960 --> 00:19:34.731
00:19:34.731 --> 00:19:44.205
00:19:44.205 --> 00:19:54.444
00:19:54.444 --> 00:20:14.740
00:20:14.740 --> 00:20:24.067
00:20:24.067 --> 00:20:37.143
00:20:37.143 --> 00:20:39.684
00:20:39.684 --> 00:20:45.470
00:20:45.470 --> 00:20:52.856
00:20:59.500 --> 00:21:01.743
00:21:01.743 --> 00:21:08.217
00:21:08.217 --> 00:21:28.432
00:21:28.432 --> 00:21:48.491
00:21:48.491 --> 00:22:04.010
00:22:04.010 --> 00:22:10.970
00:22:13.560 --> 00:22:17.123
00:22:17.123 --> 00:22:28.005
00:22:28.005 --> 00:22:44.246
00:22:45.521 --> 00:22:46.105
00:22:46.105 --> 00:22:48.486
00:22:48.486 --> 00:22:50.420
00:22:50.420 --> 00:22:58.799
00:22:58.799 --> 00:23:05.205
00:23:05.205 --> 00:23:23.236
00:23:23.236 --> 00:23:34.173
00:23:35.382 --> 00:23:46.722
00:23:46.722 --> 00:23:50.782
00:23:50.782 --> 00:23:53.369
00:23:53.871 --> 00:24:00.480
00:24:00.480 --> 00:24:10.605
00:24:10.605 --> 00:24:11.468
00:24:11.468 --> 00:24:19.961
00:24:19.961 --> 00:24:29.885
00:24:29.885 --> 00:24:36.772
00:24:36.772 --> 00:24:38.172
00:24:38.102 --> 00:24:38.766
00:24:38.766 --> 00:24:39.107
00:24:39.107 --> 00:24:40.232
00:24:40.232 --> 00:24:41.638
00:24:41.638 --> 00:24:43.907
00:24:48.605 --> 00:24:55.807
00:24:55.807 --> 00:25:16.443
00:25:16.443 --> 00:25:25.009
00:25:25.009 --> 00:25:43.794
00:25:45.519 --> 00:25:54.928
00:25:54.928 --> 00:25:57.009
00:25:57.009 --> 00:26:06.678
00:26:06.678 --> 00:26:27.616
00:26:29.300 --> 00:26:33.153
00:26:33.153 --> 00:26:37.230
00:26:37.230 --> 00:26:38.973
00:26:38.973 --> 00:26:42.721
00:26:42.721 --> 00:26:51.790
00:26:51.790 --> 00:26:57.617
00:26:58.119 --> 00:27:06.203
00:27:06.203 --> 00:27:12.442
00:27:12.442 --> 00:27:22.223
00:27:23.009 --> 00:27:25.309
00:27:25.309 --> 00:27:30.640
00:27:30.640 --> 00:27:41.739
00:27:41.739 --> 00:27:56.397
00:27:56.397 --> 00:28:04.605
00:28:04.849 --> 00:28:05.914
00:28:05.914 --> 00:28:07.715
00:28:07.715 --> 00:28:21.583
00:28:21.583 --> 00:28:43.623
00:28:43.769 --> 00:29:03.650
00:29:03.650 --> 00:29:07.500
00:29:07.500 --> 00:29:18.230
00:29:18.230 --> 00:29:41.817
00:29:41.836 --> 00:29:53.295
00:29:53.295 --> 00:29:55.078
00:29:55.078 --> 00:30:13.721
00:30:13.721 --> 00:30:15.695
00:30:15.695 --> 00:30:22.441
00:30:23.770 --> 00:30:24.472
00:30:24.472 --> 00:30:29.661
00:30:29.661 --> 00:30:46.434
00:30:46.434 --> 00:30:58.644
00:30:58.644 --> 00:31:10.339
00:31:10.339 --> 00:31:17.896
00:31:17.896 --> 00:31:30.022
00:31:30.022 --> 00:31:38.019
00:31:38.632 --> 00:31:44.371
00:31:44.371 --> 00:31:51.865
00:31:51.865 --> 00:31:55.199
00:31:55.199 --> 00:32:09.441
00:32:09.441 --> 00:32:42.286
00:32:43.332 --> 00:32:44.309
00:32:44.309 --> 00:32:53.760
00:32:53.760 --> 00:32:56.144
00:32:56.144 --> 00:33:13.577
00:33:13.577 --> 00:33:22.821
00:33:22.821 --> 00:33:23.345
00:33:23.345 --> 00:33:28.938
00:33:28.938 --> 00:33:30.060
00:33:30.690 --> 00:33:40.336
00:33:40.336 --> 00:33:51.420
00:33:51.420 --> 00:33:55.919
00:33:55.919 --> 00:34:09.512
00:34:09.512 --> 00:34:15.420
00:34:15.420 --> 00:34:19.222
00:34:19.222 --> 00:34:23.094
00:34:23.094 --> 00:34:24.893
00:34:24.893 --> 00:34:29.235
00:34:30.409 --> 00:34:46.835
00:34:47.617 --> 00:34:51.478
00:34:51.478 --> 00:34:52.916
00:34:52.916 --> 00:35:02.757
00:35:02.757 --> 00:35:08.461
00:35:08.461 --> 00:35:12.581
00:35:12.581 --> 00:35:17.615
00:35:18.250 --> 00:35:26.016