The Continuous Release Cycle of Microsoft Business Applications

As of February 2019, all Dynamics 365 for Customer Engagement (D365CE) online instances should be upgraded to v9.2 (9.1 for Government Cloud), making them align with the new Microsoft Lifecycle Policy. This new policy is committed to provide consistent and predictable guidelines for the availability of support throughout the life of a product. Here, I will breakdown how to manage your organization’s own lifecycle now that Microsoft is forcing updates to standardize and stabilize their product, D365 Customer Engagement.

New Updates

Two major updates will be released in April and October with minor patches or fixes pushed automatically throughout the year. Administrators can delay the major updates for up to 90 days. This change in shorter delay options makes the biggest impact on organizations. All organizations will stay at least three versions behind, for example, as of May 2019, 9.2, 9.1, 8.2 are the only supported versions. Those that are not current will have notices six months in advance and then will be updated to the latest version.

Small Orgs (<50 users)

Administrators in small organizations with little or no change control will not be impacted. However, organizations of any size are recommended to create a change control process.

Medium Orgs (50-300 users)

By now, a medium size organization should have a change control process and an understanding of what their D365CE internal lifecycle looks like. Organizations of this size may lack an understanding of the Roadmap and may miss which features will be available. By not staying updated on the upcoming releases, they risk spending money developing solutions that may be solved by the next release.

Large Orgs (300+ users)

These organizations will most likely have an exhaustive change control process for their system. The danger here is if your change control takes 6 months to implement, they run the risk of keeping up with the releases and demands of users that are leveraging the latest portions of their tool.

Lifecycle Management Matters

Regardless of your organization size, there needs to be structure to how you gather requirements from users, develop solutions, and deploy updates to D365CE in a cyclical process. Lifecycle management describes how a system’s components will be implemented and updated throughout the lifecycle of that system or software. In the past, Dynamics CRM was unpredictable and difficult to manage when enhancements would be released. To add complexity, organizations have their own release cycles which may be disrupted by upcoming Microsoft (MSFT) releases. Therefore, any conversation of D365CE lifecycle involves two parties, MSFT and Organizations.

Microsoft’s Responsibility

In response to users, Microsoft committed to improving the overall experience. In the announcement by Mo Osborne, Corporate Vice President and Chief Operating Officer of Business Applications Engineering, “Modernizing the way we update Dynamics 365”, says:

As we add product enhancements and performance improvements at a rapid pace, today (July 6, 2018) we are announcing a set of changes in optimizing the way we deliver Dynamics 365 updates that will help you stay current in a consistent, predictable, and seamless manner.

Our new update cadence aims to lower upgrade costs, provide all users access to the latest capabilities, performance improvements and offer a better support experience.

Organization Responsibility

The tool used to deploy updates at an organizational level is the Solution zip file. D365CE solutions are how customizers and developers‘ author, package, and maintain units of software that extend D365CE. Customizers and developers distribute solutions so organizations can use D365CE to install and uninstall the business functionality defined by the solution.

A Microsoft Dynamics 365 solution is a compressed (.zip) file that contains multiple customized components that have been exported from a Microsoft Dynamics 365 instance so that they may be transported and imported into another instance. However, a solution file is a single binary file that does not lend itself to source code control or team development.

Note: There is no way for multiple developers to work on the same custom components in the same solution.

Therefore, team development of Microsoft Dynamics 365 for Sales (D365s) solutions requires those actively working on a common solution to be aware of the work of others.

Clearly the management of these zip files has been difficult for many projects.

Microsoft Recommended Approach

Below is a great diagram that portrays how the upgrade process should work. Organizations should adapt this model to fit existing controls within their own practice.

Detailed Approach

Most change control processes are missing a solution deployment program. Since the management of solutions is very manual, it is often thought to be unnecessary. A solution deployment plan would solve spending several hours troubleshooting a failing import of any type. Below is a possible outline for what could be a deployment plan for your organization.

The Solution Deployment Plan

From a general perspective, the solution deployment plan is as follows:

Assignment

- User story and work item assigned in VSTS

Analysis and Design

- Assess level of effort and appropriate release cadence

- Determine conflicts or dependencies within components being configured as part of these work items

Configuration and Development

- Release Cadence, Sprint, and/or Patches are collected into unmanaged Solutions, each containing Solution Components

- - These solutions are created in D365s

- All configuration efforts are assigned to a solution

- The base for any solution is a v1.0, exported as an unmanaged solution and saved off in an archive location once completed

The efficiency is dependent on the relationship with task management for the project. Everything starts with VSTS or whatever task management tool is being used. The following outlines the process from a project perspective.

Step by Step

Sprint Start

Assignment

- User Story Created in VSTS

- - Version created

- Tasks created and assigned

Analysis and Design

- Functional Group and Components documented in VSTS

- - Solution as part of this task is indicated on task

- - Dependency on other solutions is indicated on task

- Solution(s) created

Configuration and Development

- Document in description of each component and sub-component changes that were made (See Documentation)

- Testing and QA

Sprint End

- Solution(s) Exported

- Solution(s) saved in archive

- Solution(s) import order determined by dependencies.

- Solution(s) imported to next location

- VSTS updated with result of solution import

Use Patches

The ability to patch a solution was released in 2016 and it is the most important part of closing the loop holes when making changes to a system. However, there must be more organization for how solutions are created, and decisions are made to effectively use a patch. The information below outlines one way to create this structure and implement a patch process.

Solution Structure

In keeping up with software lifecycle best practices, the naming of solutions must be intentional and transparent to all involved. To improve production support and avoid ever-changing documentation, the configuration or customization efforts within the project should be consumable by support engineers during their troubleshooting efforts.

When it comes to configuration and customization efforts performed during a project, there will be three types of solutions seen within the system.

Base Solution

Each project will have a common base solution. This ensures that all efforts work from the same starting point.

To accommodate concurrent efforts and overlapping demands from the business, the CRM Dev Organization will contain the base solution. This portion of the solution will include, the generic configuration Entities, Plug-ins, Security Roles and Core JavaScript libraries that are common amongst all lines of business.

Note: During analysis and design within each sprint, the team will determine if a task is needed to update the base solution based on changes being made.

Sprint Solution

The Current Sprint Solution may be composed of the following pieces:

Configurations

- Dashboards

- Entities

- Reports

- Roles

- Option Sets

Processes

- Workflows

- BPF

Code

- Plug-Ins

- Custom Workflow Activities

- Scripts/Script Files

- Web resources

- HTML Pages

- SDK Message Processing Steps

Patch Solution

Adding an entity to a solution, and then exporting it, includes the entity and all related assets part of that export file. These assets include attributes, forms, views, relationships, and visualizations, and any other assets that are packaged with the entity. Exporting all objects means that customizers can unintentionally modify objects on the target deployment or carry over unintended dependencies.

To address this issue, you can create and publish solution patches that contain subcomponents of entities rather than publishing the entire entity and all assets. The original solution, and one or more related patches, can be merged into an updated version of the solution. Then, you can replace the original one in the target Microsoft Dynamics 365 organization.

Dynamics 365 v8.0 and higher, offer the ability to create patches to either managed or unmanaged solutions and include only changes to entities and related entity assets. Patches do not contain any non-customized system components or relationships that it is dependent upon because these components already exist in the deployed-to organization. At some point in the sprint cycle, roll up all the patches into a new solution version to replace the original solution that the patches were created from.

https://msdn.microsoft.com/en-us/library/mt593040.aspx

Solution Patch Example

The following table lists the details of a patching example. Note that in this example, the solution and patches are imported in numerical order and are additive, which is consistent with solution import in general.

The import process is as follows.

The developer or customizer first imports the base solution (SolutionA 1.0) into the organization. The result is entityA with 6 fields in the organization.

Next, the SolutionA patch 1.0.1.0 is imported. The organization now contains entityA with 6 fields (3 have been updated), plus entityB with 10 fields.

Finally, SolutionA patch 1.0.2.0 is imported. The organization now contains entityA with 6 fields (3 updated), entityB with 10 fields, plus entityC with 10 fields.

Think like Software, Deliver consistency

After structure has been added to solutions, version control can become the main focus and align it with the change control process. This helps identify which changes are being resolved. It also assists with both the requirements and changes being released internally with each solution.

Solution Naming Convention

Solutions will contain a structured name that will ensure sorting by name also sorts by most recent at the top. (ex. PILOT_Sprint3_Conf_1_0_1)

Project Acronym

Sprint Number – use “Patch” for patches or hot fix

Functional group

- See Functional Groups for detail

Version – entered when Solution created and appended upon export.

- See Versioning for detail

Add when saving to Archive

- Solution Created Date (yyyymmdd)

- This is not needed in the Solution name, but in the zip file name when the solution is exported and archived.

Functional Groups

At a minimum within each organization there will be some version of these four solutions.

Base (Base)

- Contains core components not part of the default Organization
- Shared by all lines of business
- This will not change frequently and will be monitored during each project to keep updated when User story calls for a global change.

Configurations (Conf)

- Contains functional changes by a customizer within Dynamics.

- - Components include entities, fields, forms, views, security, option sets, etc.
  - Reports and dashboards can be put in here or split off into their own solution, depends on demand and cadence of sprint.

Processes (Proc)

- Contains business process flows, workflows, and actions that are configured through the Dynamics interface.
- If custom workflow is already built efforts are completed in this solution.

Code (Code)

- Contains any custom code efforts by developers. If the work cannot be done through Dynamics UI then it should be published and/or registered through this solution.
- This includes custom workflow steps, plugins, javascript, web resources, custom assemblies, custom reports built-in SSRS etc.

Versioning

To manage Solution versioning, Major Version releases will be tracked differently than Minor Version releases. When using a ‘Source Control Process’ the GIT repository uses each check-in to track the Build Number and increment that number accordingly. However, when working with solutions in Dynamics, versioning will need to be up to the project team. Regardless, versioning should follow good application lifecycle management practices. (Modify to fit internal best practices)

Major Version changes are significant changes to the System and may correspond to breaking changes in Interfaces. Major Version numbers will correspond to a full release to production.

Minor Version changes are externally visible. Minor Version changes will correspond to the beginning of each sprint or release cadence.

Service Version changes are bug fixes, or otherwise not externally visible and no chance of breaking interfaces.

Order Version given dependency of one solution on another within one sprint it is essential to keep the order of solution import correct.

[major].[minor].[service].[order]

Release Cadence (sample)

1.0.0 = Go-Live

1.0.1 = Next sprint post go-live feature fixes and net new

1.0.1.1 = Configuration Solution

1.0.1.2 = Dev changes

1.0.1.3 = Processes

VSTS user stories tied to Solution named “[project]_Sprint#” and version 1.0.1

Functional tasks tied to related Conf_1.0.1.1

Dev tasks tied to related Code_1.0.1.2

Process tasks tied to related Proc_1.0.1.3

Procedural Tips

Working in a solution

Publishing

- DO NOT PUBLISH ALL
- Select entity and click publish in navigation to publish only that entity.

Adding components

- Only add what is needed for task. Do not add all sub-components.
- Do not add required components that are missing from the solution

Creating Processes

- Components are added as needed when creating the process.

- Process is created through the solution, so publisher prefix is appropriately added.

Easy does it

I am not recommending an overnight overhaul of everything you do. I recommend a manual process to all of this before trying to automate anything. I also recommend any organization take a look at the rapid pace of changes and learn to adapt. If the controls are blockers, rework the process. If the users are the blockers, invest in training. Either way, change is coming and that will not be altered. Keep trying new ways to bring consistency to your solution management and you will save time in the long run with less errors, faster deployments and happier end users.

Are you interested in learning more? Below are some references that can guide you through the process even more.