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…?