SharePoint Deployment Standards
Back To All SharePoint Standards
SharePoint provides a great deal of functionality and capabilities to business users through Out of the Box (OOTB) components and browser based configuration. It is a general best practice to rely on these components wherever possible to mitigate risk introduced to the platform through custom code (performance, upgrade, support). However, custom code may become a requirement to achieve business objectives and can often result in high value returns through deployment to the SharePoint platform.
This set of Standards is still being defined.
- Word (Docx) Version: SharePoint Test Plan
- Word (Docx) Version: Deployment and Customization Policy
What follows are SharePoint Deployment Standards. Many of these relate to SharePoint Development Standards.
General:
- In SharePoint 2007 STP files are not allowed as they are not updatable.
- All custom SharePoint work should be deployed through SharePoint Solution (.wsp) files.
- No files should ever be directly deployed into SharePointRoot (12-Hive, 14-Hive) Folders. Instead they must be deployed into a folder identified by Project Name.
Documentation:
- Provide an Installation Guide which contains the following items:
- Solution name and version number.
- Targeted environments for installation.
- Software and hardware Prerequisites: explicitly describes what is all needed updates, activities, configurations, packages, etc. that should be installed or performed before the package installation.
- Deployment steps: Detailed steps to deploy or retract the package.
- Deployment validation: How to validate that the package is deployed successfully.
- Describe all impacted scopes in the deployment environment and the type of impact.
- All custom SharePoint work should be deployed through SharePoint Solution (.wsp) files.
- Do not deploy directly into SharePointRoot (12-Hive, 14-Hive) Folders. Instead deploy into a folder identified by Project Name.
InfoPath:
- If an InfoPath Form has a code behind file or requires full trust then it must be packaged as a solution and deployed through Central Administration.
- If an InfoPath form does not have code behind and does not need full trust the form can be manually published to a document library, but the process and location of the document library must be documented inside the form.
- Just add the documentation text into a section control at the top of the form and set conditional formatting on that section to always hide the section, that way users will never see it.
Process
- All customizations and custom code will go through our review and release cycle.
Example of Review and Release Cycle:
Are some missing? Let me know via the comments section,
Richard Harbridge
{ 1 trackback }
{ 4 comments… read them below or add one }
With infopath I would say that it depends on the organization. Since endusers don’t create InfoPath forms all forms, regardless of whether they require full trust or not are packaged as features and follow the regular deployment process.
All data connections are centrally managed udcx files as well in order to make the deployment from one environment to the other seamless.
I totally understand where you are coming from Jason.
In a centralized scenario where end users don’t create InfoPath forms that approach definitely works and I could see that being a viable standard.
On the point described here: “Since endusers don’t create InfoPath forms” I agree that it depends on the organization. In many organizations I have worked with end users (as in non IT staff) actually do build InfoPath forms. In one organization in fact we had an entire community (a knowledge sharing one) around building InfoPath forms that was organized not by IT but by various passionate individuals in other business units.
So I am not sure I understand or fully agree with the above standard. I might be missing something so please feel free to share further thoughts on it.
In terms of data connections I agree UDCX should be used… centrally managed I am not sure I agree to… what’s the reasoning behind the central management of UDCX in your opinion? I can see pro’s and con’s depending on the organization. Similar to what was mentioned above.
UDCX files in Central Admin is useless. The UDCX (in both 2007 and 2010) have GUIDS for the lists they have connectivity with (lookups etc.) as well as the library where the forms are saved or submitted to. It’s best to use UDCX files in document library on the site where you’re deploying the form to. While you still have to manually edit the UDCX file when moving from environment to environment, at least you can do it isolated in the site. In Central Admin, there is only one UDCX file so you’re forced to create a .dev, .test, and .prod UDCX file.
Gotcha and that makes sense. Anything else to add? Would love your help refining this and the Dev standards Bil. 🙂
Still haven’t gotten many updates/feedback on 2010 Dev standards either from the people I have asked.