26

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!

Improve this question
3
  • 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, 2011 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, 2011 at 20:45
  • Retraction after debugging can be switched off in the SharePoint section of the project properties
    – Steve P
    May 15, 2011 at 17:56

5 Answers 5

Reset to default
15

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.

Improve this answer
2
  • Good list of disadvantages for "function-based" project structure, which is what I find myself leaning toward.
    – SharePoint Wrangler
    Mar 31, 2011 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, 2011 at 15:51
5

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.
Improve this answer
4

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.

Improve this answer
4
  • If possible, I'd like to avoid branching because I find that it adds significant complexity to managing source control.
    – SharePoint Wrangler
    Mar 31, 2011 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, 2011 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, 2011 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, 2011 at 17:54
3

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.

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

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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