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

We are a group of ASP.NET developers who are new to SharePoint and we are starting fresh from SP 2010 with no prior experience with 2007. I am trying to figure out how to implement the SW development processes that we are so used to for SharePoint development. One big question I have involves whether or not creating separate Visual Studio solutions for each new requirement that needs customization. We are going to use VS2010, TFS for source code control and work item tracking; we will have developer VMs, Integration server, Staging server and the Production server. I am trying to figure out where the code labeling and branching practices will fit into this new picture. We want to be able to save the releases in TFS in the form of branches as we always did. For the regular ASP.NET development, we labeled the code for each QA release, then we branched the code before each Production release. Any help is greatly appreciated.

share|improve this question

1 Answer 1

I don't see why your source control and release process need to change, now that you are doing SharePoint development. These are good practices that you should continue to use.

The only thing that might constrain you is how you structure your VS solutions or projects. I would not recommend creating a VS solution for each requirement in any case - I think these should be chunked according to functionality or architecture. This may be more of an issue than before because you will be wanting to package your SharePoint artefacts and code as features within solution packages (solution in the SharePoint meaning of the word). This will be a lot easier if you keep this together within a VS project. Think of the SharePoint solution package as being equivalent to a Windows Installer package for client systems, but targetting the SharePoint farm.

Think carefully about how much you put into each solution package (which will probably correspond to a VS project) and into each feature. Avoid too many separate solution packages, or the other extreme of one monolithic solution package.

Some useful links on MSDN: Setting Up the Development Environment for SharePoint 2010: http://msdn.microsoft.com/en-us/library/ee554869.aspx Packaging and deployment: http://msdn.microsoft.com/en-us/library/ee539979.aspx ALM: http://msdn.microsoft.com/en-us/sharepoint/ff420387.aspx#lesson2 Get Started Developing on SharePoint 2010: http://msdn.microsoft.com/en-us/sharepoint/ee513147.aspx General advanced dev. training: http://msdn.microsoft.com/en-us/sharepoint/ff420377.aspx

share|improve this answer
    
Good answer, SPDoctor. Engin, you are on the right track. Chris O'Brien gave some good advice on how to organize features here: sharepointoverflow.com/questions/3084/… –  Rob Wilson Jan 20 '11 at 21:13
    
+1 very well written! –  Falak Mahmood Jan 20 '11 at 22:06

Your Answer

 
discard

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