Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

My team is responsible for maintaining a SharePoint 2010 site that was developed by another group. This maintenance includes updates to existing web parts (approximately 20). Currently, all of these web parts belong to a single feature. A few of these web parts are related and share code, but most are independent.

The problem with this situation is that if I need to deploy a change to one of these web parts, I still have to deploy the other 19. This means that if another developer is currently working on one of these other web parts, I could inadvertently deploy his unfinished code.

I'm looking for suggestions and best practices on how to organize these web parts to facilitate incremental deployments. Should I group related web parts into separate features? Since it appears that you can only have one package per project, should I put the features in separate projects? Or, should keep them in the same project and just change the package contents before doing a deployment?

Thanks for your feedback!

share|improve this question
    
This is actually a great question - I'd love to hear other stories as we're kinda in the same situation ourselves. –  James Love Mar 30 '11 at 18:16
    
I should also mention that interactive debugging has been a huge pain with 20 web parts in the same project since they all have to be compiled and deployed. It takes so long that I rarely do it anymore. Also, when I'm finished debugging all 20 web parts get retracted so I have to remember to do a redeploy. –  SharePoint Wrangler Mar 31 '11 at 20:45
    
Retraction after debugging can be switched off in the SharePoint section of the project properties –  Steve P May 15 '11 at 17:56

5 Answers 5

up vote 10 down vote accepted

I'd avoid branching as it will get very difficult to manage when multiple webparts are under different parts of development. Been there - a messy code handed to me and had to figure out better way to maintain.

This kind of issues crop up due to "type-based" project structure, where all webparts are under "WebParts" project, all features are under "Features" project etc. The alternative is to use "function-based" project structure, where each of your project represents a business function.

In a maintanance mode, the typical enhancements are related to "business function", so it is easy to apply develop individually. Identify and Group your webparts into business function related projects, then you can deploy them individually.

The disadvantages are

a) if you want to change all the webparts [mitigation: use a BaseWebPart class to derive all your webparts, move common code into that] b) You may end up with too many projects - for eg. one per Business Function, you can try to group them smartly and reduce them.

share|improve this answer
    
Good list of disadvantages for "function-based" project structure, which is what I find myself leaning toward. –  SharePoint Wrangler Mar 31 '11 at 20:40
1  
Yeah I think organizing it by function is the way to go and refactor out common code into utility DLLs when possible. –  Kit Menke Apr 5 '11 at 15:51

I would use one SharePoint VS project per web part and one for common codebase such as the base classes.

Then have another 'webparts' SharePoint VS project that is actually just used to bring them all together within one WSP. This was you can update an individual web part and repackage everything without the constraint of possibly pulling in half finished code. This means that you only ever deploy the wsp from this aggregating project but during dev you can just deploy the one wsp for the in progress web part. Which is quicker in my experience.

Things that would need consideration are really around how you manage releases. I would suggest that if developers are responsible for packing up the 'release' code into the production WSP then you may need to revisit the release process. We use TFS to automate the packaging of build to avoid pulling down 'work in progress'. As above people mentioned branching and in my opinion you need to have at least dev and release branches in source control to perform proper ALM process with SharePoint.

If you're attending the Best Practice Conference next week be sure to catch Chris O'Brien's presentation where he'll be demo'ing SharePoint CI with TFS2010 which we use on our project.

share|improve this answer
    
I sure am, but he clashes with Zimmergren's Silverlight awesomeness, might have to wait for the DVDs :) –  James Love Apr 9 '11 at 11:33

All 'related' web parts need to be in the same WSP package. By related I mean those that share a common codebase.

This is because if you retract one WSP that has the shared code in but not the others then the others all fail.

A better solution is to deploy a shared code base as a seperate WSP completely then you can isolate your web parts in to much more manageble solutions.

Also regarding your comment:

This means that if another developer is currently working on one of these other web parts, I could inadvertently deploy his unfinished code.

That is what developer branching is for! Sounds like you have a underlying config management issue too.

share|improve this answer

I asked a similar question a while ago... but didn't really get much input. I'm sure there is much room for improvement in our current process but it seems to work OK.

  • All webparts use separate Visual Studio Projects
  • Utility classes use separate Visual Studio Projects
  • We use a LOT of Visual Studio Solutions. We've only recently started using Solutions with many Projects inside. Some of the solutions use the same projects (ex: the solution for ProductA may use UtilsLibrary as well as the solution for ProductB). We used to only have one project per solution but found it very hard to manage dependencies.
  • One "build" solution that manages all the release artifacts. We still do it the old fashioned way. This helps mitigate the risk of a "broken build" because there is an extra step to move your release DLL into the build. However, this does require more work.
share|improve this answer

Interesting question! I will be in this situation very soon, I'm sure.

I can't think of a clean way of doing this using just Visual Studio and SharePoint's framework of solution files and features.

To me, it appears the solution will lie in using branching in your source control system to keep half-finished work away from releasable code.

share|improve this answer
    
If possible, I'd like to avoid branching because I find that it adds significant complexity to managing source control. –  SharePoint Wrangler Mar 31 '11 at 15:24
1  
Branching - yes it does if using SVN/VSS etc. If using a DVCS then its much much less painful. This tutorial is for Mercurial but the same principles apply to others such as GIT. Having said all that I don't believe that branching is the way to solve this particular problem. –  Ryan Mar 31 '11 at 23:05
    
@Ryan Very interesting sidebar. We're currently using TFS as our source control system, which is not a DVCS. However it does support shelving, which would allow developers to save their code to source control without affecting everyone else. –  SharePoint Wrangler Apr 4 '11 at 13:24
    
"I could inadvertently deploy his unfinished code." means branching to me. Even when reduced to 1 web part per wsp the problem of unfinished changes to that 1 web part from multiple developers will still exist. –  Steve P May 15 '11 at 17:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.