SharePoint Solution Deployment Strategies – Dare I say Best Practices?

June 12, 2009 Mark Rackley Uncategorized 0

Originally posted on: http://geekswithblogs.net/SoYouKnow/archive/2009/06/12/sharepoint-solution-deployment-strategies-ndash-dare-i-say-best-practices.aspx

 

Application deployment in SharePoint is a broad topic with many options. It is extremely important to set standards in your organization for application deployment in SharePoint that are straightforward and reproducible in order to make deployment successful and repeatable. A proper deployment also lends itself to ease of maintenance of deployed applications. After giving the issue a lot of thought, research, and talking to people who know more than me, I decided to detail recommended strategies for deploying various applications into a production SharePoint environment.

So, why bother?

The objective for setting forth deployment standards in your organization is to provide guidance to developers and administrators and set expectations about SharePoint Deployment. Some Key objectives:

  • · Set realistic expectations – SharePoint application deployment is never a one-step process. You can’t just copy files over and be done with it.
  • · Document the process – Because multiple steps are involved in a SharePoint deployment it is important to document the deployment steps in a way that is understandable to both developers and administrators.
  • · Package where possible – Part of a successful and repeatable deployment strategy is to create packages where possible that can be deployed instead of manually creating items as part of the deployment process.
  • · Improve upon the process – As your organization becomes more adept at SharePoint application deployment you will be able to streamline the process allowing deployments to take place in fewer steps.

What steps might I take during a deployment?

There are multiple steps that may or may not take place when deploying an application in SharePoint. The following table details many of the various steps.

Step #

Description

Details

1

Create Web Application

In Central Admin or STSADM

2

Create Site Collection

In Central Admin or STSADM

3

Extend Site Collection

In Central Admin or STSADM

4

Deploy Themes

STSADM command with WSP file

5

Deploy MasterPages

STSADM command with WSP file

6

Deploy Custom Web Parts

STSADM command with WSP file

7

Upload Site Template

in SharePoint Site Collection

8

Create Site Using Site Template or Create Blank Site

in SharePoint Site Collection

9

Create or Deploy Lists / Libraries

In newly created site. Ideally lists will be deployable WSP files or part of site template, but may need to be manually created in some instances

10

Publish InfoPath Forms

In Central Admin if Admin approved, otherwise just publish to forms library

11

Deploy Custom Workflows

STSADM command with WSP file

12

Build Pages using created lists and deployed web parts

As time goes on, these pages will be part of deployable packages or part of the site templates. To start off though they may need to be put together manually.

13

Set Up Security Groups

in SharePoint Site

14

Configure navigation for accessing newly created site accordingly

This could involve modifying an XML file or modifying Navigation in SharePoint or even a third party solution

 

There are many options when it comes to SharePoint Application Deployment. Unfortunately, many of the options are not great and end up being “Developing in Production”.

The most common SharePoint Deployment strategies involve using SharePoint Designer and publishing SharePoint sites with SharePoint Designer. This may work fine for smaller implementations and indeed seems ideal for an initial deployment, however many problems emerge when maintenance has to be done on an application deployed using SharePoint Designer. Among these problems:

  • · Any sort of republish of a site with SPD overwrites list data
  • · Modifications have to either be done in production or on a copy of the site.
  • · If changes are made on a copy of the site, newer data will be lost when the changes are republished.
  • · SPD Workflows cannot easily be modified in Development environment and individually redeployed.
  • · Using SPD to maintain pages breaks SharePoint’s “ghosting” feature.
  • · Using SPD on a production server is equivalent to “developing in production” and can bring down a site if a mistake is made.

So, how should your organization handle SharePoint Application Deployments? A recent conversation with a SharePoint guru indicated that if 50% of your application deployment was made up of deployable packages then you would be ahead of 90% of the companies using SharePoint. I think 50% is an achievable goal and most organizations should endeavor to reach it.

An ideal SharePoint deployment would be 100% deployable packages and the only steps a SharePoint administrator would have to do are:

  1. 1. Deploy Features
  2. 2. Create Site
  3. 3. Configure Security

Although ideal, this option is generally not realistic with the maturity of the SharePoint team of most organizations and in some cases is overkill (i.e. if it would take much longer to create everything as deployable packages than to just put the parts together manually). As SharePoint developers gain more experience and develop a set of internal templates they use daily, this ideal scenario becomes more plausible.

Deployment Types with Sample Deployment Scripts:

When creating deployment scripts for your SharePoint application it is important to note that not every deployment script will be the same. Steps in a deployment script can vary widely based upon a number of factors. It is not realistic to attempt to create one deployment script template that will be the basis for all deployments. Things that can affect deployment scripts:

  • · Logical placement of application in production
  • · Size of application
  • · Customization level of application
  • · Number and types of features to deploy
  • · Security (AD, FBA, Anonymous, etc)

That being said, deployment scripts can be expected to fall into one of three main types. These types are described in detail below.

No Custom Development or No Template Deployments

Some sites may have no customizations, templates, or deployable packages. This means that all of the functionality for the deployed sites would need to be re-created in the production environment. Although at first glance this may seem pretty severe, it is the most common SharePoint Deployment strategy and builds upon one of the Strengths of SharePoint (rapid application development and deployment). Problems arise, however, when these applications must be modified or maintained. All changes have to be done in production or on a backup of the site which can cause data to be lost when the backup is restored into production. Again, maintenance may not be an issue for more simple sites as changes may also be kept simple. SharePoint Designer Deployments also fall into this category. Reasons for having no custom development or templates include:

  • · Lack of experience of development team (don’t know how to create package “x”)
  • · Time to create deployable packages is much greater than just building the site with a good deployment script
  • · Site is based upon an existing template already in production (i.e. Team Site)
  • · Site was designed and developed in SharePoint Designer

Below is an example Deployment Script for a site with no custom development or templates.

Step

Description

1

Upload the Site Template “x.STP” to the site collection http://url.com/path/sitcol

2

Create a new site called “Site Name” under the Site http://url.com/path/sitcol using the template uploaded in Step 1

3

Upload data connection files in Central Administration
 
  • – Give location of files (drive or attached to script)
  • – Click on ‘Manage Data Connection Files’ under Application Management in Central Admin.
  • – Upload data connection files.
  • – Specify the correct category when uploading the files.

4

Install the form template in Central Administration.
 
  • – Click on ‘Upload form template’ under Application Management in Central Admin.
  • – Give location for form

5

Activate the form template to the appropriate site collection

6

Set up security groups in Active Directory (this assumes you are handling users security in AD and only specifying AD groups in SharePoint, not a bad idea for maintenance)

7

Set up permissions for site using groups created in Step 6

 

Mixed Deployments

A “mixed” deployment script contains non-customized items and customized deployable packages. At first glance the no custom deployment process may seem more desirable; however with this deployment script you get the advantage of maintainability around your workflows. The workflows deployed in the following script may be modified and redeployed to the site without affecting the rest of the site. This gets us closer to our goal of having all modifications occur in a development environment, tested in a QA environment, and then deployed in production. The reasons for a “mixed” deployment:

  • · Lack of experience of development team (don’t know how to create package “x”)
  • · Time to create deployable packages is much greater than just building the site with a good deployment script
  • · Site is based upon an existing template already in production (i.e. Team Site)
  • · Site was designed and developed in SharePoint Designer

The following steps are approximate steps that would need to take place to deploy the same application as the previous script using a mixed deployment scenario.

Step

Description

1

Upload the Site Template “x.STP” to the site collection http://url.com/path/sitcol

2

Create a new site called “Site Name” under the Site http://url.com/path/sitcol using the template uploaded in Step 1

3

Upload data connection files in Central Administration
 
  • – Give location of files (drive or attached to script)
  • – Click on ‘Manage Data Connection Files’ under Application Management in Central Admin.
  • – Upload data connection files.
  • – Specify the correct category when uploading the files.

4

Install the form template in Central Administration.
 
  • – Click on ‘Upload form template’ under Application Management in Central Admin.
  • – Give location for form

5

Activate the form template to the appropriate site collection

6

Install the workflow solution package
 
  • – Give location of workflow.wsp file(s)
  • – Open a command prompt and navigate to 12 hive:  c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin
  • – Enter the following command: stsadm –o addsolution –filename <name of wsp file>

7

Deploy the workflow package from Central Administration – Operations – Solution Management

8

Go to Site Collection Features to activate the solution package (name of workflow)

9

Associate the workflows with the correct list/library
 
  • – From Library/List Settings, select Workflow Settings
  • – Click Add a workflow
  • – Select ‘name of workflow’ from the list
  • – Type in name of the workflow
  • – Set this workflow to be manually started by an authenticated user with Edit Items Permissions, click ok
  • OR
  • – Set this workflow to be started when a new item is created (make sure to remove the checkbox from Allow this workflow to be manually started by an authenticated user with Edit Items Permissions, click ok
  • OR
  • – Set this workflow to be started when a new item is modified(make sure to remove the checkbox from Allow this workflow to be manually started by an authenticated user with Edit Items Permissions, click ok

10

Set up security groups in Active Directory

11

Set up permissions for site using groups created in Step 10

 

Custom Development Deployments

In an ideal world every aspect of deploying a site would be done with packages. The packages would be deployed to an appropriate location and the site created. As stated earlier, if you get 50% of your deployment to be packages you are ahead of 90% of the companies out there, so having deployments that are entirely package based may not be attainable, but should be strived for none the less.

Below is a deployment script for the same application deployed in the previous scripts but is entirely made up of packages. Steps 1,2, and 3 are the main difference between the previous script. The Site Definition will be created as a deployable package adding another level of maintainability from previous deployment script.

Step

Description

1

Deploy the Site Definition “x.WSP” to the site collection http://url.com/path/sitcol

2

Create a new site called “Site Name” under the Site http://url.com/path/sitcol using the site definition deployed in Step 1

3

Deploy data connection files (thanks to Corey Roth for showing how to do this:)

4

Install the form template in Central Administration.
 
  • – Click on ‘Upload form template’ under Application Management in Central Admin.
  • – Give location for form

5

Activate the form template to the appropriate site collection

6

Install the workflow solution package
 
  • – Give location of workflow.wsp file(s)
  • – Open a command prompt and navigate to 12 hive:  c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin
  • – Enter the following command: stsadm –o addsolution –filename <name of wsp file>

7

Deploy the workflow package from Central Administration – Operations – Solution Management

8

Go to Site Collection Features to activate the solution package (name of workflow)

9

Associate the workflows with the correct list/library
 
  • – From Library/List Settings, select Workflow Settings
  • – Click Add a workflow
  • – Select ‘name of workflow’ from the list
  • – Type in name of the workflow
  • – Set this workflow to be manually started by an authenticated user with Edit Items Permissions, click ok
  • OR
  • – Set this workflow to be started when a new item is created (make sure to remove the checkbox from Allow this workflow to be manually started by an authenticated user with Edit Items Permissions, click ok
  • OR
  • – Set this workflow to be started when a new item is modified(make sure to remove the checkbox from Allow this workflow to be manually started by an authenticated user with Edit Items Permissions, click ok

10

Set up security groups in Active Directory

11

Set up permissions for site using groups created in Step 10

 

Caveat

One important note when creating deployable packages.  You’ll notice in that last script that the workflows were still separate packages to be deployed and not part of the same feature as the site definition.  This is important from a maintenance standpoint.  If you stick everything in one package it makes incremental updates on each web part, work flow, etc… more cumbersome.  So, don’t stick everything in one feature.  Make them dependent features instead.  You’ll thank me later.

Some important things to have in place before you begin

So, you are about to go and set up your deployment standards for your organization.  Here are a couple of things you need to have in place first:

  • · A well defined taxonomy needs to be in place before rigid deployment standards are enforced
  • · A back-out strategy in case an application needs to be un-deployed
  • · A maintenance strategy for future modifications to application
  • · Whoever is deploying the applications into production needs to be competent in SharePoint’s ins and outs and should not need handholding.

Also, some things you need to decide internally within your organization:

  • · What is the threshold for creating a package versus manually creating objects in SharePoint?
  • · What person / group is responsible for deploying applications?

Conclusion

These scripts are not meant to be the end of the conversation.  They can be improved upon for even more automation.  This is just to help get you started and help you understand what application deployment means in SharePoint.  Hopefully you learned something you didn’t know or maybe even had an “ah-ha!” moment.

Families in Germany who are facing divers health problem, such persons can buy drugs from the Web without prescription. With the market flooded with divers web-sites selling sundry medicaments, purchasing medicines from th WEB is no longer a trouble for common man. Certain medications are used to treat infections caused by dental abscesses. Of course it isn’t all. If you’re concerned about erectile soundness problem, you probably know about Xenical and Hoodia. Probably either adult knows about Garcinia. (Read more PhentermineXenical). The symptoms of sexual health problems in men include improbability to have an hard-on sufficient for sexual functioning. Certain medications may add to sex drive difficulties, so its vital to cooperate with your soundness care professional so that the prescription can be tailored to your needs. Preparatory to taking Levitra or other medicament, speak to your pharmacist if you have any allergies. Talk to your soundness care provider for more details. Preparatory to ordering this remedy, tell your doc if you are allergic to anything.