Managing team based SharePoint development scenarios

If you are starting on a SharePoint development you will need to start thinking about how you will manage and provide a team based development environment for building and deploying solutions for SharePoint. Even in a scenario where you are about to deploy a medium SharePoint environment then you will need to address the following points in order to cater for a team based development approach. If you are a jack of all trades developer who does everything you can stop reading now. But in most cases organisations will have a number of developers working together to build and develop solutions to be deployed to SharePoint.

There is a significant investment involved in setting these up and usually provisioning three separate deployments (Dev, Stg and Prd) such as above may not be seen as high-priority. However let me point out some cases where you will need to start prioritising on the above when rolling out and deploying solutions based on SharePoint. Say you are deploying a largish Intranet. It’s a given that you will need to deal with the following

In the first phase of your project you will need to agree on putting in processes in place for ensuring that your investment in SharePoint can be realised longer term. It’s typical for some projects to launch with a budget to build the intranet and go-live but the reality is in order to gain value of your investment your organisation will need to budget for ongoing maintenance. And if you don’t plan to address the above scenarios you will end up again in the same situation where you started from. Remember your old intranet? Which never got updated or never had any new functionality because it was not easy to add functionality? And you actually got funding to build an easy to manage “new” Intranet? Right?

With a SharePoint project you will need to plan for constant change that can be a challenge to manage. What I mean by this that with SharePoint you will need to manage changes on two fronts. These are changes or additions you do using code by creating new web parts and new user controls. These are usually packaged up as Solutions packages. If you are not using Solution packages in your deployment you should start using them. More information about Solutions and how to create these for a SharePoint release are available in this MSDN article for SharePoint developers here “Windows SharePoint Services solution framework”.

The other changes are made by end users to your SharePoint site. These can be in the form of changes to site templates via the browser and content type changes. To manage this change you should consider having a deployment/build server where you can incorporate all of your code artifacts to do a daily build. In a previous post I mentioned how we deployed a Internet web site using this scenario. The up front time spent in establishing this process will save you time and cost in the long term. Every development or deployment should come up with a similar approach so that you can always ensure your web site or intranet is supported and maintained in the long term.

A recent article has also been published by Microsoft and is available on MSDN which outlines how you can use Visual Studio Team System to manage your builds for the deployment.

Organizations that select Microsoft Office SharePoint Server 2007 to meet the needs of collaboration and Web presentation business solutions often must supplement the built-in functionality of SharePoint Server. These modifications can take the form of feature enhancements and can include development of Web Parts, custom workflows (designed using Microsoft Visual Studio and based on Windows Workflow Foundation), Web controls, and custom list and site templates. Alternatively, other types of modifications can include branding—a process by which the organization changes the visual appearance of the SharePoint Server Web application and implements custom navigation, modified look and feel elements (by using custom master page design and style sheets), and images—and integration with back-end line-of-business (LOB) applications, and implementation of custom workflows designed by using Microsoft Office SharePoint Designer 2007. These two types of development tasks are differentiated by classifying the former as assembly-based development and the latter as artifact-based development; however, the method a single developer uses to approach his or her development is much different from the approach a team takes to collaborate and develop a SharePoint Server solution.

Article: http://msdn.microsoft.com/en-us/library/bb428899.aspx