I am looking to automate the deployment process for CRM between different Environments eg.Development Env, Test Env and UAT.
I am wondering if there is existing tools(s) available on market to automate the deployment for me?
If NO, Is it possible to automate the CRM deployment between different environments and what is the best practics for doing that?
Thanks
Where I work we are currently working with the exact same issue. I spend quite some time initially looking for of-the-shelves products that could help us, but I have not found anything promising. Therefore we have undertaken the task ourselves.
Some guys from Microsoft made a short "whitepaper" on the subject which I found quite helpful. It can be found here at Deploying Microsoft Dynamics CRM 2011 and CRM Online Solutions from Development through Test and Production Environments.
I will not claim that we are using "best" practices, but we have chosen to try and script everything in PowerShell or through .net based CmdLets in our own PS-module. CRM server comes with a PowerShell snap-in that sports some basic functionality for creating/removing organizations, but you are more or less on your own when it comes to actually "deploying" CRM-customization, configuration data, users etc.
It would be interesting to know, which approach you choose (if any)? And if you have any specific question, please don't hesitate to ask!
How about this?
The xRM CI Framework is a set of tools that allows you to quickly and easily implement Continuous Integration for your Dynamics CRM solutions.
PowerShell and the XRMCI framework will serve you well for solution deployments, the downside being that for Standing or configuration data that cant be added to a solution (or for solution items that are currently buggy in CRM 2015 e.g. Case Creation Rules, SLA Items etc.). In this case, my client and I have created powershell C# CmdLets that use the SDK and API to create standing data such as Users, Teams, Memberships, Queue's, Case Creation Rules (although its unsupported, the API does allow it), and to configure mailboxes etc.
So in combination, the XRMCI framework, C#, and PowerShell can be used to automate a deployment of one environment to the next. The key is to take it slow, manually execute the scripts to begin with and build trust in the process, tweak and add more elements. Once that trust is achieved, move onto integrating it with TFS in as a CI/CD process.
As for best practice, my own research suggests that this is still a "he/she who dares" area with no real "best practice", in time the players such as Chef, Puppet, Octopus and Microsoft (with DSC) will contribute, but for now....
Related
I have been told that "to use managed solutions for deployment through Dynamics 365 requires the developing organization to be a certified ISV for Dynamics with Microsoft. And furthermore, that a Managed Solution also goes through some sort of vetting process within Microsoft."
This sounds like some sort of misunderstanding to me.
From my understanding of the use cases for unmanaged and managed solutions, there is no such restriction on my creation of managed solutions. All the documentation I have seen mentions the benefits of using managed solutions but does not go into any sort of detail about having to be a certified ISV or that the solution has to be vetted.
I am new to using D365 and am having a hard time determining if what I have been told has any truth to it. My question is if anyone can clarify if there really is any sort of certification required by my company to use the concept of managed solutions?
A small confusion.
Customizing & deploying as a Managed solution (part of internal DevOps) within your organization is not needed to go through vetting process.
Partners/ISVs developing & distributing the Managed solutions through Dynamics Marketplace aka Appsource has vetting process, Microsoft will review the solutions before publishing in AppSource. This is to make sure the compliance with respect to standard, policies, security aspects.
We are in the process of implementing the sharepoint application, we would like to know the the pros and cons of SharePoint workflow versus Windows workflow.
Workflows in SharePoint are implemented using the Windows Workflow Foundation, so they are not that different, but there still are some things to be aware of regarding that implementation.
SharePoint is a Windows Workflow host, so you don't have to implement your own host which is fine if you agree with the decisions made by the SharePoint team:
Workflow instances are persisted in the content database
Communication with the user is through SharePoint tasks
Every workflow instance is tied to a list/library item
Tracking is not implemented
If these choices are to your liking then by all means use the SharePoint workflows.
If not then implement your own host and make your own decisions.
They are the same thing. The current Windows Workflow Engine was created for SharePoint.
Now it should be noted, that the Workflow engine is going to be overhauled with the release of .Net 4.0. I don't know the specifics, but I've been told the differences are significant. I woudld assume this is going to be used in Sharepoint 2010, but I don't have any information on that.
Here is a link describing the upgrade in 4.0.
You haven’t specified whether you’re building a custom coded application in SharePoint or configuring an out of the box solution via the browser. Either way, here are a few options for workflows in SharePoint.
Use the native workflows built into SharePoint and readily accessible from any list. They’re very basic (mostly simple approvals with one or two steps), but they’ll get you up and running very quickly and it can all be done via the browser.
Use SharePoint Designer to build slightly more complex workflows. This will give you access to conditional logic (i.e. route a workflow based on a list value) and unlimited steps and well as a number of other features that allow you to introduce more logic into the process. The downside is you have to work with SharePoint Designer which, to be frank, can be a real pain.
Custom code your workflows in WF. Windows Workflow underlies the first two options which are essentially abstractions on top of the underlying framework. The main difference with this approach is that you’re not limited to the functions that the browser or SPD surface. The downside is that this becomes a more complex process (although admittedly the workflows will likely be more complex) and you have to go through the rigmarole of coding against SharePoint, packaging deployments, publishing, etc.
I find the best balance in terms of ease of development and functionality is to try and work through the above list in the order I provided them and only progress to the next option if you definitely can’t implement the requirement with the current point.
It's basically the same technology. If you know one you can easily work with / switch to the other.
When you add the SharePoint dll to your solution you get some specific SharePoint 'activities' that you can use in your workflow. (create task, ...)
Your SharePoint Server will act as a host for your workflows.
The best way to deploy a workflow in SharePoint is by using a SharePoint feature. This tells SharePoint what dll (assemblies) to use and which (input) pages to show.
As input pages you can use simple .net aspx pages or infopath forms. Both require some trial and error to get the hang of it.
SharePoint simply uses windows workflow Foundation (WF) as its workflow engine. WF in itself is just a generic workflow engine.
In order to use WF you must implement a host process for the execution of workflows, and configure it so it persists instances to database etc (these days most people use a WCF service as a workflow host, see here or here).
SharePoint comes with everything already configured and implements its own workflow host, so you can start using workflows out of the box. Apart from that, it comes with custom activities and other goodies specific to SharePoint.
As stated in other answers, they are the same, as they use the Windows WOrkflow Foundation. That being said, there is a major thing to keep in mind when it comes to Workflows created through SharePOint Designer: They are not "portable" out of the box, meaning that you can create one bound to list a, then save the list as a template and then create another list based on that template, the workflow will NOT work (you have rebind it as it is still referencing the original list's id (guid).
Microsoft Team System appears to be a great platform for process-oriented systems implementation, however if you strip out access for the BAs, PM and Business Users and just purely use it within a Dev team does it have any more value than just using Visual Studio Professional, SourceSafe, a Defect Tracking Tool and a continuous integration server like CruiseControl or TeamCity?
Yes. Every replacement technology you've mentioned is something that is supported by the Team System package (either in this release or the next). All of these components are designed to integrate and work with each other in TFS. This is a high priority of the TFS team for all components. The result is a set of features which in most cases seamlessly integrate with each other.
I'm not familiar with several of the other projects you mentioned but it's unlikely that they integrate as well with each other as the corresponding TFS components. This is not to say they have no integration or perform poorly as products. Just that they are not designed ground up to work with each other. Hence the interaction will not be as crisp as the TFS components.
Is this valuable enough to continue using TFS? Don't know because it would be highly dependent on how much you value this integration.
One of the big selling points for TFS for my team is the coherency it provides to our overall product life cycle. We do allow BAs, PMs and Business Users to have certain levels of access to TFS, but even if we did not, the product would still be of great value to use. The ability to manage our workflows within TFS and enforce consistency across the development team is great.
Some of the features that TFS provides that we use: security, reporting, work flow management, integrated builds, email alerts, branching / merging.
Could you pull it off with a hodge-podge of other tools? Probably, but it wouldn't be as easy to manage and maintain and you probably wouldn't be able to pull out the kind of data necessary for reporting and tracking the way you can with TFS.
On a sidenote, if your counting on Visual SourceSafe as your repository I would highly suggest looking elsewhere. From personal and business experience, I can attest that it cannot be counted on as a stable/robust repository.
My thoughts.
Sure it has value. There are a ton of client features only in the Team SKUs (don't let the name fool you -- they are primarily just the new "super premium" kitchen-sink versions, that also have the nice bonus of including a server CAL for TFS.) Exact specs available here: http://www.microsoft.com/visualstudio/en-us/products/teamsystem/default.mspx
Looking specifically at the collaboration features, again there's clear value in a system whose components were design to "just work" with each other. The setup is streamlined (though it has a ways to go); the UIs are consistent and accessible from each other; the backend feeds a unified reporting/analysis service. If you have a large team, the overall perf/scalability also far exceeds what the typical OSS suite is capable of at the moment.
The question is whether it's worth the $$ to you. Why use Visual Studio Professional instead of SharpDevelop? Why SourceSafe instead of Git? Why not Notepad and specially labeled folders?
All of the commercial products are commercial for a reason (ok, maybe not SourceSafe!). If you want something with a broad feature set, tight integration, well-defined support & testing lifecycle, good fit & finish, etc then it's usually worthwhile to spend the $$ and let your development staff get on with their work. If you don't mind doing setup & troubleshooting yourself, switching between several applications as part of the development workflow, losing the ability to query & report on team statistics as a whole, etc then by all means go open source -- many OSS dev tools are very solid nowadays.
My organisation is in the final stages of acquiring CRM 4.0 for use as a general purpose software development platform. The company who is selling it to us has convinced upper management that CRM will solve all our productivity problems and make software development as easy as point and click. (They don't read Brooks.)
Having resigned to the fact that I can't stop CRM from being foisted upon us developers, I have been doing research on how to manage the complexities of large scale CRM development.
I have so far identified the following complexities that need to be addressed:
CRM seems wholly incompatible with basic configuration management practices.
Keeping the black box CRM database in bidirectional synchronisation with external LOB systems is both very hard and critical to project success.
What other complexities must I take into account when building a large scale CRM application?
What limitations does CRM have as a development platform?
Edit: This topic provided additional insight.
I've worked with MS CRM 3.0 and now 4.0 here's my take:
Whenever possible focus on standard best practices. Don't get overly confused by what CRM is doing or wants you to do.
Don't be afraid to break what's "supported" by MS. With some caveats on 2 major factors - will your company let you think outside the box to solve problems and do customizations/integrations that are not officially supported? - and are you comfortable enough with .Net, SQL, javascript etc to weave through their code and implement what you need?
I have sometimes banged me head 100 times trying to do something in a "supported" fashion when one small tweak to a js file here or a small db modification there gave me what I needed.
If constant data integration with other LOB apps is critical you should consider a 3rd party tool like Scribe (http://www.scribesoft.com/). It's not cheap but can basically get you 90% of the way when it comes to integrating with your other LOB apps.
As a general rule, MS CRM is great at contact management - doing things like tracking appointments, doing mail merges, etc. Could you use it as your core HR system - probably. Finance system - maybe a bit more difficult. The further you go from it's core competency of performing contact management the more custom work you'll have to do. The more custom work you have to do the more you should consider if MS CRM is the right solution to that problem.
I know you're likely well underway into your deployment of Dynamics CRM, but just a few quick tips:
I'd avoid making unsupported changes purely because it becomes too hard to track the changes eventually. Since Dynamics CRM allows developers to make C# Plugins and access to web services, it's usually unnecessary to make unsupported changes for anything non-trivial. Plus you run the roulette of having to hide changes from MS if you have to call their support. I know many people will include external javascript files (jquery, etc) and other somewhat benign changes, but try to mentally stop yourself when an unsupported edit involves anything non-visual.
Look into the phrase Microsoft Dynamics Xrm, there are several books on the subject that are excellent, http://www.thecrmbook.com/ is particularly good because it comes with some nice custom code to use with your CRM.
Source Control your customizations xml's and don't let people touch the database, also, Google Halan CRM tool, and use it for scripting out CRM customizations and javascript files. Easier than writing custom powershell scripts to do the same job.
Transaction Support
If your application require transaction support from the underlying platform, Dynamics CRM is not the correct choice. The reason is because currently Dynamics CRM SDK web service doesn't support transaction.
The reference thread is here : Does MSCRM web-service support database transactions?
Since you would like to utilize Dynamics CRM as a platform, that means all the business logic should utilize Dynamics CRM SDK Web Services as data access layer. But imagine without the transaction support and you're invoking a series of web service calls as a unit of work, and one of the web service calls fails. That means you potentially will encounter data integrity issue.
Configuration
Usually i create a custom entity called Configuration, which will store all the necessary related configuration for the current CRM application. After it has been created, you can use Dynamics CRM SDK Web Service to read all the necessary configurations from the Configuration custom entity
Our business is looking to automating Dynamics CRM hosting. We've been looking at the options. At the moment, it seems like HMC/MPS would be useful. However, from the looks of it, the frameworks are nearing end of life and are also. HMC/MPS also seems to be based around exchange. Would it make sense to use HMC/MPS to provision CRM or is there another framework. Would we be better off talking directly with the Active Directory and CRM Deployment Service APIs?
I work for EMS-Cortex and this is what we do. Please have a look at our website www.ems-cortex.com and if you are interested get in touch.
Please remember HMC/MPS has been cancelled, and if you invest in it now you are investing in technology which will have disappeared in about 12 months.
Kind Regards
Daniel Thurston