Selecting your Dynamics CRM developer(s) setup

If you are ever involved in a very large CRM implementation project, one of the decision that you need to make early is how to setup/structure your development environments and workstations. Not that I think it’s not as import on smaller project, but it is more critical in larger project.

First let’s start by defining what I mean by a large project (this is a completely personal):

  • Large development team (4+ people)
  • Multiple complex customizations pieces (plugins/custom activities/JavaScript/HTML) and/or integration points
  • Project length: variable, usually 6-8+ months

Last year, I wrote about how to setup your Dynamics CRM/Source Control environment properly for Dynamics CRM projects. Today, I want to focus more on the Development Machines setup and what I have found to be useful for decision making process to set them up.

In the typical CRM project, you will find a Dev CRM organization used for doing system configuration and basic customization. Then, for plugin/JavaScript development, we typically recommend to have either a dedicated VM with CRM installed for each developer, or a dedicated CRM Organization. The reason why we make this recommendation is very simple: development Isolation.

When you are developing say a web site or a mobile app, you don’t deploy your content on the test server or device that everyone uses until it’s ready to be tested. The same applies for CRM. If you have a primary development organization, why would you want developers to deploy work in progress on a regular basis? Plus, if they are working on the same module, they might overwrite each other’s code all the time. The loss of productivity will be at two levels

  • Deployed code that’s not finalized will cause bugs and people won’t be able to continue working, test in the CRM organization normally
  • Developers will likely overwrite each other if they are working on similar or dependent tasks which will result in a major loss of time and productivity

Now that I have sold you on the development isolation idea, here is a list of pros and cons that will help you decide whether you should go the individual CRM Organization way or the individual VM + CRM route.

Individual CRM Organization

  • Pros:
    • Easy to setup
    • (possibly) Part of your corporate domain which makes the access easier for developer and possibly other people if needed
    • Provides isolation for development
  • Cons
    • Developers lack control over the servers (i.e. can’t do IIS reset or restart services etc.)
    • Depending on how powerful your infrastructure is, sharing CRM/SQL Servers with multiple users, the servers might be overloaded quickly and you find yourself with an issue related to sharing your server resources
    • Removes the ability to debug the old fashion way by attaching to IIS/sandbox/async processes
    • Ongoing maintenance of the CRM/SQL server(s) hosting the organizations

clip_image002

Individual VM with CRM/SQL installed

  • Pros:
    • Provides developer with great control over the environment in which they develop
    • Provide isolation for development
    • Provide isolation for Hardware utilization (depending on how VMs are setup)
    • Easy to setup (build a VM once, create a capture and provision on need)
    • All development tools can be installed on the VM and isolated from workstation
    • Easy to do plugin/custom activities debugging by attaching to IIS/sandbox/async processes
    • Easier to perform integration test in an isolated VM
    • Relatively light use hardware resource if the VMs are hosted on developers’ workstations
  • Cons:
    • Possibly Windows OS Server license issue (each developer needs one license)
    • Network configuration can be tricky depending on your environment or Enterprise context (e.g. accessing TFS from VM, expose VM to the internet)
    • Heavy use of hardware resources (especially if you have VM Host server(s))
    • Ongoing maintenance of the VM host server and VMs

SNAGHTMLec1ea7

It’s worth noting that individual VMs can be created on a host server or on developers’ local workstations (laptops or desktop). You may or may not decide to join the VMs to the corporate domain, you could even setup your development environment in the cloud on a Virtual Network which we have done multiple times including for my company. 

Lastly, as noted by Darly Labar, if your project is with CRM Online, running VMs locally will prevent you from having a same version of Dynamics CRM in your developer VMs (CRM Online and On-prem are very similary, but not the same and not always in sync). The same applies for the individual developer CRM organization unless you have a CRM Online Sandbox for each developer or other instances of CRM Online they can use for development purpose.

There you have it. The great thing is that you always have options. From there, it’s making sure you select the one that is appropriate for your needs.

If you need help and guidance throughout this process, feel free to reach out to us at SADAX Technology. We offer “Hour Bucket” packages from 5 to 30 hours for Dynamics CRM and Azure consulting services. Request a quote here!

 

Advertisements

5 thoughts on “Selecting your Dynamics CRM developer(s) setup

  1. You should also mention that if you’re running CRM Online, you won’t always be able to have a VM version that matches the CRM Online version…

  2. In the “Individual VM with CRM/SQL installed” configuration, you state under the “Pros” section that “All development tools can be installed on the VM and isolated from workstation.” Can you please explain the benefit(s) of running Visual Studio from the VM as opposed to running it from the workstation?

    • Sorry for the late reply here. Installing development tools on your VM means you keep your workstation light on dev tools that can take up lots of space and memory (not everyone cares about this). Plus, having dev tools including Visual Studio and your plugin/custom WF code on the individual server will allow you to debug your plugin by attaching VS to your IIS process which for some of us, is a real plus (those who don’t like using the Plugin profiler to debug plugins).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s