Dynamics 365 Deployment Approach

Integration
1

Hi Octopussers (?)

We’re starting a fairly large project where we intend to deploy full ALM packages through a lot of different Dynamics 365 environments. I saw a post from a while back regarding Dynamics/SharePoint deployment, but it didn’t really give any of the answers I’m looking for.

So what I’m looking for this to do is:
Deploy a Dynamics solution; with potentially some data imports as well as perhaps some specific clean up and actions

Since this is an SaaS application we don’t have access to a machine to perform deployment operations. Everything we need, will need to be done through webservices. In the past I’ve referenced the SDK from PowerShell to make the appropriate methods available. So I’m trying to figure out how I could accomplish something like this (even conceptually) through Octopus.

Some of the tools we have:
VSTS instance for ALM and source control
Multiple Dynamics 365 Instances (multiple development and typical ALM)

My thoughts so far:

Create a package (of some sort) that includes: Dynamics Solution (zip file), Data files (csv), SDK dlls (for reference in the PowerShell scripts?), The scripts itself to perform deployment

Random thoughts:
If I have multiple steps: remove master data, deploy master data, unpublish reports, publish reports, import solution file; is it best to separate these out as deployment steps and make them more modular, or should I go with an all-in-one type script and have an XML file where I replace some variables using Octopus?

I’m fairly confident in my PowerShell skills or at least my google skills :), I have a programming background (would C# Script be easier for me to leverage?), and have been doing Dynamics projects for close to a decade, I’m totally new to Octopus (obviously). So given these skills i’d be more than happy if someone would throw a URL at me that could give me some thoughts around how to best approach this.

2

Just to add reference to it. The link I referenced above is:
http://help.octopusdeploy.com/discussions/questions/3087-deployment-assets-for-microsoft-products-dynamics-sharepoint

Don’t think it really applies here.

An idea around how the PowerShell tools would look: https://github.com/seanmcne/Microsoft.Xrm.Data.PowerShell I’d love to leverage those in my package.

3

Hi Alex,

Thanks for getting in touch! Your thoughts so far are good. To answer your Random thoughts question, we would generally recommend separating your scripts into their own individual deployment steps within a single Project. That will make it easier to manage. For instance, what if one part of a large script failed? You would not be easily able to tell what part had completed successfully. If you break it into components you have more control (partial deployment) or better knowledge of your deployment status.

We don’t have much experience deploying SharePoint/Dynamics solutions specifically with Octopus (like you saw in the old forum post you linked). I have found some great resources online guiding the process of deploying SharePoint solutions with Octopus integrated into their deployment pipeline. I think these examples may be of help to you while working on modelling your approach:


We also have a Library template for deploying SharePoint solutions courtesy of our great community :slight_smile: https://library.octopusdeploy.com/step-template/actiontemplate-sharepoint-solution-deployment

I hope this helps you get started! All that being said, please don’t hesitate to get back in touch if you have any specific questions.

Best regards,

Kenny

4

Hi Kenneth,

Thank you for this. Two questions I have:

Where do I put these SDK dlls? I see an input for the ps1m bit, but I wasn’t able to figure out where to put the required dll files. The GAC would be the least preferred method, but if it’s needed I’ll load it in.
About the tentacles; all of our environments live in the cloud through SaaS or PaaS so we don’t have any VMs that could act like Tentacles unless we set one up in a dedicated role. What would be the best approach here? Can I go without and do a “Cloud” deployment, or can I make the Octopus server act like its own tentacle?

I’ll fiddle a bit with the stuff below to see if I can get it to do something :slight_smile:

Alex Ries | Manager

5

Kenny

Thanks for following up. If you install the Tentacle on the server, and the SDK dlls are installed on the server, the Tentacle would potentially have access to all the dlls.

You could also include the dlls as part of your package. Calamari is open-source, so you can refer to how we reference PS modules in the path of a package in our Calamari.Azure context, for example. The following link highlights adding the PS module path variable and is how we call through to the Azure PowerShell modules that we have bundled with Calamari:

We have Octopus variables to tell where the files were extracted to. You could potentially take the path and put it into the PSModulePath environment variable, then you should be able to call your PowerShell modules from your deployment scripts.
You can also see which variables are being used in a deployment and what they evaluate to, using the steps shown in our doc: https://octopus.com/docs/how-to/debug-problems-with-octopus-variables

I hope that offers some more information, and helps you avoid having to use the GAC. Fiddling around may be the best approach in determining how you’d like to proceed :slight_smile:

Best regards,

Kenny