locked
Environment Setup Advice RRS feed

  • Question

  • Hi,

    I'm currently working on a project that incorporates Dynamics CRM 3.0. In preparation for the implementation stage of the project, we are preparing a solution architecture document. Part of that document involves describing how the development environments are to be setup. Another part of the document will require a description of the various environments that will need to be setup (dev, test, training, production) and how they will be setup.

    My first question is this: For one or more developers doing both CRM customization and custom callout/workflow assembly development, what does the development environment consist of?

    My initial take is that it could be as simple as a reasonably powerful development machine with Visual Studio 2003 and an MSDN development copy of CRM 3.0 (along with the other usual suspects - source control client, etc). As well, the development machines would need to be on the same domain as an Exchange server and be able to make use of Active Directory.

    At the same time, I've heard of people using VPCs for development purposes.

    My second question involves the various environments: Is it best to create separate Active Directories for dev, test and training? If not, what is a better approach?

    I can provide more details if necessary. At this point I'm just trying to feel my way through things.

    Thanks in advance for any advice.

    Regards,
    Matt
    Friday, October 5, 2007 3:35 AM

Answers

  • It's probably easiest to answer this by giving what I consider the 3 main scenarios you could go for:

    1. One Active Directory domains, with separate CRM installations on different servers for dev, test, training etc. This provides enough persistent environments that everybody can access. The AD will get a little cluttered with CRM security groups, but this can be managed quite well
    2. Separate AD domains, with separate CRM installations on different servers. This gives better isolation than option 1, but has an extra setup and server demand for the AD, CRM and SQL servers. If you already have separate domains for these purposes I'd use them, but I wouldn't establish them just for this
    3. Developers have a local CRM implementation on a VPC image (it's a lot easier to manage than having the local machine as a CRM server). Performance-wise this is viable on 2GB of RAM. This minimises the need for servers, but may require more frequent export of customisations

    All these are viable, and none of them have major flaws. CRM provides the tools to make it pretty easy to transfer data, customisations and code between any of these environments. In most cases it comes down to how many servers you have, and the preferences of the people who have to maintain them

     

    Friday, October 5, 2007 8:07 AM
    Moderator

All replies

  • It's probably easiest to answer this by giving what I consider the 3 main scenarios you could go for:

    1. One Active Directory domains, with separate CRM installations on different servers for dev, test, training etc. This provides enough persistent environments that everybody can access. The AD will get a little cluttered with CRM security groups, but this can be managed quite well
    2. Separate AD domains, with separate CRM installations on different servers. This gives better isolation than option 1, but has an extra setup and server demand for the AD, CRM and SQL servers. If you already have separate domains for these purposes I'd use them, but I wouldn't establish them just for this
    3. Developers have a local CRM implementation on a VPC image (it's a lot easier to manage than having the local machine as a CRM server). Performance-wise this is viable on 2GB of RAM. This minimises the need for servers, but may require more frequent export of customisations

    All these are viable, and none of them have major flaws. CRM provides the tools to make it pretty easy to transfer data, customisations and code between any of these environments. In most cases it comes down to how many servers you have, and the preferences of the people who have to maintain them

     

    Friday, October 5, 2007 8:07 AM
    Moderator
  • Hi David,

    Thanks for that. Very helpful.

    Matt
    Friday, October 5, 2007 11:00 PM