Quality Checks Before Deployment

Most deployment problems are already visible in the export before the import. You just have to look, and before you click Import. This is the short checklist for that.

Dependencies and environment variables

• Dependencies: Compare the missing dependencies from the "solution.xml", including version, against the target environment. A solution that exists but is too old counts as missing.
• Environment variables: Does the export contain a value next to the definition? Then decide deliberately whether it should overwrite the target environment.
• Deletions: During an upgrade, whatever is missing in the new version disappears. Look at the deletion list beforehand.

Run the Solution Checker

Not right before the deployment but as a permanent state: the Solution Checker should run regularly on the development state, so that no surprises are left in it before delivery. Critical findings in the categories security or upgradeability are a reason to postpone the delivery. The rest is a matter of judgment, but should be documented.

Unmanaged layers in the target environment

Are there unmanaged customizations on components that the managed delivery is supposed to overwrite? Then the delivery does not take effect at those places. The solution layers view of the affected components shows it.

Connections for the flows

If the solution contains Power Automate flows, they depend on connection references. If the target environment has no connection for one of them yet, the flow arrives but stays turned off until someone assigns the connection. Before the import, clarify who creates the missing connections and under which account they should run. A service account is almost always better than the personal account of whoever happens to import.

Version number and change note

It sounds trivial but decides the response time when something goes wrong: has the version number been counted up, and is there one line on what this version contains? If something turns up three weeks later, that line is the difference between a targeted rollback and guessing.

Languages of the target environment

A small point with an annoying effect: some solutions contain translations for languages that are not enabled in the target environment. These labels do not come along with the import. Comparing the enabled languages is a one-liner in the preparation and saves maintaining them by hand.

What this list does not do

It does not replace a test import into a staging environment or a functional test. It catches the errors whose cause is already in the package. In my experience that is most of them, but not all. An import can also fail on states that only the target environment knows.

If you apply the list to an existing delivery practice for the first time, you will almost always find something. After that it quickly becomes routine, and routine is the actual goal with deployments.