I’ve spent a lot of time over the last year applying my general application development experience to the world of Dynamics CRM customizations (aka XRM). Often, I take part in conversations that go something like “Why is X harder to do when customizing Dynamics CRM compared to general .NET web development?” I usually respond with “Well how exactly are you doing X?” After finding out, my next response is usually along the lines of “Well have you thought about doing it like Y instead? That’s a much more productive way.” The next response is usually “Well, why isn’t that documented somewhere?” My answer is usually “Well, it’s really just applying proven development practices to CRM.” These conversations are usually the catalyst for many of my blog posts. Sorry for the contextual tangent. Back to the point of this post.
When I first started focusing on Dynamics CRM about a year ago, I was adamant about developing in an isolated VM which included the CRM Server installed (if at all possible). The main reasons were:
- Developing in isolation from others
- Ability to attach to the necessary processes to debug plugins and workflow activities
- Speed of deploying web resources / plugins to the server through the developer toolkit (no network latency slowing the process down)
- Ability to create/delete CRM organizations on the fly for prototyping, starting from a clean environment, etc.
I still believe this is the best setup for CRM developers. However, I also recognize that many folks don’t have the hardware resources to give each of their developers a machine that can handle such an environment.
I’ve been asked quite a few times “Why isn’t there a lightweight dev server for CRM like there is for ASP.NET?” That’s a much longer discussion. It’s the same basic answer as why SharePoint and other server products with APIs don’t have one. However, what I think people really want is to be productive developing without having to install the full fledged server locally. As I was building out the walkthroughs for my posts on unit testing:
… I had a bit of “DUH” or “AHA” moment. If you practice Test Driven Development (TDD) using these approaches, go with the one org per developer approach on a remote server, and sprinkle in effective team development approaches enabled through Solution Packager, then you can become quite productive developing without a local server. Your remote server becomes your integration testing environment.
I still prefer doing all of the above in a local, isolated VM environment. There’s nobody else playing in my sandbox
. However, when you don’t have the luxury of installing CRM locally, I’ve learned that the combination of these approaches against a remote server can be a surprisingly productive setup. I’ve been forcing myself to use this approach lately, even in a local VM. It does take some getting used to. I call this the “up front setup/config tax.” Once you’ve paid the tax and get into a rhythm doing things this way, I think you will appreciate the efficiencies gained. Try it out. Let me know your thoughts.
@devkeydet
Gold Coast 