DevOps for Dynamics 365 Customer Engagement (CE) is becoming a popular topic. The goal of this project is to help Dynamics 365 CE solution builders understand and accelerate their implementation of DevOps practices with Dynamics CE and VSTS.
It does not support instance reset (which is available through the admin center ui). One has to mimic a "reset" by deleting the instance and creating a new one. The side effect of this is that backups for the deleted instance disappear. Which effectively renders the act of backing up before "resetting" useless. The correct solution to this problem is for the management API to support reset because backups are kept during a reset when performed through the Dynamics 365 admin center ui. Please vote up the feature request here: https://ideas.dynamics.com/ideas/dynamics-crm/ID0002981
Demonstrate restoring an instance from backup before deploying a new build to it. This is a common scenario for those who want to deploy their customizations on top of a previous version of an already deployed version.
There will be two tasks. One to delete the instance and one to create an instance (which is what the current scripts do). The management api doesn't currently support "reset" so you have to "reset" by delete/create.
Once the VSTS tasks are available, update the release template to use them.
I am exactly following your GitHub blog and videos and i got everything working in my environment. We created a new visual studio solution and adding all CRM solutions as website projects inside it (thus we are not storing plugin/webresource code within same solution or repository).
I am getting errors in the map configurations under spkl.json file of the project. Since plugin code is not part of the solution, what should the map "from", "to" be in spkjl.json file?
Is there a way i can download the plugin/webresource code into my project from CRM solution and thus reference the code in map?
Hi,
I am seeing the following failure when the MSCRM pack solution is running:
[error]Cannot find path 'D:\a\1\s\SolutionPackage\package\Other\Solution.xml' because it does not exist.
How is it resolving the file path to D:\a\1\s - do I need to update a variable or config file?
I get this error referencing CrmAsyncRequestResponseSample projects.
Variable names evolved iteratively. Some no longer have obvious meaning. Improve names to reflect their purpose, then update build/release tasks to use those new names.
The "Create Or Update Azure Resource Group" takes forever. It eventually gets cancelled by VSTS due to timeout. When checking Azure Portal, the resource is stuck in a deploying state. However, all the resources appear to get deployed.
While it's nice to demonstrate how release management can automate the creation of azure infrastructure using an ARM template, it can be overwhelming for some. Give an example of a release deployment where the azure infrastructure is already deployed and just show deploying the code to Azure.
I can import the Primary Build definition, but I got below error when saving.
The request specifies project ID 40e7ae05-db93-41cb-9334-ad0db7b87821 but the supplied pipeline specifies project ID 7895651c-7f1a-466c-aa8f-0352510e6c2c.
Looks like the ID is stick with your original project. Is ther any way we can resolve this without manually re-create the definition?
While it is nice (and necessary) to learn how to deploy an existing application, what's missing is the ability to understand how to get the initial "skeleton" solution setup to be in a position to source control all the items. To that end, create a Visual Studio solution that contains a set of projects for the following:
Web Resources
Plugins
SolutionPackage
DeploymentPackage (i.e. Package Deployer project)
InitialData (i.e. using DataMigrationUtility.exe)
The intended use case would be:
-Developer downloads "skeleton" Visual Studio solution/projects
-Developer commits to their source control repository
-Developer can manually create the web resource and plugin assets or use tools like spkl (https://github.com/scottdurow/SparkleXrm/wiki/spkl), or others to bring existing assets down.
-Developer can use tools like SolutionPackager (https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/compress-extract-solution-file-solutionpackager) or spkl (which provides is a wrapper around SolutionPackager) to bring configurations into source control
-Developer is able to "get started" faster and now focus on using build and deployment automation from VSTS pointing to their source control system.
Right now, have redundancy across spkl.json and map.xml. spkl creates it's own solution packager mapping file from spkl.json. Use that instead and delete map.xml.
...explaining devops, followed by devops in the context of Dynamics 365. This will help others with context and understanding when viewing the other videos.