Iterative deployments using WSP in SharePoint2010

Question

I am looking for best practices for deploying frequent custom code changes to SharePoint 2010 server, my changes include all kind of changes like web parts, content types, workflows, feature receivers, pages images and scripts in layouts folder etc. So far what I have found in documentation is that WSP packages are recommended for deployments for SharePoint. I have few questions regarding frequent code changes using WSP packages

1. Do we need to retract a WSP package before installing updated WSP package? What happens to previous code deployment through this package. Do we need to keep all previous changes in wsp package, so that when we retract and remove old version we get all code changes from previous version and new version.

2. Keeping all the code changes in wsp package through various deployments can cause issues in case we have content type and list instances included in the package, how to manage this kind of changes?

3. If we make new wsp packages for each iteration of changes, wont it clog my server with a a lot of wsp packages, one for each code change cycle?

Answer 1

• WSP Packages are indeed the recommended approach to deploy a solution.
• The WSP will contain all the components you mentioned, such as Web Parts, Page Layouts, Master Pages, Workflows, etc.
• The preferred approach to perform updates in an integration environment would be to automate the deployment of the WSP with a PowerShell script that performs the required operations (Add, Install, Uninstall, Remove, etc.)

Answer to the other questions:

1 - It depends.

• If you want to completely update everything with the new version of the WSP, the recommended approach would be to Retract first, and then redeploy.
• If you only want to update the code from your binaries, you can use the Update-SPSolution command from PowerShell.
• I would keep a backup of any major release just in case

2 - It depends on the approach you use to deploy your Fields, Content Types, etc.

• If you are using Declarative approach (i.e. XML) for your definitions, everything is handled automatically by SharePoint when activating the Feature with the Elements.xml files. If this is your scenario, you will have to rely in how SharePoint deals with retraction of used fields and CT's, what properties are updated and which not, etc. In various situations you will need to propagate your changes manually or with a custom PowerShell Script after redeploying the WSP.
• If you are using Programmatic approach (i.e. SharePoint Server Side Object Model) to deploy your Fields, Content Types, etc. then you can control the exact behavior for your updates. Everything will be controlled by your own code on the Feature Receivers, so you can decide what to do if a field already exists, if there were changes in a property, etc. This is generally my preferred approach; note that you will need to probably write more code to cover for the various upgrade scenarios.

3 - If your WSP has the same "identity" (i.e. file name), each deployment will overwrite the previous version, which means that you won't have coexisting installations. This means: no duplicate .dll's (unless you have versioning), no duplicates in 14/15 hive, no duplicates on fields, etc.

Resources

PowerShell basics for deployment: http://technet.microsoft.com/en-us/library/cc262995(v=office.14).aspx

Declarative VS Programmatic: http://www.1stquad.com/sharepoint-kompetenz-erfahrung-know-how/Blog/default/September-2012/SharePoint-Deployment-Declarative-vs-Programmati