A few days ago a Windows update rolled out that broke pipelines all over the place and the suggested workaround is to use hyper-v isolation instead of process isolation so that the container is not affected by whatever happened on the host.In addition to Freddy’s blog about what happened and Read more…
In my last post, The true story behind my build service for NAV/BC I wrote about what it took to build a small, but scalable cloud service.In this post, I’ve got something to announce, so let’s get started! From now on I’m offering a free trial period + configuration for Read more…
Usually, I write posts about a certain technical subject, but not today.
Today I’ll tell you the true story behind my build service for NAV/BC and I hope I’ve challenged you by the time you reach the end of this post.
Today is a good day, today the 1000th build ran on my CI service for Dynamics 365 BC/NAV and that feels like a huge achievement if I look back at how this all started.
I initially came up with this idea of a generic build service almost two years ago, in those two years the code has been rewritten twice and I’ve changed from a build API approach to a service exclusively for Azure DevOps.
Next to that, Docker came around, Business Central replaced NAV, C/SIDE is now retired, we got AL in return and I probably forgot to mention a lot of other disruptors.
Last week, I was working on the final bits of a release pipeline for Business Central in Azure DevOps and all that was left was to import a couple of RapidStart packages in an automated (PowerShell) fashion.
The only (future-proof) automated way of doing this is by using the automation APIs as described here.
Seems do-able, right…?
It has been 7 months since I released my VS Code extension called NAVBaaS Git, a free extension that seamlessly integrates your C/SIDE development with Git and Docker. (you can read all about it here)With 544 unique installations and almost 1400 downloads, it’s safe to conclude that quite a number Read more…
In my previous blog post, we looked at how to authenticate and call the Business Central Admin Center Telemetry API, we ended up with a response message that we could not deserialize into a C# class.
Luckily some guys from Microsoft stumbled upon my blog post and asked for feedback, which resulted in a backlog item on their side to provide key-value pairs in the response.
Today we’ll look at how to transform the response into a class that we can then use to create a JSON message that’s importable by Azure Log Analytics.
Azure Log Analytics is the place where logs from all kinds of different resources come together for further analysis, these resources can be virtual machines, logs from Azure Functions or security events from the Azure platform itself, but there’s also a data collector API and that’s where we will send the Business Central telemetry to.
With Business Central you get something called Business Central Admin Center, the place where tenant admins and delegated admins (the partner associated with the tenant) perform admin tasks like manage environments, set upgrade windows and view telemetry.
Everything you can do through the admin center can also be done through the APIs, today we’ll have a look at how to consume the telemetry API from a simple C# console application and create the foundation for the next blog post where we will go one step further and transform the data returned by the API into a proper JSON structure that can be sent to Azure Log Analytics.
For the people that missed out on the session called ‘Performance: Business Central reloaded for the Cloud’ at the #navtechdays this year, it’s extremely important to catch-up with the topics discussed as this was the most informative session at the event.
One key takeaway of the session is about that magic thing that solves all our problems when going from C/AL to AL, that’s right, we’re talking about events!
Oh, and by the way, the recording of that session can be found here.
What do you do when you need to kill some time in a hotel before the NAV TechDays break loose? That’s right, write a blog post!
This one has been on my list for quite some time now but there were always more interesting things to blog about, but now it’s time to finally take care of the Upgrade Tags.
Somewhere in the development of Business Central the table Upgrade Tag and codeunit Upgrade Tag Mgt. appeared, but what are they meant for?
Let’s find out!
We’re in an era where we are expected to deliver software more often and to deliver it faster, in other words, we’re expected to be agile.
In order to be agile, we need continuous integration, continuous integration is a practice where members of a team integrate their work several times a day into a shared mainline.
Each integration should be verified by a build (including tests) to detect integration errors as quickly as possible.
This is just a brief explanation of continuous integration as I just want to set the stage for the official release of my generic build service called NAVBaaS!
Last week at directions Microsoft did a demo where they’ve shown the full solution running as an extension with only the system objects left in C/SIDE, that’s great, right?
In this blog, I’ll share my thoughts on the subject and make you aware of the impact it has.
Just two weeks ago I released the initial version of my VS Code extension NAVBaaS Git at the Dutch Dynamics Community event, in case you missed it, you can catch up here.
At first, I want to thank everyone that downloaded the extension and especially the people that gave me feedback, it’s highly appreciated and please keep giving feedback!
In this blog post, I’ll give you a brief update on the new features that I’ve added to the extension over the last two weeks.
I’m very happy to announce that my first Visual Studio Code extension called NAVBaaS Git has been released last Wednesday.
The people who attended the session about Continuous Integration at the Dutch Dynamics Community event already had their first glimpse at the brand new extension and I really hope that people are or will be excited about this extension.
Source control is step one if you want to do professional development and with source control in place you’re able to take the next step, which is Continuous Integration!
When running AL and C/SIDE side by side you always want to have your symbols up to date, this can be done by starting up finsql.exe with the parameter generatesymbolreference=yes as described here, but it’s also possible to generate symbols at compile time when using the Compile-NAVApplicationObject cmdlet.
With the release of the latest development preview most of the functions in the test libraries are marked as external, meaning they can be used for extension development!
With the current test framework and it’s limitations it can sometimes be hard to find a way to test your code, this gets even worse when external web services are called.
I’ve seen a number of (bad) workarounds in the last few months varying from calling a nonexistent endpoint to a self-hosted web service to test against.
Of course those workarounds do their job but we can do better than that, and let’s not forget tests must be independent of external components!
Ideally we would simply mock this web service call and return some data we can test against, but not in (C/)AL right?
Every now and then a developer takes the xRec bait and they’re wondering why their code doesn’t work and it usually ends up with a lot of lost time combined with a good amount of frustration.
I hope most of you do know that if you trigger the OnModify through code and xRec is used in the OnModify trigger, Rec and xRec will be the same, however it works fine when it’s triggered through the UI. (more…)
With AL you can already create test codeunits, write test functions but you have to use your own libraries because all functions in the standard libraries are not marked as external.. After reporting an issue on GitHub Microsoft confirmed they’ll be marked as external in the January update! In my Read more…
The time has come, we can finally run multiple NAV versions, cu’s and localization’s side by side with Docker, but how do we actually move our old and dusty c/side development environment to a modern place? (more…)
In the ideal world you have a nightly build, creating your entire solution from scratch, running all the automated tests that come with standard NAV and so on.
During business hours you basically want the same thing but a lot faster, you want to have feedback about your modifications as quickly as possible and running all the tests might be unnecessary and it’s very much time consuming.
Automating your automated tests is just as important as creating and maintaining them, you want to be able to run your tests at least once a day and ideally multiple times a day or even after every check-in.
All we have to invoke these automated tests is PowerShell but there’s another challenge because the automated tests require a user interface and the Invoke-NAVCodeunit cmdlet does not support this.