“Hybrid development” is not a general accepted term in our world of “Microsoft Dynamics 365 Business Central”. The term Microsoft uses for this concept is “Side-By-Side” development.
But in a way, I find that “Hybrid” does more “right” to the term:: combining old technology with new technology (like C/SIDE and VSCode, or C/AL and AL, or internal combustion engines and electro motors.. ). Why anyone would to that, I’ll go into in a minute .. but now you at least know what I try to blog about ;-). But first, I’d like to start with a big fat …
I very much realize that a lot of you will not agree with my opinions below. And that’s ok. I just want to share my opinion on “hybrid” / “side-by-side”. May be there are a few points you didn’t think of – or there are a few points that I didn’t think of that you are happy to share in the comment-section below ;-). All for the best – we are helping each other out by sharing experiences, opinions, touchpoints, things to take into account, realizations, whatever… .
In any case, the below opinions are my own, and my own only. And obviously – no judgement from my side for people that think different :-). You are already heroes to me just by taking the time to read my blog ;-).
Why would anyone start to combine development in C/SIDE (C/AL) together with Extensions in VSCode (AL)?
Well, very simple: non-existing events is probably the most important reason: you lack an event in the default app. So you create it yourself, and subscribe to it from AL.
Do know that Microsoft is very much working on new events in NAV. And we are already in a very good spot: the current version of AL has about 3337 published integration/business events! A massive improvement compared to NAV2018, which had about 1300 published events. If you need a new event, please apply for it here: https://github.com/microsoft/ALAppExtensions
Another reason to “go hybrid” would be to actually change code, like commenting a part of the default app. For example: commenting the deletion of sales orders while posting. With extensions, you obviously can’t do that anymore, since you can’t change code.
I can go on – like implement breaking changes. Like changing the primary key of the Invoice Posting Buffer. You can’t change primary keys anymore! But you obviously still can in C/SIDE, since that is “open source”.
But I will stop here with trying to find other reasons to “turn to the Dark Side“. Yes indeed – going further with this post, you’ll see that I actually think that hybrid development is very much to be avoided at all times.
How do I do Hybrid / Side-by-Side development?
Well, I won’t tell you :-). Mostly because – again – I don’t like it one single bit, but also, Microsoft has described it for you on Microsoft Docs. So why would I repeat that? ;-).
It comes down to:
- Whenever you develop in C/SIDE, your symbols change
- So you need to update symbols by generating symbols every time you change something in C/SIDE
- Then you need to make the new symbols available to AL by downloading them from the serverinstance you created them
That seems easy enough. So why is this bad?
Well, may be before I continue, I need to explain my situation:
- I am a partner,
- which needs to support multiple customers,
- with a repeatable product
- that has multiple releases,
- with a team of 15 developers.
Meaning: nothing special. I strongly believe most of us are developers that have multiple customers, servicing them with a product, that is being maintained as well. These customers need to be able to upgrade easily, and you probably are working in a team.
And if you don’t fit this profile, you are probably a freelance, working for a select number of customers, or an internal IT, with 1 database to maintain.
The difference between these two profiles is massive. And I’m taking conclusions in terms of my role and my role only (may be I should have put this in the “disclaimer” section as well ;-)).
Let’s drill down in a few parts of our lives, like:
On Going Development
The process to do both types of development on one environment is quite cumbersome, as I described above. But let’s just imagine you (as a person) can manage it. Thing is – you have a team – does your team manage it? Not only you have to have access to VSCode and the serverinstance (which many of us manage for our team of developers – sure there is Docker, but I can tell you, a lot of us development managers realize that we need to manage building environments for developers, because simply put: we want them to focus on the development job, rather than fiddling around with Docker – meaning, centralized development environments, branched per developer or not, doesn’t matter), but now you also need access to C/SIDE, NST, PowerShell and what not .. . System administrator don’t really like that, because simply put – developers usually don’t have enough knowledge of these technologies … .
It is not enough you know how it works – you have to make sure the team knows how to do this kind of “working around stuff” like hybrid development … and I don’t know about you, but I don’t want to focus teaching my developers about workarounds. I’d rather teach them real stuff.
One of the beautiful things about Extensions is the fact it is “rather” independent of localizations (if you build on W1), or very upgrade-safe.
But when doing Hybrid Development, you basically throw this advantage completely overboard: You are dependent on YOUR version of the database, and not on any other default database for NAV.
And on top of that – just think how your upgrade-process will look like. In stead of simply develop against the next version (CU) of Business Central, now you need to upgrade your C/SIDE in a classic way as well – for each CU! Let along localizations…
Doable for one environment? May be so .. but sure not straight forward.
But imagine in a few years, when you have a multitude of customers and environments … still doable? Not a chance!
Supporting customizations has always been a challenge in a partner-environment. This is also one of the reasons why many of us (partners) have turned “customizations” into “applying repeatable solutions”. Usually in the form of a vertical. Sometimes in the form of horizontals. Many times in the form of “functional libraries”.
On top of that, many of us have to support a multitude on ISV solutions .. resulting into a wide range of combinations between all these solutions.
On then on top of all that – because NAV’s “simplicity” – we do customer-specific customizations, usually based on all these solutions.
Combining all this, every single customer usually is a unique case – which turns support into a challenge. A challenge many of us accepted, and are doing quite well.
Why? Because we know what we do, and we only have 1 environment (usually) to do it in.. : C/SIDE.
Just imagine: all the above, but hybrid .. do I need to say more?
When you have a problem .. where to solve it? C/SIDE? AL? How to find out? And when you finally found out – how do you deploy? …
Yet another extra challenge you have.
Deploying an app is quite easy. There are some ground rules, some scripts you can write, … these days, you can simply “auto deploy” or make deployment part of a release cycle (with devops / continuous deployment).
What if you went the hybrid-road? How do you deploy?
Remember you have a very “hard” dependency between your very own version of classic old NAV and Extensions. So you’d better deploy classic C/AL objects, together with your extension, at the same time, in one go. I’m not saying you can’t do that… PowerShell can do anything. But what if something is wrong? It’s kind of a multi-transaction-deployment – not like there is an easy rollback scenario… .
And – again map this to a few years later, where you need to do this for a multitude of customers.. ?
We have a product. And that product needs to be localized. You know what that means: one codebase all of a sudden is a multitude of codebases which need to be tested and maintained.
For an AL-only-app, it’s easy – DevOps to the rescue! Set up build processes and you’re relatively safe.
In a hybrid environment, it’s not “just” a matter of applying your app to a different localization. It’s a matter of merging your changes from C/SIDE, deploying it, symbols, … Blebleh (I intentionally don’t want to give all steps here ;-)) .. and THEN start building and testing your app.
You guessed it right: Hybrid is evil! I strongly believe that we should do everything we can to avoid a Hybrid solution.
Hybrid cars make as much sense as hybrid development: none 😉 – go electric ;-).
We have a very simple guideline in the company. We will never ever, in any circumstance, after ANY request from the customer, … go down the hybrid route (but I guess you got that by now). We will try to find another solution. And if we can’t find any .. we will not do it (and until now, we haven’t come across any situation we couldn’t solve … and yes .. we have been going into AL for quite a number of (big and small) projects.. ).
We even put the bar higher than that: we create all OnPrem solutions in AL as if they were either “AppSource” (for verticals) or “PerTenantCustomization” (for customer customizations) as Extensions (not “internal”). Which excludes other evils, like “DotNet” – but that’s for a whole other blogpost ;-).
Have a nice weekend! And this is probably my last post of the year, so –