Robert Pröll

.NET Software Architect

Key areas of interest: ALM, .NET C#, PowerShell, Azure, Dynamics 365 Tooling

Robert started in the area of ASP.NET projects and has now more than 10 years of experience in the international Dynamics Enterprise business.

He works mainly as an principal software architect at Kupp and as an external consultant for Microsoft.

Robert Pröll

.NET Software Architect

Basic vs Advanced Deployment Tasks

Power Platform Build Tools vs. Third-party tooling (technical review & comparison)

Posted: 08.2020 | Category: ALM

Robert Pröll | .NET Software Architect

Intro

Finally, we got an official answer for the D365 Deployment Challenges - Microsoft Power Platform Build Tools for Azure DevOps.

The topic is nothing new but I really appreciate the commitment of the product group to improve the compatibility with well known CI/CD concepts.

Various reasons why solid release management can make a huge difference can be found here: https://kuppsoft.com/resources/blogs/

In this article I would like to give an overview of the main features compared to an enterprise-oriented 3rd party solution.

PowerPlatform Build Tools (PPBT):
https://docs.microsoft.com/en-us/power-platform/alm/devops-build-tools

KDTooling Deplyoment Manager (KDDM):
https://kuppsoft.com/our-products/deployment-manager  

Goals: Enterprise Ready 1x Click Deployments without custom development.

Content: 

Highlights / Features (PPBT)

Source: Azure Marketplace (Microsoft Power Platform Build Tools for Azure DevOps)

Source: Azure Marketplace (Microsoft Power Platform Build Tools for Azure DevOps)

Basic Solution Transfers
The common solution import/export tasks are fulfilled with some help of the native DevOps capabilities.

Free
Only a valid Azure DevOps Subscription is required, there are no additional costs.
Note that build/pipelines times may increase due to export/import waiting times

Fast Setup Time
The recommended option via Service Principles requires some additional steps, the rest is straight forward.

Support for Azure DevOps
Can be installed for On-Premise & Online Environments.

Support for D365 Application User (OAuth)
There are many advantages to use Service Principal (SP) instead of username/password credentials. Not only this can avoid the license requirement, but also a noticeable security improvement as most deployment user must have the system administrator role

Enterprise Challenges of Modern CI/CD Infrastructures

As the D365 ecosystem grows (Portals, PowerAutomate, etc.), implementing clean CI/CD concepts gets more challenging, even for the basics like solution transfers.

For enterprise projects, there is always a wide range of project-specific issues which can be handled by custom scripts etc., however implementing a solid process for the following most common major topics can make a huge difference.

The following statements are scoped to online-only environments. (For on-premise systems topics are slightly different: Generic SQL Error, Win Event Log etc.).

Note: Although automated process can massively reduce the risk of human-errors which result in saving time and efforts, none of the available approaches can replace an experienced specialist nor a well-designed system architecture.  

Solid Solution Upgrades / Transfers

Solution transfers are usually straightforward. A few common root causes of failed imports (missing components etc.) can be easily fixed according to the error message. Those common errors are not production critical as they occur in most cases on the first deployment stage.

Much harder to handle are “not reproduceable” import issues such as failed solution upgrades due to timeouts etc.
For experience professionals, doing the error analysis is not a big deal as it only takes some time to figure out the root cause. 

Common Requirements:

  • Versioning
  • Import 3rd Party Solutions
  • Data Model Changes / Upgrades
  • Sync View States 
  • Transfer Templates

Common Issues:

  • Unmanaged customizations on production systems
  • Staging/Import Timeouts
  • Unclear Error Messages
  • Entity Type Code (ETC) conflicts in document templates

PPBT

KDDM

 

PPBT

KDDM

Strengths
  • Free
  • Fast Setup
  • Cover all basic requirements
  • Support for Holding Solutions
  • Versioning of solutions
  • UI: Autocompletion for Solution Names
  • Error Analysis (Parse XML Logs)
  • View States Sync
  • Code Components Updates
  • Autodetection & Applying of Upgrades
  • Advanced Versioning (Code Style version injections)  
  • Timeout Retry
  • Auto generated Release Notes (D365 Components, DevOps Work Items)

Weaknesses
  • Full CI/CD needs additional custom scripts
  • Only Solutions without additional components
  • Limited to AzureOps Pipelines
  • License Costs
  • Setup requires local client

Configuration Data Transfer

Sometimes it's hard to draw the line between configuration and production data, but the concepts are similar for all of them. Mostly, we try to align the id's through all system if possible.

Common Samples:

  • Business Units (Hierarchical, single root)
  • Product Catalog (Hierarchical, multiple Roots)
  • Portals (complex data model)
  • Custom Config (Key/Value)

Common Issues:

  • Entity Behavior (Cannot create published product)
  • Predefined Id's (Root Bu, Currencies)
  • Unwanted Plugin Triggers (Portals)
  • Environment specific values (URLs to different external Systems)

 

There are many different approaches to solve such requirements with custom script, external applications etc.
As this is not part of the Power Platform Build Tools only the 3rd Party approach is described:

 

PPBT

KDDM

 

 

Strengths

(out of scope)

3-level config process
1. Entity (filter, update or create)

2. Attribute (Static, Ignore, EnvironmentSpecific, Hierarchical, HierarchicalMultipleRoot,  AutoResolve)

3. Entity Specific behavior (documentTemplates: Adjust ETC for .docx etc, adx_*, …)

  • Detect undefined environment specific values
  • OOB Support for Portals
  • Templates for various use cases
  • Special import behavior for certain entities
  • Delta Checks (Update only changed data)

 

Weaknesses
  • Needs additional tools

 

 

More Information: https://docs.kuppsoft.com/KD-Tooling-Deployment/Reference/Steps/ExportDataStep

Compliance & Enterprise

Fulfilling technical requirements in highly restricted environments (Banks, Insurances Companies, Public Services etc.) can be very tough. Especially, when it comes to cloud services, many enterprises are in the middle of the process to integrate cloud services and as a matter of fact those processes are quite slow.  

Just to mention a few common topics:

Common Requirements:

  • Identify responsible persons for specific tasks (e.g. Approve Mailboxes in D365)
  • Compliance Policies: Software Distribution Systems, No Production Access for external Staff etc.
  • Data Fixes for very large Datasets (> 100k records)
  • Restrictions: No manual interactions on production systems
  • Internal Communication/Announcements (Release Notes, Downtimes, Prevent User Access)

Common Issues:

  • Timeouts, Timeouts, Timeouts (It’s worth it to mention it 3 times)
  • Microsoft Support Cases due to unexpected/unwanted product behavior
  • High Efforts for custom PowerShell / C# scripts
  • Missing Transparency in custom scripts

 

PPBT

KDDM

Strengths
  • Azure DevOps Service Connections

 
  • D365 Application User Support
  • Enterprise Proxy Configurations (e.g. Local Build Agents)
  • Encrypted Credentials (Azure Dev Ops Secrets)
  • On-Demand Credentials Prompt
  • Generated Release Notes
  • Hotfix Packages (Without Server)
  • Dedicated On-Site or Remote Support if required
  • Out of Business Hours Support
  • (Server Logs Analysis for OnPrem-Systems)

 

Weaknesses
  • Limited to Azure DevOps Pipelines
  • 3rd Party Solution
  • Supplier Compliance Checks required

Conclusion

Power Platform Build Tools is a great “lightweight” deployment solution for D365 projects as it now can cover all the basic deployment tasks more thoroughly. Starting from scratch with CI/CD is certainly much easier as “quick-and-dirty” legacy custom written scripts can be replaced with clean & well-organized Build Tasks.

Depending on internal resources & expertise (especially DevOps & release management skills), companies can create their own scripts for certain automated tasks, which are not covered by one of the available open-source tools on the market.

For enterprises with even more advanced requirements (strict compliances, complex configurations etc. ), third-party tools are still a considerable option.

My personal experience: for many international or large-scale enterprise projects, people usually either have to:

  • Write up a lengthy deployment guide that consists “tons of steps” for different tools or;
  • Manually modify their existing custom scripts for each project

This is nothing but time-consuming, annoying and thankless tasks, not to mention custom scripts do not provide much transparency & logging.

The Bottom line: For enterprises or consulting firms (who are dealing with large-scale projects), a company-wide unified deployment solution from a third party is strongly recommended to simplify processes & accelerate every project kick-off. 

 

Features Comparison

Business

Priority

PPBT

KDDM

Automatic Backup

High

X

X

Release Notes for D365 & DevOps

High

 

X

Support for Azure Pipelines

High

X

X

One Click Deployment

Medium

X

X

Run Locally

Medium

 

X

Self executing package

Medium

 

X

Fully automated Deployments

Medium

 

X

Immediate Data Fix Package

Medium

 

X

Scheduled Deployments

Medium

X

X

Single Tool

Medium

 

X

Solutions

 

 

 

Solution Versioning

High

X

X

Solution Components Versioning

High

 

X

Import (Deep Error Analysis)

High

 

X

Import (Retry Configurations)

High

 

X

Update of Solution Components

High

 

X

Pack  Solution

Medium

X

 

Solution Verify Checks

Medium

X

 

Uninstall Solutions

Medium

X

X

3rd Party Solutions

Medium

X

X

Detect & Apply Staging

Medium

 

X

Unpack Solution

Medium

X

 

Data Transfer & Maintaince

 

 

 

Hierarchical data

High

 

X

Missing Values Detection

High

 

X

Env. Specific Data

High

 

X

Dynamic Data

High

 

X

 Static Data

High

 

X

Data Maintenance (Update, Deletion)

High

 

X

Custom Import Behavior (e.g. Product Catalog)

High

 

X

Trigger Workflows

High

 

X

Execute SQL Query

Medium

 

X

Delta Checks

Medium

 

X

Templates (e.g. MS Portals)

Medium

 

X

Remove unmanged Components

Medium

 

X

Configuration

 

 

 

Configure Outlook Filters

Medium

 

X

Activate Mailboxes

Medium

 

X

Disable/Enable Plugin Steps

Medium

 

X

Technical

 

 

 

No direct PROD modifications

(code updates, settings…)

High

 

X

Preconfigured Deployment Packages

High

 

X

Source Control Integration

Medium

 

X

Security

 

 

 

Block Users

High

 

X

Username & Password

High

X

X

OAuth

High

X

X

Infrastructure Mangement

 

 

 

Canvas App Deployments

High

X

 

Backup Environment

High

X

X

Create Environment

Medium

X

 

Delete Environment

Medium

X

 

Copy Environment

Medium

X

 

Support & Compliance

 

 

 

Secured Credentials

High

X

X

Commercial Support

High

 

X

Guaranteed Support for future versions

High

X

X

Community Support

Medium

X

 

Tags:

DEPLOYMENTS CI/CD DEVOPS ALM POWERAPPS BUILDTOOLS DYNAMICS 365
All Blogs