Distribuzioni iterativi utilizzando WSP in SharePoint 2010

Question

Sto cercando le migliori pratiche per la distribuzione di frequenti modifiche del codice personalizzato sul server SharePoint 2010, le mie modifiche includono tutti i tipi di modifiche come Web Parts, i tipi di contenuto, i flussi di lavoro, i ricevitori di funzionalità, le immagini e gli script nella cartella Layouts ecc. Finora Quello che ho trovato nella documentazione è che i pacchetti WSP sono raccomandati per le distribuzioni per SharePoint. Ho alcune domande riguardanti frequenti modifiche al codice utilizzando i pacchetti WSP

.

1. Dobbiamo ritrarre un pacchetto WSP prima di installare il pacchetto WSP aggiornato? Cosa succede alla precedente distribuzione del codice attraverso questo pacchetto. Dobbiamo mantenere tutte le precedenti modifiche del pacchetto WSP, in modo che quando ritraggiamo e rimuoviamo la versione antica otteniamo tutte le modifiche del codice dalla versione precedente e la nuova versione.

2. Mantenere tutte le modifiche al codice nel pacchetto WSP tramite varie distribuzioni possono causare problemi nel caso in cui abbiamo il tipo di contenuto e le istanze di elenco incluse nel pacchetto, come gestire questo tipo di modifiche?

3. Se facciamo nuovi pacchetti WSP per ogni iterazione delle modifiche, non osserviamo il mio server con un sacco di pacchetti WSP, uno per ciascun ciclo di modifica del codice?

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