Hello,
We got a request for a total greenfeild enterprice portal for SP2010. The techincal requirements describe 22 dedicaded sites and unique branding. The branding style be the same across all 22 sites.
Every site may contain dedicaded lists and web-parts according to the prescribed functionality, but some featured information blocks should also be delivered onto the main page of the portal or even be embedded into the “mysites” app or user profile pages .
We have five developers and my question is how to share responsibility among all of them and how solutions must be organized.
Does only one developer have to be responsible for building all 22 site templates and provide it as a separate solution and share their guids and urls with the others for customization?
Should the UX developer create the only master page for all 22 sites and delegate some additional styling to every developer individually? Should we assign a developer to work on the main page separately?
Now it is going like this: we cut the Technical Requirements into 22 parts according to the sites described and every developer is working with several parts of the TR. But the problem is that some web parts and information from libraries have to be used across different sites and it comes out that nobody is responsible for that. And we have 5 solutions to deploy as many as the number of our developers.
So if you have any experience your recomendations will be appreciated.
Thanks.
In my experience it makes most sense to divide the solutions based on the type of content, not based on functionality or even by developer.
My solutions usually contain following SharePoint projects
- Branding
This project contains all the UI related files, primarily images and css. This is the project where the UI/UX developer is mostly working. Usually it should not contain any line of .net code which means that it has no assembly to be deployed. - Presentation
This project contains webparts, masterpages, application pages, control templates etc. These are primarily components which might be used in several places of the solution. the project has an obvious dependency to the branding project. - Definition
This project contains content types, site columns, field types, list definitions, site definitions and web templates. It has a dependency to the presentation and the branding project - Core
This is a project which contains usually only an assembly which provides core functionality which other projects use. Think of it as a utility library or the business logic class. In most cases it should not contain any SharePoint artifacts. The only exception could be if you have JavaScript files which also act as utility class. - Resources
This project contains all language resource files used in the other projects. Putting it into a separate project makes it easier to translate and easier to organize the resources for the whole solution. - Others
There are more projects I use, based on the type of solution, i.e. one for workflows.
As you already might imagine dividing it up like that may cause problems among the developers who work in the same project. Primarily that happens when files are added or removed as this requires to update the csproj file. But I assume that you are using some kind of source control which helps you handle the merges if required.
The advantage of structuring all projects like that is that every developer knows where he can find which artifact, no matter which solution it is. So if you need to break out a module, functionality or whatever in to an own solution, I would use the same structure again.
Having multiple WSPs for one solution requires also some standardized way of solution deployment, which allows to check for prerequisite solutions.
I created such deployment scripts and made them available on CodePlex, so if you are interested just check out the “SharePoint Solution Deployer” at spsd.codeplex.com
I am also having a “SPChat” session about SPSD next week on May,16th 2013 here in the main chat room. So just join there if you have any questions about it.
