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.
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!