Sunday, February 25, 2007

Development Environment for MOSS 2007

I'm interested in working out the best approach for developing on MOSS 2007. My first preference is to have a central MOSS server that is shared by the team and allow developers to debug remotely.

The advantages that I see with this are:
  • The development environment remains similar to the production environment

  • Less resources required on each developer's workstation

  • Better chance of identifying issues with other developer's code early on

  • Forces you to have good deployment strategies that can be re-used for deploying to test/production/DR environments

  • The disadvantages are:
  • Harder to debug - must be done remotely, and from what I hear this is particlarly difficult with workflows

  • Risk of overwriting other developer's efforts (proper use of a source control product reduces this risk)

  • May need to co-ordinate debugging/testing with others in the team

  • For me, the advantages outweigh the disadvantages, but I'm keen to understand other people's experience in this area. Please provide your comments if you have any experience/opinions on this.

    The other configurations that I see include:
  • Installing Visual Studio on the Dev server and allowing developers to remote-desktop on to debug. I dislike this because it means that you have to modify the permissions on the server, it means the Dev and Test environment are significantly different and puts extra load on the dev box. Also only two developers can work on the server at any time (assuming you only have the standard Terminal Service licenses).

  • Each developer running local Virtual PCs. Because our company mainly does on-site consulting, a lot of our developers have laptops. This makes it more expensive to beef their machines up to a spec that can comforatably run a MOSS 2007 VPC that runs Visual Studio. In fact a few of our laptops cannot have their memory upgraded beyond 1.5 GB. Another hassle here is that each developer is working in isolation. Conflicts between components won't be discovered until a later stage. This risk can be reduced by having strong source control and deployment processes.

  • I also found this great post from Eli Robilliard on this topic: