Here’s a consolidated overview of
how updates, upgrades, and patches work in relation to platform solutions and
Dev solutions in Microsoft Dynamics CRM, along with strategies to handle your
specific scenario:
General Dynamics
of Platform Solutions and Dev Solutions
Platform Solution: Provides the foundational or core
managed components, typically deployed as managed solutions by a platform team.
These components are locked and cannot be removed or replaced.
Dev Solution:
Contains customizations and updates created by development teams. Dev solutions
often need to layer changes on top of the platform solution when deployed to
higher environments.
Challenges:
Dev solutions cannot
overwrite or upgrade the platform layer due to managed layer restrictions.
Any updates from the
Dev team must respect the integrity of the platform managed components.
Updates
vs. Upgrades
Updates:
Purpose: Incremental
changes or modifications to components, layered on top of the existing
solution.
Use Case:
Ideal when the platform solution exists, as updates do not attempt to remove or
replace the platform base layer. Safely applies new changes without disrupting
foundational components.
Examples: Adding
fields to a form, modifying views, or updating metadata tied to managed
components.
Upgrades:
Purpose: Full
replacement of an existing solution, consolidating patches or unmanaged
components into a new managed solution version.
Limitations:
Cannot upgrade solutions if a base layer (e.g., platform solution) is
immutable, as CRM prevents removing platform components.
Examples: Used in
scenarios where no platform managed layers exist, or the entire solution
structure requires a reset.
Using
Patches
Definition: Patches
provide a way to deploy small, specific updates without reimporting the entire
solution.
Workflow:
1. Create a patch from the parent solution for
targeted modifications.
2. Import the patch to the target environment,
layering updates without altering other components.
3. Consolidate patches into a new parent solution if
needed (using "Clone Solution").
Benefits: Useful for applying fixes or updates to
environments with platform managed layers, ensuring seamless deployments.
4. Best Practices and
Recommendations
To Address Your
Current Scenario:
For 8192 views and
other platform layer components, use updates or patches from the Dev solution
to layer customizations without attempting to remove the platform's managed
base layer.
If multiple patches
exist, consolidate them using the Clone Solution feature to simplify future
updates, while still preserving the platform solution layer.
Test updates in a
staging environment to validate that the layering works as expected with the
platform solution.
Proactive Strategies Moving Forward:
1. Collaboration: Work closely with the platform team to
align on solution design principles.
2. Standardization: Keep platform and custom components in
separate solutions for clarity and better manageability.
3. Incremental Updates: Use updates and patches as your
primary deployment mechanism when platform managed components exist.
This structure minimizes risks,
respects platform layer restrictions, and ensures smooth deployments across
environments
Single
Publisher vs Multiple Publisher
Using multiple publishers can help facilitate governance and
maintain consistency in your base platform solution. Here’s how this approach
supports your goals:
Benefits of
Multiple Publishers
1. Enhanced Customization Governance:
By assigning specific publishers to dev teams
or environments, you create clear boundaries. This allows better control over
what changes are made, by whom, and where they originate.
2. Consistency in the Base Platform Solution:
The base platform, under its own publisher,
remains consistent across all environments. Customizations from different
publishers do not directly alter the base solution, ensuring its integrity.
3. Controlled Production Deployment:
You can control which publishers'
customizations are promoted to production by reviewing their managed solutions
independently. This prevents accidental or unauthorized changes.
4. Audit and Accountability:
With separate publishers, it’s easier to trace
who made specific customizations and when. This ensures accountability and
simplifies auditing.
Cons:
1. Complex Upgrade Coordination:
Requires careful management to resolve
dependencies and validate compatibility during base platform updates.
2. Higher Testing Overheads:
Updates to the base platform must be tested
with all dev solutions to avoid disruptions.
3. Risk of Dependency Conflicts:
Multiple
publishers may create dependencies that complicate cross environment upgrades.
Single Publisher
Pros:
1. Simplified Upgrade Process:
Consistent version control and easier
dependency management during upgrades.
2. Unified Governance:
Centralized control over solutions ensures
alignment with the base platform.
3. Streamlined Compatibility:
Reduces the risk of conflicts as all
customizations share the same publisher identity.
Cons:
1. Limited Customization Oversight:
Hard to track changes across dev teams due to
shared publisher identity.
2. Higher Risk of Conflicts:
Customizations from different teams may
inadvertently overlap or override each other.
3. Reduced Accountability:
It becomes challenging to pinpoint who made
specific changes.
Key Points to Consider
Dependency
Management:
Ensure that customizations from different
publishers do not create conflicting dependencies with the base platform.
Upgrade
Coordination:
Define rules for how base platform upgrades
will affect dev solutions under different publishers to avoid disruptions.
Communication Between
Teams:
Facilitate coordination among teams to ensure
their solutions align with organizational standards and the base platform’s
functionality.
To manage dependencies and create rules for upgrades in a
setup with multiple publishers, here’s a detailed approach:
Dependency
Management Guidelines
Establish Clear
Boundaries for Customizations:
Isolation of
Components: Dev teams should avoid direct dependencies on the base platform's
components unless explicitly permitted. For instance, shared components like
fields or workflows should be part of the base platform solution.
Use Solution Layers
Properly: Ensure customizations are layered correctly, with the base platform
solution always at the lowest layer. Dev solutions should build on top of it
without overwriting base components.
Identify and
Document Dependencies:
Dependency Checker:
Use the Solution Checker tool to analyze solutions and identify any existing
dependencies between custom and base solutions.
Documentation:
Maintain a repository (e.g., in Azure DevOps or SharePoint) that lists
components in the base platform and their acceptable usages.
Scoped Component
Ownership:
Assign specific types
of customizations (e.g., entities, forms, or plugins) to each publisher to
prevent overlap or duplication of components.
2. Upgrade Rules
and Processes
Upgrade
Coordination for the Base Platform:
Dependency Free Base
Upgrades: Ensure the base platform solution does not depend on any custom
solutions. This allows it to be upgraded independently.
Pre Upgrade Testing:
Create a sandbox environment to test upgrades of the base platform with dev
solutions from all publishers to identify issues before deployment.
Guidelines for Custom
Solution Updates:
After a base platform
upgrade, dev teams must:
1. Validate their custom solutions for compatibility
with the updated base platform.
2. Update their solutions if required to resolve any
conflicts caused by the upgrade.
Upgrade Ownership:
Assign one team
(e.g., the platform team) as the owner of the upgrade process. This team is
responsible for initiating, coordinating, and validating all upgrades.
3. Communication
and Collaboration
Notify All Teams
Before Base Upgrades: Inform dev teams about upcoming base solution updates,
including timelines, potential impacts, and required actions.
Feedback Loops:
Establish a process for dev teams to report issues or conflicts during testing
or after upgrades.
4. Continuous
Monitoring and Audits
Regularly audit
solutions to ensure adherence to dependency and upgrade policies.
Use tools like Power
Platform Admin Center or custom reports to monitor changes and track solution
performance post upgrade.
Platform Solution Team (Base Solution):
Has the sole
authority to perform upgrades to the base platform solution. This ensures
consistency and avoids dependency conflicts across environments.
Upgrades to
the base solution are applied across all environments, maintaining the
integrity of the foundational layer.
Dev Teams (Custom Solutions):
Can only
perform updates to their respective custom solutions. These updates add
features or modify functionalities on top of the base platform solution but
don’t alter the base layer itself.
Their updates
must be tested for compatibility with the current version of the base solution
before being deployed.
This separation of responsibilities ensures that:
The base platform
remains consistent and scalable across environments.
Dev teams maintain
autonomy for their customizations while adhering to governance standards.
Production
deployments are tightly controlled, reducing the risk of conflicts or errors.
