locked
Development Environment Setup for Multi-developer, Shared Solution sort of development in a big team RRS feed

  • Question

  • Hi,

    Guys, I have been looking for very reliable answers and guidance on how to setup my development environment to suit all my needs, so here are the points I have as an input, please help me out in understanding if there could be optimum way (from Dynamics licensing perspective too).

    1. I will have many developers working on the product, there could be groups formed among them.

    2. We have an architecture that uses dynamics CRM "Managed Solutions" to stack the things on top of each other, like there will something as a base product and other things in solution as on top of it.

    3. We will have a situation where multiple developers will need to do customization in same Solution.

    4. We will have cases when multiple developers might be working on same entity and it's form.

    5. We have a lot of cases where we will develop Silverlight code and .net plugins on entities CRUD operations, so we have some debugging needs.

    So essentially I will need things to be merged etc and there I have my challenge, I want to all that be seamless. I have gone thru the microsoft development planning links from MSDN but I am not sure which one would be optimum for my needs esp on licensing cost.

    Can I simply have one single Dynamics Server, with one organization created, and then everyone can develop their .net code and then it automatically gets worked out, with this can I have some better debugging infrastructure (where I can have multiple IIS servers or Async Service). I want to understand what all possible ways are there which will allow me to not need server license for each developer.

    please suggest.

     

    regards,

    Ram

     

     

     

    Friday, April 22, 2011 4:29 PM

Answers

  • Ram,

    I ran a development team at a company I worked at.  In that environment, we had the following:

     

    1.  Every developer had it's own development (physical) machine.  I suppose you can have virtual machines too.

    2.  Each developer had its own (local) installation of CRM, (along with SQL Server Developer Edition, VS 2008).  Check with Microsoft to make sure you have the correct license for this.

    3.  We had one test and one staging environment.  The test server is where every developer had to deploy their customizations, once unit testing was completed.

    4.  For Source Control, we had TFS 2008.  Typically, we had different developers working on their own thing; however, sometimes we had to work on common code.  We allowed for multiple checkouts.  Very seldom we had issues when checking the code in, but it was great for the most part.

    5.  In the case of custom JS code, which does not need to be compiled, we created an extra project in TFS.  This project was added to the global solution and excluded from compiilation.

    6.  As for the projects themselves.  Every type of project was separate from the rest.  So, plugins, workflows, custom pages, common classes were each in its own separate project.

    7.  When QA completed testing, the customizations would be promoted to staging and then production.

    8.  All deployments (files and customizations) were added to TFS to make sure all historical information was properly maintained.

     

    Cheers,

     


    oliver barrera
    Friday, May 20, 2011 6:23 PM

All replies

  • Bump !

    Monday, April 25, 2011 3:25 AM
  • I have the same questions too.  I would like MS to compile a document that outlines best practices for multi developer environments.  The solution feature works great for publishing our work but it is really complicating the development of our solutions, as there is no easy way for our devs to collaborate within a single solution.  We are considering using multiple solutions and then manually merging them into a single solution that we can publish but this route introduces a lot of work and the potential of not properly compiling the solution we want to publish.  Please let me know if you have any ideas on how best to approach this issue.

    Friday, May 13, 2011 4:39 PM
  • This is certainly a question worthy of a blog in itself.  We've been working in such an environment with CRM 2011 for almost a year now.  I can give you at least a couple of pointers:

    • You can work with a single installation in a dev environment, however make sure you have an unlimited license.  That way you can create an organization for each developer.
    • Each developer will want their own CRM server.  They can all point to the same db though, as there is nothing you can program there directly anyway.
    • The above will allow each dev to set breakpoints and debug without remote debugging, and without interrupting anyone else.
    • Plugin development can be managed in the usual way (pretty much) you are used to developing managed code.
    • Web resources are tricky.  It is very easy for devs to walk over each-others code in a large dev setting.  I recommend exclusive check out rights on your source control for these.
    • You'll find that implementing an automated deployment process for Plug-ins and web resources will save everyone some headaches.  Check the CRM SDK for code examples.  You'll most likely need to implement some custom version of this on your own.

    -JayB

    Friday, May 20, 2011 3:58 PM
  • Ram,

    I ran a development team at a company I worked at.  In that environment, we had the following:

     

    1.  Every developer had it's own development (physical) machine.  I suppose you can have virtual machines too.

    2.  Each developer had its own (local) installation of CRM, (along with SQL Server Developer Edition, VS 2008).  Check with Microsoft to make sure you have the correct license for this.

    3.  We had one test and one staging environment.  The test server is where every developer had to deploy their customizations, once unit testing was completed.

    4.  For Source Control, we had TFS 2008.  Typically, we had different developers working on their own thing; however, sometimes we had to work on common code.  We allowed for multiple checkouts.  Very seldom we had issues when checking the code in, but it was great for the most part.

    5.  In the case of custom JS code, which does not need to be compiled, we created an extra project in TFS.  This project was added to the global solution and excluded from compiilation.

    6.  As for the projects themselves.  Every type of project was separate from the rest.  So, plugins, workflows, custom pages, common classes were each in its own separate project.

    7.  When QA completed testing, the customizations would be promoted to staging and then production.

    8.  All deployments (files and customizations) were added to TFS to make sure all historical information was properly maintained.

     

    Cheers,

     


    oliver barrera
    Friday, May 20, 2011 6:23 PM