SharePoint Project Collaboration – Best Practices

Hello and welcome to the first in a new series of blog posts from the members of the SharePoint practice at Magenic. Magenic has a wide range of SharePoint and application lifecycle management expertise to serve you when you are engaging enterprise development within SharePoint.  One of the key challenges with a team of developers and enterprise development on SharePoint is how to enable the team to effectively work together.  We’ve seen this done well and we’ve also experienced instances that we would love to forget.

In these situations, your goals are:

• To enable each developer to work independently of each other.  You don’t want developers “stepping on each other’s toes” so to speak (e.g. upgrading conflicting deployments to the same farm, interrupting each other because there is an IIS Reset with every test deployment, etc.)
• To have the benefits of a source code control system that provides version history and task management
• To have tight control over what goes into a release along with a well-defined, highly automated deployment process as you deploy solution packages from an integration testing farm, to a QA farm, to production.  Ideally, you would want a single Visual Studio Solution containing multiple Visual Studio projects, some of which generate SharePoint Web Solution packages.  You want to avoid having each developer work in a silo such that their changes can’t integrate.  Giving each developer their own development environment while sharing the Visual Studio solution accomplishes that.

To achieve these goals, we find that it is best to use Team Foundation Server (TFS) for source control and task management and for each developer to have their own development environment.  For the development environments, two options are available:

1. Virtual Windows Server 2008 R2 server – This environment provides a setting closer to real-life or production for developers but requires additional licenses and resources. These may be provided by the client, available as a local desktop solution or even from Magenic on particular projects. They can also be rented from organizations such as Cloudshare. VM instructions can be found here and will be the subject of a future blog.
2. Windows 7 desktop – SharePoint can be installed on a Windows 7 Enterprise Edition workstation supplied to all Magenic consultants, and can usually be set up and working in under a day. Since the developer is using their own desktop, there are no additional costs for licenses or resources. In most cases, this is the best scenario for a team of developers where the farm architecture is not itself the subject of the project.

So now comes the question “What are the best practices …” of which an Internet search might make your head spin as you realize that it will always be tailored to the project at hand.  Whether you are the UX master designer, the team lead developer or the staff-aug admin, your tool of choice will either be dictated to you or forced on you by the conditions.  You will not always have the power to “recommend” a method, so you should at least be able to intelligently explain to project managers and your client the implications of the chosen setup.  To make this easy, consider the following table showing setups, their best use AND their limitations:

As this is a blog, the comments and collaboration of all is appreciated, especially in the use and combinations above. Submit your scenario and how it has worked/did not work for you.

Magenic consultants Michael Blumenthal and David Lozzi also contributed to this blog post.