We are all beta testers for Microsoft Dynamics 365

Working with Microsoft Dynamics 365 is often painful but always exciting #HoskCodeWisdom

Microsoft Dynamics 365 version 9 has seen a lot of bugs in Microsoft Dynamics 365, particularly an increase in bugs in the core functionality, not just new functionality. I have heard a few Dynamics professional say

“We are beta testers for Microsoft Dynamics 365”

What’s happening and why is it so bad

This is my opinion with no evidence to back this up apart from talking to other Microsoft experts and my experiences. Before Dynamics 365 was rebranded e.g. Dynamics CRM 2016 and before, there would be a few bugs with new features (which we all know to never use a first version e.g. Microsoft Dynamics Marketing)

In version 9 I have seen lots of bugs, obvious bugs, solution bugs. I wondered if it was just my bad luck but speaking with other Dynamics professionals they have seen an increase in bugs.

Some bugs I have had the pleasure of in 2018

Auditing broken
lookups have no names
Importing solutions times out
holding solutions broken and get stuck (breaking other imports)
adding visuals breaks solution import
Microsoft minor updates creating dependencies
minor update stops solution being imported with duplicate guid
Problems with performance and scale groups
memory leaks in web servers
Microsoft adding dependencies in minor patches – When a Patch to Microsoft Dynamics 365 can break your instance
Microsoft adding functionality into Case management and breaking solution imports
Microsoft updating instances slowly, stopping up solutions being imported between Dynamics 365 environments
Dynamics instances getting stuck, disappearing or being unusuable

What might have caused this?

The direction of Dynamics is to move to business applications, take the processing out of Dynamics and put it into Azure via

PowerApps
Flow
Logic Apps
Azure functions
Azure WebJobs

Dynamics 365 is one part of the solution and integrated with many services. Processing should be moved out of Dynamics to reduce load on Dynamics and move data out to store it where it’s cheap (e.g. not in Dynamics 365 where it’s expensive)

To do this, Microsoft needed CDS (common Data Service) to be easy and affective to use. I have always thought of Microsoft Dynamics as a GUI front end to a database and a framework to trigger customisations.

Now CDS is a blank Microsoft Dynamics 365

To decouple the default functionality of Sales, Marketing and case management, Microsoft needed to recreate these to use standard and supported solutions. Trickier than you would think because the functionality was created using unsupported customisations because supported customisations couldn’t do.

This explains why the CRM 2011 screens have been sitting in Dynamics 365 for so long, Microsoft couldn’t take them out without rewriting all that unsupported functionality (naughty Microsoft).

Microsoft have recreated the functionality with supported customisations (so they could decouple it). They needed to create the custom control framework and other cool stuff to do this but they have finally got there. This will be great once they give us a tool to edit the custom controls.

I like the ability to import Sales, Marketing, Case management solution only if you need them, if you are using Dynamics 365 CE as an XRM framework you can now remove those unwanted dependencies.

This rewrite has caused many bugs but I see this is short-term pain for long-term gain.

Microsoft has moved to Azure SQL and moving from SQL server to Azure SQL caused a bunch of problems no one expected.

Process

We got a bug which was reported as fixed, we tested it and found it wasn’t. After some investigation the support analyst told me the developer had forgot to check the code in. How did this get reported as fixed?

Azure

Microsoft has fully moved Dynamics 365 to Azure, they are the largest service on Azure, they are eating their own dog food. This added infrastructure problems to compliment the bugs it added to the system.

Online

The move to Dynamics 365 online has picked up speed, now all customers want to use Dynamics 365. This means we are getting different projects, doing different things and find different bugs. The number of projects, type of projects and crazy things developers are doing with Dynamics 365 online has exploded.

Devops and automation

Best practices like DevOps and automation are being brought to Dynamics projects. This is finding problems not identified before or seen before.

Will it get better?

I read this article about how they build windows 10 and I’m guessing Dynamics does it a similar way

The one version is coming – The new Microsoft Dynamics 365 release schedule is coming and with this Microsoft are moving to a continuous release cycle and a greater testing.

New Dynamics 365 fixes will be tested by Canary (early release) organisations and smaller regions (sorry smaller regions, the need of the Europe and America is greater than the need of everyone else). Everyone will be on the one version which means more testing will be done on the one version.

Microsoft have just persuaded all Dynamics production instances to test it for them or risk breaking their production instance on upgrade.

Microsoft has put the pressure of testing earlier onto its customers, accepting the latest major release is not optional and cannot be scheduled. Companies will have no option but to test the new release in a sandbox instance. The one version (to rule them all) should lead to greater automated and manual testing from Microsoft and all its Dynamics 365 customers, this will find bugs faster but will leave the question on how quickly can Microsoft fix and release these fixes.

Features can be turned off, you can avoid using them until they work

Microsoft are improving the monitoring and proactive fixing and self healing of Azure resources. Proactively finding problems with customer Dynamics organisations and send them advice. Microsoft will release a tool to check solutions, which does static checks on code to find poor performing code.

The move towards the one version of Dynamics could initially be painful but will improve Dynamics 365 in the long term. Microsoft seem to making the right noises about moving toward continuous deployments, mentioning automated testing and other improvements should help.

The windows development post ends with a good quot

Adopting the principle that the Windows code should always be shipping quality—not “after a few months of fixing” but “right now, at any moment”—would be an enormous change. But it’s a necessary one. Microsoft needs to be in a position where each new update is production quality from day one; a world where updating to the latest and greatest release is a no-brainer, a choice that can be confidently taken. Feature updates should be non-events, barely noticed by users. Cutting back to one release a year, or one release every three years, doesn’t do that, and it never did. It’s the process itself that needs to change: not the timescale.

Embrace it

What I have always enjoyed working with Dynamics is its attitude to change. Microsoft add new services, new tools and new everything. It’s often painful, but it’s always exciting.

Future projects will look nothing like the projects you have been creating for the last 5-10 years and we are all going to need to learn the limitations and best practices. You will laugh, cry and scream with frustration but hopefully not every day.