To answer these questions once and for all, I will post my suggestions in two articles. I will step way outside my comfort zone of coding the solutions and give you strictly no-code alternatives. Well, I do feel reasonably comfortable, since I wrote the code in the tools we need… ?
If you have problems shifting gears in your car, you don’t call Volvo to say “Hey, I don’t like how this gear shifting thing works, so I’m just going to use reverse and drive backwards from now on.” What you probably do is call them to say “I’m having trouble shifting, you need to fix the problems or show me how to use it properly.“
Ever since Microsoft introduced the Solution platform with Dynamics CRM 2011, there has been an ongoing and never ending discussion about whether to deploy managed or unmanaged solutions.
I can’t say I can end the discussions or solve all problems. But I will try to convince you – there is no discussion.
Recently I posted a series of three articles describing our approach to DevOps for Microsoft Dynamics 365, and the technology behind it. After giving a session on this topic at CRM Saturday in Madrid, Spain, it is now time to announce “public preview” of our tools.
If you want the full story – these are the articles describing the background and technology behind our tools:
Below is a sample of a full build process that not only builds and packs a new CRM solution, but updates the individual assemblies and webresources in DEV environment, exports solutions and data, and then publishes the files exported from DEV together with Shuffle Definitions and Package Definition, which is the resulting build artifact.
We now had the tools we needed to automate the central parts of the build/deploy process. But it still involved lots of manual or script based steps. To describe it simply, the following steps were required to produce a full deploy of a Customer Solution (CS) that has a prerequisite in one of our Product Solutions (PS), assuming we wanted the latest available code and customizations for both PS and CS.
Define new PS version number
Set version number for assemblies
Use Plugin Registration to update PS DEV assemblies
Minify webresources (scripted post build event)
Use Web Resource Utility to update webresources in PS DEV
(scripted post build event using modified version from SDK, that allows command line execution w/o user interaction)
Run Shuffle scripts that export PS solutions and data from PS DEV
Run scripts that import PS to CS DEV
Define new CS version number
Set version number for assemblies
Use Plugin Registration to update CS DEV assemblies
Use Web Resource Utility to update webresources in CS DEV
Run Shuffle scripts that export CS solutions and data from CS DEV
Create package (by running a script)
Collect all required definitions, solutions and data files from PS and CS exports
Execute CRM Deployer with cdpkg file and a flag to create cdzip archive
During my eight years as a Microsoft Dynamics CRM / 365 developer, I have felt a strong pain every time it was time to package and distribute a customer or product implementation.
Over the years our tools have evolved to now support a complete automated process; from source repository via compilation, updating dev environment, exporting solutions and configuration, collecting the artifacts and compose deployment packages to be installed manually or by VSTS release management.
This is the first article of three telling the tale of our own DevOps for Microsoft Dynamics 365, and the technology behind it.
Back in the days of CRM 4.0 we started delivering systems that were based more and more on generic configurable functionality. The benefit of having an automated way of delivering and moving configuration data between CRM environments was becoming increasingly obvious. This was long before utilities like the Configuration Migration Tool, so we started to draw the blueprints to develop the functionality we needed. Basically, what we needed was to grab a bunch of data from a source environment to persist it in a file, and later push it into another CRM organization.
In this article I will demonstrate how to implement a plugin to extend the possibilities for showing activities that are related through account hierarchy in a subgrid on a Microsoft Dynamics CRM form.
In my previous article I showed how to create a simple plugin to show all directly related activities in a subgrid, and not just activities related through the Regarding field.