D365 Environments and Solutions
As always, this is not a definitive guide and it’s
not the intention to teach you the intricacies of application development. It is more aimed at giving you an
understanding of what these things are and how we may use them in the D365 (CRM)
space.
What is an Environment in the Dynamics 365 Space?
Here’s a simplified definition:
An
environment is place where we can create store and manage apps, the security,
process flows, the security who can see them etc. Think if it as a big bucket that contains
everything you need to use the apps contained within it.
Why do we need environments in D365?
At the very least we need one. The ‘Production’
environment, which is great for a finished application that is never going to
be updated (how many of those exist?). Typically, we have more. As a developer or a student learning their
way around you might want create environments to hold and sperate or different
designs or development ideas or projects.
You might be building two completely different D365 apps. and want to
keep it all separated so that one change in one app does not affect the other.
In the commercial space we normally have as
a minimum a Development Environment and a Production Environment, the larger
the organisation or scale of the application the more environments you likely
to have. The table below shows how a
large organisation might structure their D365 environments
|
Environment Name |
Description |
|
Dev |
The abbreviation for Development. This can be a single development
environment whereby all the developers work, or it can be a developers own
personal environment where only their changes are created and managed. |
|
System Integration |
Once the developers have created their functions or changes, the
System Integration is used to ensure that changes do not adversely affect any
of the systems or changes that are attached or interfaced to. This is typically where the IT teams will
test the API integrations to other applications or other types of
environments (Think accounting system, HR system, ERP systems etc.) |
|
Test (IT) |
On the developers have completed their integration testing, it will often then be passed to the test team
for further testing. Larger organisations
will typically have this environment for regression testing and may have automated
robot scripts testing the application to ensure that previously working items
are not adversely affected by anything from the System Integration. |
|
User Acceptance Testing (UAT) |
Once the IT testing is completed, it is handed over to the User
Acceptance Team. Here a selected, cross
section of users will test the application from the user’s perspective. They typically contrate on the user
experience and usability of the application (fault testing should have
already been completed by this stage).
This environment is can also be a full copy of production that the is
updated with the new changes, so that the acceptance team can see the changes
in the context of the live environment (production) but without the risk of
testing in the actual production environment.
This environment is sometimes called ‘Pre-Production’ |
|
Production |
The live environment, that all users work in, this contains all the
current working updates and is what is used as part of the ongoing ‘Business
as usual’ processes. |
In summary, an environment is a space (think
box) that contains all the constituent parts needed to run the application. We have multiple environments purely to manage
the risk of making changes to the D365 application.
If the Environment can be considered as a Box,
What’s the ‘Solution’?
Microsoft define the D365 solution as:
‘a packaged
unit of software that extends the platform, allowing customizers and developers
to author, package, and maintain extensions, and deploy them across different environments.’
What does that mean really? In its simplest form, it is a way of combining
changes (Configuration of customisation) together in a single file that can be
used to add those changes to another environment or application. Think ‘transportation device’. A solution can contain, whole apps, Site
Maps, Entities (record types), Option sets (think list of countries as an example)
Web Resources (For example these can be
Java Scripts, Icons, Images, External Web Links), in fact (pretty much) anything
that is contained with the D365 environment can be put into a solution.
Managed or Unmanaged?
If you have already looked under the covers
in the D365 environments, you may have already seen that Solutions are Managed
or Unmanaged. We’ll talk about that next. We’ve already said that a solution is a way of
combining changes or updates into a single transportable unit. If you look at the D365 environment as a whole,
you’ll see there are thousands of attributes across hundreds of entities, scripts,
actions and process (and more).
Now
let’s suppose you want to make some layout changes on a couple of the forms (User
interface) for couple of the entities. You could open up the default solution (That
contains everything for that environment), or you could create a new solution
and just pull in the items you want to change.
For example, you might want to add an Address Validation and Lookup function
to the address on the Account and Contact forms. You might create a Solution and call it “Address
Validation Changes’ and add the two entities to the solution.
NOTE
You can add
the whole entity along with all its consistent parts and meta data or you can just add the bits you actually need to make the updates
which is the preferred approach and you’ll see why when we talk about ‘Managed
Solutions’
Assuming you have added the Account and
Contact entities to your solution along with the relevant address fields your
address validation with work with or update you will end up with a solution
that contains about a dozen or so items.
That makes it much easier to see, deal with and manage. As you make your changes in the solution and then
publish it, those changes are now live in our environment. Having that small
solution, means is fast to save and only loads / updates those few items (much
faster than having to read through and update the entire default solution).
We have already spoken about that fact the solution
is our transport device more moving changes between environments. Now we have our solution, we can export it
from our current environment and ‘Import’ into another one. With a nice small solution
like this example, it should have a minute or two.
When you import a solution into a new environment,
it instantly becomes part of that environment and overwrites what’s already
there (with the same database name) with your changes. Just image if you exported the whole default solution,
with your changes and then imported it into new environment, and unbeknown to you,
someone else had incomplete changes elsewhere in the system, there could be
very unwanted ramifications and how long would it take to find them? Keeping
your solution to just the minimum required items helps avoid this.
What if I want to reverse out my updates I
hear you ask, can I just ‘Undo’ my Import?
What a great question, I’m glad you asked. When you import a solution that is unmanaged
(its unmanaged unless you export it as a ‘Managed’ solution) it is now part of
the default solution, the only way to ‘reverse it’ is to go into the
environment and edit the items and change them to what you want them to be. If you’ve only changed a couple of fields,
not that big a deal, you say, but what if its several hundred attributes across
20 or 30 entities and web resources, that could get really messy and very, very
time consuming. Not to mention it’s not
a good look in your next team meeting while you explain why you have no capacity
for the next few weeks / months…
How do I Manage my solutions?
Don’t panic, the chaps at Microsoft have
given you a way to make the process of ‘managing’ your solutions much less
painful. An unmanaged and a Managed solution
are exactly the same other than one very subtle difference (that has a knock-on
effect). When you export your solution,
there is an option to export it as a ‘Managed Solution’.
What this does is in simple terms is adds a
wrapper around your work. The ‘Managed’
part of it tells application to create another set of meta data (hidden from
you) related to your changes that locks and tracks them in the new environment. Now when your ‘managed solution’ is imported
to another environment, there’s a new feature that allows you remove (delete
it) from the environment.
So why don’t we just make everything a ‘Managed solution’?
The easiest way to answer this question is that
‘Unmanaged Solutions’ are really for developers to group there work together in
manageable chunks whereas ‘Managed Solutions’ are really intended for the distribution
of a ‘complete’ functions or discrete chunks.
For example, a software vendor would sell their D365 updates as
discreate pieces of code wrapped in a managed solution, obfuscating their (IP)
code and locking the custom components within it.
There are some
other aspects of a managed solution that ‘might’ stop you from wanting to use
it
·
You can't
add or remove solution components in a managed solution.
- You can't
export a managed solution.
- Deleting a
managed solution uninstalls all the solution components in it.
There is also the concept of ‘Managed
Properties’. With a managed solution you
can decide whether or not to allow some components within it to be customised
by other solutions.
This brings us to the concept of ‘Layering’
which is the ability to add multiple managed solutions with over lapping components. By this I mean, it is possible to create a
managed solution then create a second managed solution that add to or changes
to the components of the first one.
As I mention in most of my posts, I’m not
trying to teach the intricacies of programming or managing D365 systems but
rather give you a taster of what’s available to you. If you want to know more about Managed and unmanaged
solutions and which to use for what and when, Microsoft learning is a great
place to start and the following link delves into this in greater detail. : https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/introduction-solutions?view=op-9-1
No comments:
Post a Comment