Creating a package or a model is one of the first things we’ll do when starting to code in a new project.
It’s something very basic, but I’m still seeing some issues around this, bad practices that can lead to problems in the future.
Packages or models?
Is a package something different as a model? Well, more or less, it’s something conceptual more than anything else.
A package is a group of one or more models. And models are the substructures of packages. So if you have a package with a single model, that model is also a package. The main point here is that packages can be… packaged and distributed to other environments.
To be more clear: everything that’s inside K:\AosService\PackagesLocalDirectory is a package. For example ApplicationSuite is a package:
And inside this package there are several models:
And after this short explanation, let me get to the important part of this post.
How should we plan around packages and models?
Let me start with this, and let me write it in capital letters, and in bold, and in color red: DO NOT CREATE A PACKAGE PER EACH DEVELOPMENT YOU’RE DOING.
We need to think about packages as a container for our work, and models as a way of organizing some objects inside packages. So create a package for your org, and inside it create as many models you need, for example a model for each Dynamics 365 module.
And of course you can just put all of our customizations inside a single package with only one model. These two should be the way to go.
But we will not, in any case, never, create a package for each development we need to do. And I’ve seen it! More than once! Why shouldn’t we do this? Because that’s a recipe for disaster, and for a future first-class ticket right into hell. Let’s see some reasons why you shouldn’t do this.
You’ll hate the azure-hosted pipelines
It’s not the most important, but it’s the first one that always comes to my mind. Imagine you have 20 packages for 20 different developments.
When you create the solution that will be used in your Azure-hosted pipelines to build your code, you’ll need to create a solution with 20 projects in it! Oh, of course it’s only 20 projects, but what if it’s over 100?
And what about the maintenance of that solution? You’ll be updating it for each new development you do! And then you’ll need to create branches with versions of that solution, to be able to run pipelines for each branch, until you move all your changes to the branch that goes to prod or to a sandbox environment!
Circular references
This is really the main reason we shouldn’t be creating a package per development.
Imagine we create ModelA, that contains a table called TableA. Then we create the ModelB and add a reference to ModelA because we want to use the TableA in a class that will run in a batch. No problem! Done!
Then we create an EDT in ModelB, and someone needs to use it in ModelA. Now we cannot add a reference to ModelB because there’s already a reference to ModelA in ModelB, and that would be a circular reference.
With just two models this is easy, if you have 50 you’ll want to die.
I love extensions!
Sure you do! And if you do the one development, one package thing, you might end up with a million extensions of the same table or form. And when it comes the time you need to modify a control you added… you’ll spend a nice day looking for it through all your lovely extensions!
Build times
This one’s maybe not important, but with so many models, building all your models in VS will take longer.
Your future you, will hate you
Seriously, this might be even more important than the circular references one. If you chop your packages and models, and one day you realize what you did, and want to move everything to a single package, there’s self-hate guaranteed.
