PART ONE: APPLICATION HOTFIXES IN THE PERFECT WORLD, AND OTHER LIES
In the future, Microsoft is going to “seal” off all customizations, and soon after they’ll be automatically rolling out updates without us having to worry about it. But since that hypothetical rosy future could be years off for slow upgraders (and because I have suspicions about how rosy it will be), some of us are going to have to keep applying application hotfixes. And applying hotfixes sucks.
It’s not quite as bad as it used to be, but it’s still bad.
For sake of these blog posts, I’m going to assume you have a general idea what an application hotfix is for Dynamics 365 for Finance and Operations (what they’re naming the product this week) and that you know how it is different from a binary hotfix. In general:
- Application hotfix: This is changes to X++ code in the Microsoft-controlled models (Application Foundation, Application Suite, etc.). When you look at or extend classes, tables, etc., in these models, this is the code that an application hotfix can change. When we get “application updates” (7.1/”1611″, 7.2/”July 2017″, 7.3/”December 2017″, 8.0/???), it includes all of these and more.
- Binary hotfix: This is a change to binary code we can’t see, customize, or extend. They are always cumulative. When we get “platform updates,” it includes these and more. We won’t be talking about these right now.
I’ll also assume you know how you’re supposed to apply an application hotfix, and maybe you’ve even done so. (Note: as of this writing, the linked wiki documentation still uses the command line tool to prepare and apply the hotfix. There is now a tool in the Visual Studio GUI that makes it a little easier, under Dynamics 365 > Addins > Apply hotfix) The general steps are:
- Download the hotfix to a development VM (“onebox”) from Lifecycle Services, either through “tiles” or “issue search.”
- Prepare the hotfix in the development VM, either through SCDPBundleInstall or the GUI.
- Check in the “prepare” files. This is your insurance policy if things go bad.
- Apply the hotfix in the development VM, either through SCDPBundleInstall or the GUI.
- Resolve conflicts; and build/compile locally. If you have customized/extended the objects changed in the hotfix (or the hotfix has dependencies on other hotfixes), you can’t take this step for granted.
- Check the hotfix in to source control.
- Build & deploy to sandboxes, test, promote to MAIN/production… same as any other code.
It is easy and works fine… like, 95% of the time. But if you are here, something has probably gone wrong, or you are afraid something might (good instincts, you). You might be wondering if you did something wrong. Maybe you DID do something wrong. But maybe not.
After all, in one year of working with D365, I have seen application hotfixes that:
- Were marked “binary” instead of “application update” and couldn’t be downloaded until Microsoft fixed that marking.
- Broke customizations/overlays. (Expected.)
- Broke extensions. (Surprise!)
- Required followup actions in the GUI, which were not documented on the hotfix page (or possibly anywhere?), after deployment.
- Had undocumented dependencies on other hotfixes.
- Just plain didn’t do what they were supposed to do.
When a hotfix failed, I have lost hours, or even days (if it got into source control), fixing the damage. Arguably, I was dumb, and it didn’t need to be so bad. No reason YOU need to be dumb too, though.
In my next blog post, I’m going to talk about the steps you can use, proactively, to minimize the likelihood of problems when applying application hotfixes.