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.īoth the export and import had to support configuration beyond the “ Export to Excel” functionality available. This was long before utilities like the Configuration Migration Tool, so we started to draw the blueprints to develop the functionality we needed. The benefit of having an automated way of delivering and moving configuration data between CRM environments was becoming increasingly obvious. It started with the dataīack in the days of CRM 4.0 we started delivering systems that were based more and more on generic configurable functionality. If you are already there, these articles should provide an alternative solution, which may or may not suit your needs today, but might be worth considering. Part III – Demo of complete build and release definitions taking you from A to Z My hope is that these articles will inspire you to take your delivery process to the next stage by implementing automation through CI and what is usually called DevOps. Part II – Automation of the build and deploy process using custom VSTS Build Tasks Part I – Background and how our DevOps tools evolved before we knew about it This is the first article of three telling the tale of our own DevOps for Microsoft Dynamics 365, and the technology behind it. 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.
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.
0 kommentar(er)
