Episode 338: In the Dynamics Corner Chair: Efficient Development with AL-Go for GitHub

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:35:26.016 --> 00:35:43.860
We will automatically submit it to validation and thereafter actually even take it live in AppStore if you want to do that.

00:35:43.860 --> 00:35:55.797
But typically if you don't state anything, it will be validated and set where you need to go into the partner center portal and say go live with this app, else it'll stay there.

00:35:55.797 --> 00:36:21.128
And if you now the latest version, we also support preview of app source apps and at that point in time what we really do when we publish to app source without going live is to put it in preview and people can now, from that production environment, install the preview if they like that and then you can test it, you can go live and then they can install the final version there.

00:36:22.411 --> 00:36:32.358
So, talking about that preview version of an app, is that something that partners can give to specific customers to test new functionality?

00:36:32.358 --> 00:36:38.911
Is that the focus for it, where you can give specific customers reference to a version or preview version to work with?

00:36:40.135 --> 00:36:53.059
so when, when you, when you publish an app to app source, it goes through like a validation process and then it it, if you have created what's called a flight code, then it's in preview for the people who has that flight code.

00:36:53.059 --> 00:36:58.096
You can give that to customers or partners and they can then install the preview version of that app.

00:36:58.096 --> 00:37:07.795
Um, with that flight code, you can give that to customers or partners and they can then install the preview version of that app with that flight code and then they can install the final version once that gets shipped.

00:37:07.815 --> 00:37:08.898
That's good, that's a new feature.

00:37:09.318 --> 00:37:22.280
I've been hearing about that quite a bit and it's also good for partners or anyone who has an app AppSource to get some additional testing or functionality review for customers before releasing it to widespread use within it.

00:37:22.280 --> 00:37:38.579
You had mentioned, when setting up a GitHub repository for a new PTE or a new AppSource app again, ptes would be for customer environments, appsource apps would go to AppSource that you could run the AKMS, pte, load, pte.

00:37:38.579 --> 00:37:41.304
I forget what to wish ALGO PTE, algo, pte.

00:37:41.304 --> 00:37:44.659
I know there's two of them, one for apps and one for PTE.

00:37:44.659 --> 00:37:48.619
What about for an existing repository?

00:37:48.619 --> 00:38:04.059
So now, if someone's been working with an AppSource app or a PTE in a GitHub repository, is there a way to apply the AL Go workflows to that repository or is it better to create a new repository and copy in the code?

00:38:07.070 --> 00:38:10.300
I haven't actually thought too much about applying.

00:38:10.300 --> 00:38:12.556
There's a few ways of doing it.

00:38:12.556 --> 00:38:22.800
You can create a new repository and then you can import the git history from the old repository and basically get everything in there.

00:38:22.800 --> 00:38:27.603
But you can also that's probably you can do that from Azure Deluxe to GitHub.

00:38:27.603 --> 00:38:37.684
You can also take I don't know if I have a documentation on that specific one there are some in ALGo.

00:38:37.684 --> 00:38:44.293
You can go to the documentation, the readme.

00:38:44.293 --> 00:38:52.239
There are a few ways that it's documented on how to take an existing repository and make that into an ALGo repository.

00:38:52.239 --> 00:38:58.536
Not sure that you can do that with a GitHub repository.

00:38:58.536 --> 00:39:00.221
I'm not sure it's documented.

00:39:00.221 --> 00:39:20.469
You can obviously do it, but I'll write that down on a piece of paper and then add that to the docs, Because it is really just adding some files to your repository and then ALGo should more or less be able to take it from there should more or less be able to take it from there.

00:39:22.630 --> 00:39:34.518
No, that would be great if there's some documentation on that process or that situation for those partners or customers that are managing their code with source control such as GitHub and now, with AL Go becoming more and more popular, to be able to add that to the repository.

00:39:34.518 --> 00:39:43.081
Speaking of ALGo and you mentioned the documentation where can someone find more information on ALGo?

00:39:43.081 --> 00:39:44.596
Where do they obtain ALGo?

00:39:45.730 --> 00:39:46.514
You can find that in the.

00:39:46.534 --> 00:39:50.117
GitHub repo In the GitHub repo for ALGo.

00:39:50.117 --> 00:39:54.190
It's in the Microsoft repo and you can search for ALGo and find it.

00:39:54.952 --> 00:40:24.465
You can also do akams slash ALGo workshop, which will take you to it's an area in the ALGo repo, really, where there's some MD files that takes you through the workshop on how to set things up, how to do releasing versions, how to do a lot of things, and a lot of things that are not yet documented are there, just as lines to be documented.

00:40:24.465 --> 00:40:26.130
So we're working on that.

00:40:26.130 --> 00:40:39.402
It's a continuous involvement, really, of this, and whenever we get new ideas, it goes into the, into the backlog, and we'll try to make that happen.

00:40:39.402 --> 00:40:51.842
We also have a few partners that contribute to ALGrow, which we are happy for, but obviously the idea is that partners, most partners, will just use it as a tool.

00:40:51.842 --> 00:40:59.882
Some partners, if they have the capacity to actually co-develop ALGo with us, they are more than welcome to do that.

00:40:59.882 --> 00:41:01.244
The more the merrier.

00:41:01.244 --> 00:41:20.384
We are three people right now working on ALGo for GitHub Obviously me and then two other guys, or a girl and a guy, and yeah, we'll be trying to keep up with all the requirements that are coming from partners and customers.

00:41:22.489 --> 00:41:24.195
It's like drinking from a water hose.

00:41:24.195 --> 00:41:26.021
I call it, or a fire hose, excuse me.

00:41:26.021 --> 00:41:30.797
And it's not just AL Go, it's just with Business Central.

00:41:30.797 --> 00:41:43.192
The number of changes, number of features, technology is advancing customer requirements, everything's becoming easier, but because it's easier it's becoming faster, so it's almost like a cycle of.

00:41:43.192 --> 00:41:47.161
I feel like I'm constantly running to keep up, as I guess you could say.

00:41:47.161 --> 00:42:05.958
But having tools such as VC Container Helper and ALGO do facilitate that process where you don't have to become an expert in the workflows or you know creating Docker containers and downloading images and setting pieces up the AL Go workshop.

00:42:05.958 --> 00:42:13.797
I know you do a number of sessions for AL Go and I know in September upcoming to be Days of Knowledge US.

00:42:13.797 --> 00:42:16.715
Are you going to be attending Days of Knowledge in the United States?

00:42:18.541 --> 00:42:42.655
I'll be there and I have a few sessions about Elgo and some of the things that we talked about here, also some like getting started session and a more advanced session, and I'm also looking to see who's there to see if I can get some feedback from partners who are using it already to get some good ideas and what can we do better and what should we do differently.

00:42:42.655 --> 00:42:59.802
I'm always looking for that when I'm at conferences to get feedback on where people are struggling and where people are running into dead ends, to make sure that we can do it better than we're doing already I understand.

00:42:59.889 --> 00:43:05.210
So in days of knowledge in the United States you'll be having a workshop or a session on ALGO.

00:43:05.210 --> 00:43:11.230
So if anybody who wants to get some hands-on or to learn a little bit more about it, they can also attend that conference.

00:43:11.349 --> 00:43:14.561
There's no hands-on labs per se, but there's sessions.

00:43:15.329 --> 00:43:20.398
Sessions where you walk through how to set up and use ALGO and then also be able to answer some questions, which will be good.

00:43:20.398 --> 00:43:23.239
I will be there.

00:43:23.239 --> 00:43:27.135
Chris is going to the Power Platform Conference, so we switched on this one.

00:43:27.135 --> 00:43:27.677
Usually we go.

00:43:28.190 --> 00:43:29.898
The next week you can go both places.

00:43:34.231 --> 00:43:35.356
We've got to spread ourselves.

00:43:37.110 --> 00:43:38.277
It's also coast to coast.

00:43:38.277 --> 00:43:42.942
It's a stretch across the country for Chris to go and come back for the two conferences.

00:43:42.942 --> 00:43:52.202
And that's why I'll just do the Data Knowledge United States one as well, because it gets a lot to fly back and forth all over the place.

00:43:54.371 --> 00:43:58.239
I have quite a few business central conferences around the world.

00:43:58.719 --> 00:44:01.981
Oh, yeah, oh, more than you can count right now.

00:44:02.389 --> 00:44:09.001
Yeah, there's quite a few, and that's one of the questions I always have, or you know, or get asked.

00:44:09.001 --> 00:44:09.911
I like to talk to him as well.

00:44:09.911 --> 00:44:11.836
As you know, it's outside of.

00:44:11.836 --> 00:44:14.342
You know the ALGO or BC Container Helpers?

00:44:14.342 --> 00:44:16.733
Like which ones do you go to the ALGO or BC Container Helpers?

00:44:16.733 --> 00:44:17.813
Like which ones do you go to?

00:44:17.813 --> 00:44:19.755
Right, because you have Dynamic Minds.

00:44:19.755 --> 00:44:20.916
You have BC Tech Days.

00:44:20.916 --> 00:44:26.164
You have Directions EMEA, you know Directions Asia, directions North America, days of Knowledge.

00:44:26.164 --> 00:44:28.346
You have Dynamics User Groups.

00:44:28.346 --> 00:44:31.943
So there's a lot of conferences and there's a few others.

00:44:31.943 --> 00:44:34.637
On there too, there's a lot of great information.

00:44:34.637 --> 00:44:40.219
It's just important to just strategize and plan so you get the right ones, that you get the most out of it, which is important.

00:44:41.010 --> 00:44:44.494
I've always, I think I've attended every single Days of Knowledge conference.

00:44:44.695 --> 00:44:50.418
There were Really Not Days of Knowledge every single Tech Days conference.

00:44:50.418 --> 00:45:27.701
In all the years I think I've went to Anver and what I like about these technical conferences is really that not only will people I mean, if you go into a session and you see a lot of stuff and you hear a lot of stuff, you're not going to remember everything, right, but you're going to get some, you're going to see, you'll have an overview of what's possible and you know where to look and you'll start thinking about how to do things smarter.

00:45:27.701 --> 00:45:52.541
So going to conferences and learning technical stuff, I think is something that partners should prioritize for their people, because people will really be much more innovative if they know more about what's possible and what's coming and what's trending and all of these things.

00:45:52.541 --> 00:45:57.139
You will get people's mind working and not only their hands and feet.

00:45:57.139 --> 00:45:58.603
But you can, like you can.

00:45:58.603 --> 00:46:01.916
Your people will be much more satisfied, right?

00:46:01.916 --> 00:46:12.302
So I cannot, yeah, stress enough that partners should really send their their technical people to technical conferences and and learn stuff.

00:46:12.722 --> 00:46:17.442
It's, it is important I agree with you I, it's absolutely important, I agree.

00:46:20.637 --> 00:46:33.481
It's important to also support their customers so it gets the technical talent that they have, whether it be functional consultants or developers that go to these, or even solution architects, whatever roles you have, as you mentioned.

00:46:33.481 --> 00:46:48.760
But I'll call more on the implementation side, just so that they know what's aware, they know what's positive, they know what's coming so they can solution Business Central better or also implement it a bit better, so that they can know what to expect and what's going on.

00:46:49.170 --> 00:46:52.295
So it's interesting that we have a Days of Knowledge in America now.

00:46:52.295 --> 00:46:54.398
I hope there's going to be a lot of attendance.

00:46:54.398 --> 00:46:56.516
So I hope it's going to be a lot of attendance.

00:46:56.516 --> 00:46:58.789
So I hope it's something that's going to be a recurring event.

00:46:58.789 --> 00:47:10.021
Obviously, the Directions Committee cannot run sessions in the US if only two guys show up, because I assume there are more than two guys.

00:47:11.210 --> 00:47:12.195
I'm hopeful there will be.

00:47:12.195 --> 00:47:16.922
I mean, it's the first year, so hopefully they'll have enough of an attendance.

00:47:17.230 --> 00:47:18.054
We'll do this again.

00:47:18.735 --> 00:47:19.452
Yes, that's.

00:47:19.612 --> 00:47:36.530
I'm hopeful for that too, because I do feel that we need to have those technical conferences or those technical tracks at conferences, uh, where consultants uh, you know, those that are in the field, as I'll say can get a good look at what is there, what is coming, and also see how to do some things.

00:47:36.530 --> 00:47:46.041
You know, as you had mentioned, it gets me thinking, when I go to see some of these sessions and conferences, of how to solution better, which is extremely important.

00:47:46.041 --> 00:47:52.282
Well, freddie, thank you for taking the time to talk with us today about BC Container and ALGO.

00:47:52.282 --> 00:47:56.081
I'm going to go back now and play with it again myself.

00:47:56.081 --> 00:47:57.596
I just want to try some new things.

00:47:57.596 --> 00:47:57.990
Every time.

00:47:57.990 --> 00:47:58.652
I see.

00:47:58.652 --> 00:48:00.679
I follow everything that you put.

00:48:00.679 --> 00:48:02.835
I follow the ALGO, I follow the BC Container Help.

00:48:02.835 --> 00:48:06.313
As I mentioned, I use it daily, several times a day.

00:48:06.313 --> 00:48:11.855
I'm doing something with containers, even if I just need to do a quick test of something that it doesn't require.

00:48:13.050 --> 00:48:17.722
It's a little easier than downloading the DVD and installing that and uninstalling the old version.

00:48:17.742 --> 00:48:20.813
Yes, yes, and sometimes it's again.

00:48:20.813 --> 00:48:37.519
It's where a sandbox environment may not be again, because the whole you know the online environments if I have a sandbox as well too, but again, as you had mentioned, it's a lot easier to just spin up a Docker container sometimes in my workflow some days, so I appreciate the tools that your team has put together some days.

00:48:37.519 --> 00:48:40.047
So I appreciate the tools that your team has put together.

00:48:40.047 --> 00:48:47.097
I know personally it's simplified my days and helped a lot of customers as well too, because of that simplification.

00:48:47.097 --> 00:49:02.940
If someone wanted to learn more about BC Container, algo, there are GitHub repositories for both of them and in that GitHub repository if they have any questions, I know that you're very responsive to the issues and then someone can keep up with the changes as well.

00:49:02.940 --> 00:49:16.898
If anyone else wanted to get in touch with you if they had additional questions about additional questions or feedback on ALGO or BC Container Helper, what's the best way to get in contact with you?

00:49:19.949 --> 00:49:29.494
Typically like if people have anything on bc container helper or al go, it would be create questions or issues directly in the in the github repos, right?

00:49:29.494 --> 00:49:44.612
Um, the github repo for el go with uh yeah, githubcom slash Microsoft slash AL dash go and the GitHub repo for the BC container helper is githubcom slash Microsoft slash container helper.

00:49:44.612 --> 00:49:55.313
So it's still the repository, is still called nav container helper, but that's where everything is and there's an issues box there where you can go and ask questions or whatever else.

00:49:55.313 --> 00:49:59.496
I mean people are also free to shoot me an email, freddyk at microsoftcom.

00:49:59.496 --> 00:50:07.315
I'd be more than happy to answer, but be prepared that I might say please create an issue here instead.

00:50:07.315 --> 00:50:15.536
It's easier to track issues like that on GitHub than it is to track where the heck is that email.

00:50:18.655 --> 00:50:18.835
I agree.

00:50:18.835 --> 00:50:26.958
I agree with you and with that, if somebody has an issue or a question, I'd like seeing them in the issues because it may help others as well.

00:50:27.170 --> 00:50:36.780
Because if one person has a question, if one person thinks something is an issue, it's a good place to go, because I had something that I had an issue.

00:50:36.780 --> 00:50:41.541
I had some errors on that I saw on the issues list and I was able to easily remedy without having to contact anybody.

00:50:41.541 --> 00:50:44.934
So having it in there is some good use for that.

00:50:44.934 --> 00:50:49.164
So that response is welcomed, I think, by many.

00:50:49.164 --> 00:50:57.400
It's important for others to realize that on these GitHub repositories, that's a great resource as well If you have questions to look at through the history and to be able to search them.

00:50:57.400 --> 00:51:05.184
Hopefully GitHub will get a little better with the searching, but that's not our space for that.

00:51:05.184 --> 00:51:08.177
But again, thank you for taking the time to speak with us today.

00:51:08.177 --> 00:51:09.335
I really appreciate it.

00:51:09.335 --> 00:51:19.096
I definitely look forward to seeing you in a few weeks at Days of Knowledge United States and to also learn a little bit more about ALGO while I'm there.

00:51:20.150 --> 00:51:21.034
Looking forward as well.

00:51:21.034 --> 00:51:26.882
Thanks for inviting me and have a nice trip to Vegas, christopher.

00:51:26.882 --> 00:51:30.661
Yeah, he gets to go to Vegas, it's going to be a tough one.

00:51:30.661 --> 00:51:34.614
Okay it'll be tough.

00:51:34.614 --> 00:51:36.719
Have a good one.

00:51:36.719 --> 00:51:37.081
Thanks, Freddie.

00:51:38.715 --> 00:51:47.635
Thank you, chris, chris, for your time for another episode of In the Dynamics Corner Chair and thank you to our guests for participating thank you, brad, for your time.

00:51:47.856 --> 00:51:51.077
it is a wonderful episode of Dynamics Corner Chair.

00:51:51.077 --> 00:51:54.596
I would also like to thank our guests for joining us.

00:51:54.596 --> 00:51:57.619
Thank you for all of our listeners tuning in as well.

00:51:57.619 --> 00:52:12.141
You can find Brad at developerlifecom, that is D-V-L-P-R-L-I-F-E dot com, and you can interact with them via Twitter D-V-L-P-R-L-I-F-E.

00:52:12.141 --> 00:52:25.561
You can also find me at matalinoio, m-a-t-a-l-i-n-o dot I-O, and my Twitter handle is matalino16.

00:52:25.561 --> 00:52:29.206
And you can see those links down below in the show notes.

00:52:29.206 --> 00:52:30.567
Again, thank you everyone.

00:52:30.567 --> 00:52:33.952
Thank you and take care.