An opinion I encounter relatively often is that a disadvantage of isolated development environments of Dynamics AX is in the fact that if one developer forgets to include an object in version control, the application doesn’t work and doesn’t compile in other development environments. So I’ll probably surprise many people by the statement that I consider that, on the contrary, an advantage.

Let’s take an example – let’s have class A using class B. If only class A is in version control, the application built from this version won’t compile because it refers to missing class B. It will all work in the original development environment, because class B is still there.

So what’s the difference between shared and distributed environments?

From version control perspective – none. The object is simply absent in the version and this version can’t be successfully built.

But there is a difference in Dynamics AX – the shared environment behaves in the same way as the environment of the original developer, i.e. it contains a version not existing in version control, including class B. Therefore the code will compile (you get only a Best Practice error) and everything will work unless you correctly build the application from version control. At the best, it will be on the same day in a night build, in the worse case, it will be some time later, e.g. when you want to create a branch in version control or to reconstruct a collapsed development environment (and you realize that it can’t be done).

In short, errors must be detected as soon as possible and shared environments cover up this type of error. This is not a critical problem and night builds solve it quite effectively, but I surely wouldn’t describe error hiding as an advantage.

I’ve heard one more argument about this topic: “We always copy layers anyway, we never build directly from version control”. That sounds almost like: “Of course we use version control. We just don’t care if we have any objects in it”. 🙂