A while back I wrote a post called SharePoint 2010 Development Environment where I outlined my basic recommendations for getting a developer up and running building custom SharePoint solutions. Since that time I have received a few direct messages and comments on that post asking if I could expand upon the original article and get a bit deeper into team development.

The very first and most important concept that I didn’t mention in the previous post is that all custom development for SharePoint should be packaged as a SharePoint solution.  You should never deploy customizations to SharePoint by copying source files to locations on the SharePoint server’s file system.  This includes image files, custom web services, and web.config modifications. You must learn what a solution file is and how to create one before you can be successful in building customizations or branding for SharePoint.

There are two different types of SharePoint solutions that can be built; farm solutions and sandboxed solutions. My recommendation is to always build sandboxed solutions if possible. Sandboxed solutions provide protection against misbehaving code and also allows Site Collection owners to deploy the solutions.  Sandboxed solutions are also  the only type of solution allowed to be deployed in SharePoint Online.

In some cases the type of customization you wish to make to an on-premises SharePoint deployment can only be accomplished with a farm solution. In those situations you will want to test, test and re-test all of your code in the solution prior to deployment.  A simple mistake in a farm solution has the potential to impact the stability of the full SharePoint farm.

In the original article I made some recommendations for a developer environment and they still are valid today. The developers should all have a 64 bit Windows 7 computer with at least 4GB of RAM (8GB recommended).  On that computer you will install SharePoint Foundation 2010, Visual Studio 2010 and SharePoint Designer 2010.   Each developer, including graphic designers, should have this exact same build.   Now, in some cases you may need to install the Standard or Enterprise version of SharePoint if your solution requires APIs that are not available in Foundation.

I also recommended the use of Team Foundation server for managing source code and for tracking work items, bugs and issues.  If you choose not to use Team Foundation server you will need at least some sort of shared source control system that integrates well with Visual Studio.  If it doesn’t integrate with Visual Studio then you are just greatly reducing the productivity of your developers. 

A good shared source control system is key for any successful team development project!

The lead developer should be responsible for setting up the project structure and ensuring that every person on the development team, including graphic designers, are all working out of the same shared source control system.  The team development process should occur just like any other .NET development effort.

One big hang-up I think happens when people start building up SharePoint development skills is figuring out how to do the Dev to Test to Production move when working with SharePoint in a team environment. The first thing is to ensure that every developer is working in their own completely isolated development environment (hence the reason for separate Windows 7 development systems).  This is important so that developers are not stepping on each other while trying to debug their code. Having developers share a single SharePoint environment will lead to frustration and potential mistakes.

When it comes time to test the full solution, the lead developer (or test lead) will get the latest source code for the project from Team Foundation Server (or whatever source control system you are using) and do a build.  That build will generate a SharePoint solution package that will then be copied to the SharePoint test farm and deployed.  The testers can then proceed to take the necessary actions to verify that the custom solution is working as intended.  Any bugs or issues can be logged and sent back to the developers.

Developers may wish to do basic integration testing from time to time.  At any time the developers are able to retrieve the latest code from source control so they can do a quick integration test on their local dev machines prior to the real test process on the SharePoint test farm.

Another key concept that must be understood is that there is a big difference between content and customizations (or code).  Customizations, or better known as SharePoint solutions, should go through a dev, test and then production process just like any other development project. Content should not. Content should be built in the production environment and possibly follow an approval workflow process in that environment.  Think of content as any list, library, images, text, documents or other data that is not directly used by your custom solution.

Everything isn’t just black and white.  There are times when content should be deployed as part of a solution.  Usually this content will be Office document templates, images, or other files that are in direct support of the solution itself.  A good example of a solution with built in content is the Productivity Hub.  A good rule is that if the content will be created, edited or maintained by a SharePoint content editor then you should probably not include the content as part of a SharePoint solution.  You should also not include that content as part of a dev, test, production deployment cycle.

Document libraries and lists may not be considered just content if your solution directly relies on those items. For example, your solution may use a custom SharePoint list for storing information.  In this case, the list is not just content but a required part of your solution. You will need to ensure that your custom solution has a way to automatically provision that list when the solution package is installed and activated.  Never rely on a person to manually create supporting content as part of your solution install process.

SharePoint Designer is a great tool to assist in the development process. Keep in mind that when you use SharePoint Designer you are just creating content. Using SharePoint Designer to modify a master page or to create a workflow process is just creating content within a SharePoint site collection.  You should always copy or export the work you do in SharePoint Designer and place it into your Visual Studio project so that it is packaged as part of your SharePoint solution.  Remember that by having the customizations in a SharePoint solution package you can easily deploy it to other SharePoint farms.  Solution packages are reusable, content generally is not.

You might be wondering, if I build all of my content in my production site, how will I ever use that in my test or dev environments?  You will do site collection backups of the portion of your production site you need to work with in the test and dev environment and then restore it into the appropriate environment.   I usually look at it like this:  solutions move from dev to test to production.  Content moves from production to test and dev.

To wrap up, below are a few tips that I feel make SharePoint Development a bit easier:

  • Always use Visual Studio 2010 to build custom SharePoint solutions.
  • Always use a shared source control system.  I recommend Team Foundation Server.
  • Never share a development environment with multiple developers. Shared development environments can cause issues which will greatly reduce the productivity of the developers.
  • Never manually deploy files to SharePoint servers; always deploy your customizations using a solution package.
  • SharePoint Designer just creates content. If you use SharePoint Designer, think about how it will impact your ability to deploy your solution.
  • Don’t break your development efforts up into a bunch of little Visual Studio projects unless it makes good sense.  One solution package is easier to manage and deploy than several.
  • Content should always be created where it will live. Don’t try to run content through the dev, test, and production deployment cycle.
  • Use the shared test environment to ensure that all of the solutions you build work properly and integrate well with each other.
  • Copy site collections from the production to the test server if you need that content to test your custom solutions.
  • Limit the number of people who have the ability to deploy a custom solution build to the test farm. 
  • Content is not code, don’t try to manage it the same way.
  • Branding should always be placed in a SharePoint solution package so it can be reused.

Do you have your own tips for SharePoint team development?  Let us know in the comments section below!