The true story behind my build service for NAV/BC

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.

In this rapidly changing world, building and maintaining a generic build service for BC/NAV is not just about writing some PowerShell functions and ship that to customers.
Also with a small service you have to get used to a dynamic world where you adapt to changes quickly and you’ll need to accept the fact that the service will always be in beta, just like Business Central.
With a cloud service, you’re responsible for everything and you need to have a lot of things in place, for example, logging, monitoring, tenant provisioning, security and a lot of unit tests to ensure quality.
And even then, things can go wrong and they will go wrong, but that’s okay, if you move fast, you break things 🙂

Since I’ve released the service at the end of last year, I haven’t blogged about it once, due to the fact that I didn’t have all those SaaS things in place and I wanted to have time to implement that and give my first two customers the best possible experience.
In case you’ve read the book Blitzscaling by Reid Hoffman and Chris Yeh (must read if you’re an entrepreneur), this is called controlled, efficient growth and this is a great way to figure out a product-market fit.

Is it a great product-market fit?

It is and it is not, while there’s a lot of attention for CI/CD at conferences like the NAV TechDays and Directions, there’s literally no traction when it comes to purchasing a third-party service that handles your entire CI process for a small amount of money per month.
That’s really weird, right? I mean, what can you do for €200 per month? (€200 is the cost of using my build service for AL projects, including infrastructure)
Let’s say you’re building your own CI process just for AL, you’ll most likely spend a couple of weeks developing it (sunny scenario) and then you think you’re done, but you’re not.
If you’ve ever built a CI process internally (maybe for C/AL), you’ll agree with me that it’s an ongoing process and that it will always be in development, to put it differently: it’s a huge distraction for you and your team and it might even hold the company back from what it wants to achieve.

Even with all the code being shared by various people on GitHub (kudos for that), you still need to tie everything together (assuming that it covers your scenarios) and you still need to maintain the code, manage infrastructure, etc. etc.
I’m not writing this post to make you buy my build service (which would be great of course), but I’m writing this to challenge you to also look at the business side of things.
If you currently have a CI process in place, you probably spend more than €2400 (€200 x 12 months) per year on it if you sum up labor and infrastructure costs, am I right?

Us developers (yes I’m also a developer) are not used to look at the business side of things, if we need it, we build it, even though another Dynamics partner or company already has a solution or the knowledge to help you out.

Let’s stop to reinvent the wheel, change our mindset and help each other out, it will be way more fun!

5 Comments

Dr. Jonas Dee · June 18, 2019 at 8:06 pm

There are different types of people in this community. Some are happy to share their work and help others. Bug kudos to them. Then there are those that just need to get things done and are happy to consume the work of others. Then there are some who will never consume the work of others, because no matter what it is, they will always consider their own way superior. And then there are those that make a secret of everything because … you know … “my business, my secrets, my profit!”. It will be hard to unite those people under one common banner, I guess.

Anyway: I agree with you. Stop reinventing the wheel. But there is one big problem with that: Whatever it is, that the community provides, it is still that: something unofficial by someone who invests time in it. And just as you say … NAV/BC is a moving target. What happens if that very target begins moving so damn fast, that the community project I happily relied upon decides that it can no longer keep up and shuts its doors? There I stand. In the desert. With nothing in hand. Of course, you are right, its something that can always happen. But with something so new and fresh and evolving as AL … I expect fast and heavy changes. I actually prefer building myself some knowledge of stuff, so I can react on my own, if I need to. At this stage of our world, depending on something/someone “external” is handy, but dangerous.

So for the business side of things: how much am I willing to “trust” in the future of the tech and tools I use? How much am I willing to commit myself to them?

Don’t get me wrong: I still think you did a great job with your service, and both thumbs up for it But I also think that we need to be careful. Community stuff regarding AL/NAV/BC is sprouting like fungus these days. Time will tell what and how things survive. We might end up locking our selves into something and loose the “openess” and freedom we just gained with VSCode and such.

    richardr · June 18, 2019 at 8:34 pm

    Hey Jonas,

    Thanks a lot for your reply, I really appreciate it and you seem challenged by the post, which is what I wanted to achieve.

    I agree that jumping into community projects is not always a good thing, simply because there’s no financial motivation for the participants to innovate and maintain.
    The companies that we work for are not going to pay us for working on community projects unless it has other non-financial benefits.

    I made a business out of the build service and with a couple of customers depending on it, I have a lot of motivation to maintain and improve the service and I even make some money with it.

    I made a business out of the build service, so I have the motivation and

Luc van Vugt · June 19, 2019 at 5:14 am

Fully agree withyour story, Richard, and we’re a happy user of your service(s). Note that we decided to collaborate for exactly all the reasons that you’re mentioning. It’s great to reinvent the wheel, but not if it’s just a means to get our job done. Keep the good work going.

The true story behind my build service for NAV/BC - Robberse - Dynamics 365 Business Central/NAV User Group - Dynamics User Group · June 18, 2019 at 7:15 pm

[…] Richard Robberse 2019-6-18 8:35 PM 0 comments 0 views Mirror post […]

Give my build service for NAV/BC a try – Robberse IT Services · June 30, 2019 at 7:54 pm

[…] PrevPrevious PostThe true story behind my build service for NAV/BC […]

Leave a Reply

Your email address will not be published. Required fields are marked *