1. Application Lifecycle Management Overview
   

Application Lifecycle Management (ALM) is the coordination of all aspects of software engineering — including the formulation and communication of business and technical requirements, code design and architecture, project tracking, change management, coding, testing, debugging, and release management — by using tools that facilitate and track collaboration among and within work teams.

SharePoint 2010 offers significant enhancements to in the ALM space through the use of feature versioning, a more robust feature schema, the ability to push down upgrades to existing feature instances and

Visual Studio 2010 natively understands SharePoint development and thus provides a significantly improved toolset for the development of applications for SharePoint. Projects are compiled into a Windows SharePoint Package (WSP) file that can then be deployed in a repeatable manner through the various environments. Many aspects of the creation of these features is handled by Visual Studio thereby increasing the productivity of the developers.

1. Provisioning with Solution/Feature XML versus Code
   

SharePoint applications and customizations are typically built and deployed using the Feature Framework. This enables repeatable deployments from one environment to another and allows modules of functionality to be deployed to different scopes within SharePoint (provisioning).

Artifacts in SharePoint are typically divided into 2 main categories

• Declarative Artifacts — Declarative artifacts are elements that are defined in a physical file somewhere in the SharePoint root. Frequently, these artifacts are used as definitions or templates that are used when new instances of the artifact are provisioned. Examples of declarative artifacts include site definitions, list definitions, and custom actions.
  

   

• Provisioned artifacts — Provisioned artifacts are elements that exist inside a Content Database. Typically, they can be created through Feature XML, code, or other means such as the SharePoint UI itself. Examples of provisioned artifacts include content types, list instances, and fields. (O’Brien, Real World SharePoint 2010, 2011)

   

Pros & Cons of Declarative Provisioning with XML

1. Upgrading a SharePoint 2010 Application
   

A significant improvement in the SharePoint 2010 ALM is support for feature versioning. This allows for much cleaner upgrade process than WSS 3.0 offered. In order to support this new Feature schema elements have been defined.

Microsoft has added some new XML to the Features framework to support Feature upgrade. When a new version of a Feature is created, this may involve:

• Incrementing the version number of an existing Feature (this is mandatory for Feature upgrade to happen)
• Adding some new XML to define new items for the Feature
• Writing some code to execute in the new FeatureUpgrading event in the Feature receiver
• All of the above

Feature upgrade is useful in the following scenarios:

• To make changes to existing site collections or sites, or something inside – for example:
  • Making changes to existing items e.g. adding a new column to a content type/list
  • Adding new elements to existing sites e.g. a new list
  • Any change which involves doing something to a site using the API e.g. using code to modify the navigation settings for many sites
• To add new functionality into an existing Feature, rather than create a new one – perhaps because that’s the most logical factoring
• Where some functionality will be upgraded several times during its lifecycle, possibly in a situation where the changes are not rolled out to every site, or are rolled out at different times (O’Brien, Feature Upgrade Fundamentals)

The following table details the schema enhancements along with a description

A sample of this new schema can be found below:

<?xml
version=”1.0″
encoding=”utf-8″ ?>

<Feature
xmlns=”http://schemas.microsoft.com/sharepoint/”
Version=”1.0.0.0″>

<UpgradeActions>

<VersionRange
BeginVersion=”0.0.0.0″
EndVersion=”0.9.9.9″>

<ApplyElementManifests>

<ElementManifest
Location=”SomeFunctionality_Iteration2\Elements.xml”
/>

</ApplyElementManifests>

<AddContentTypeField
ContentTypeId=”0x010073f25e2ac37846bb8e884770fb7307c7″

FieldId=”{536DC46C-DC26-4DB0-A97C-7C21E4362A85}”
PushDown=”TRUE”/>

<AddContentTypeField
ContentTypeId=”0x010073f25e2ac37846bb8e884770fb7307c7″

FieldId=”{4E7A6719-011A-47EA-B983-A4941D688CA6}”
PushDown=”TRUE”/>

<CustomUpgradeAction
Name=”UpdateSomething”>

<Parameters>

<Parameter
Name=”PassSomeValue”>This is a string</Parameter>

</Parameters>

</CustomUpgradeAction>

</VersionRange>

</Feature>

The following code will handle the FeatureUpgrading event and the handling of parameters defined in the Feature.xml file above.

public
						override
								void FeatureUpgrading(SPFeatureReceiverProperties properties, string upgradeActionName, System.Collections.Generic.IDictionary<string, string> parameters)

{

    SPWeb parentWeb = (SPWeb)properties.Feature.Parent;

					switch (upgradeActionName)

    {

					case
							"UpdateSomething":

					string someValue = parameters["PassSomeValue"];

					// do some stuff.. 
						

					break;

					default:

					break;

    }

}

1. Upgrading SharePoint 2010 Features – Walkthrough
   

This section describes at a high level how you can put these feature-versioning and upgrading capabilities to work. When you create a new version of a feature that is already deployed on a large SharePoint 2010 farm, you must consider two different scenarios: what happens when the feature is activated on a new site and what happens on sites where the feature already exists. When you add new content to the feature, you must first update all of the existing definitions and include instructions for upgrading the feature where it is already deployed.

For example, perhaps you have developed a content type to which you must add a custom site column named City. You do this in the following way:

1. Add a new element file to the feature. This element file defines the new site column and modifies the Feature.xml file to include the element file.
   
2. Update the existing definition of the content type in the existing feature element file. This update will apply to all sites where the feature is newly deployed and activated.
   
3. Define the required upgrade actions for the existing sites. In this case, you must ensure that the newly added element file for the additional site column is deployed and that the new site column is associated with the existing content types. To achieve these two objectives, you add the ApplyFeatureManifests and the AddContentTypeField upgrade actions to your Feature.xml file.
   

When you deploy the new version of the feature to existing sites and upgrade it, the upgrade actions are applied to sites one by one. If you have defined custom upgrade actions, the FeatureUpgrading method will be called as many times as there are instances of the feature activated in your site collection or farm. (Juvonen, 2011)

Consider the following scenario as well:

• A Web-scoped CustomFeature.wsp v1.0.0.0 is deployed and activated on Site Collection containing Site A and Site B. An instance of the feature is created on Site A
  
• New functionality is required and CustomFeature.wsp v2.0.0.0 is created and deployed. A new instance is created on Site B resulting in v2.0.0.0 being instantiated. However the previous instance in Site A is still at v1.0.0.0
  
• You must explicitly upgrade existing instances of the feature using the SharePoint Feature Upgrade Kit and/or the associated PowerShell cmdlets.
  
• In a scenario like this you must ensure to handle both the new activation and feature upgrade process. This is discussed elsewhere in this document.
  

1. Important Points
   

• Feature upgrade does NOT happen automatically (including when the Feature is deactivated/reactivated)!  The standardized Central Admin and/or associated PowerShell cmdlets must be used to upgrade existing instances
• On the VersionRange element, BeginVersion is inclusive but EndVersion is not. In other words, a Feature instance will be upgraded if the current version number is equal to or greater than BeginVersion , and less than  EndVersion.
• Upgrade instructions are executed in the order they are defined in the file.
• If a Feature does not have a Version attribute, the version is 0.0.0.0.
• Enabling logging can help diagnose any issues. In the ULS settings, under the ‘SharePoint Foundation’ category, set the following sub-categories to Verbose to see more info:
  • Feature Infrastructure
  • Fields
  • General (O’Brien, Feature Upgrade Fundamentals)

Features are upgraded in the following order: first at the server farm level, next at the Web application level, then site collection, and finally, at specific Web sites. At the Web site level, Feature instances are upgraded starting with root Web sites and progressing downward through the hierarchy of child Web sites. Features are upgraded based on the order of dependency, that is, dependent Features are upgraded after the Features that they depend upon.

1. SharePoint 2010 ALM Standards
   

   1. Solution Packaging Standards
      

• Feature packaging model will be designed as early in the project as possible
• Features targeting different scopes must be developed in separate solution packages necessitating a separate Visual Studio Package
• Feature packaging decisions will be made on a per project basis but will consider the following factors
  • How functionality is related to each other. Unrelated functionality may be packaged into separate features to provide increased granularity around deployments.
  • Project phasing requirements
• Activation dependencies should be used to ensure proper deployments

1. Feature and Assembly Versioning Standards
   

Assembly Versioning Number Standards

Feature Versioning Standards

Some further guidelines on Feature Versioning are below:

• Increase the version number when you update a Feature and, if needed, add corresponding Feature upgrade logic. Even if you do not have to add Feature upgrade logic, you should still increase the version number so there is a way to distinguish what versions of the Feature are deployed across a server farm.
• Keep version numbers of your Feature independent from Microsoft product versions. For example, instead of starting with 14.0.0.0 as the version number, start with 1.0.0.0 and increment subsequent versions appropriately, for example, 2.0.0.0, 2.1.0.0, and so on.

1. Development Standards
   

   1. Development Environment Deployments
      

• New Features: they can be deployed using the Deploy command in Visual Studio. This will perform a Deactivate – Retract – Remove – Add – Deploy Activate Operation
• Upgrades: versioned upgrades to features should not be deployed in this manner. The solution should be packaged and the appropriate PowerShell commands should be used to upgrade the feature. This will more realistically simulate deployment to other environments.

The standard for managing the feature upgrade process will be to use the Open Source SharePoint Feature Upgrade kit available at http://spfeatureupgrade.codeplex.com/. This extends Central Administration to provide this functionality as well as includes PowerShell cmdlets to facilitate the process. More explanation is provided here: http://www.sharepointnutsandbolts.com/search?q=cmdlet

1. Feature Activation
   

Do not instantiate an SPWeb, SPSite, SPList, or SPListItem object within an event receiver. Event receivers that instantiate these objects instead of using the instances passed via the event properties can cause the following issues:

• Significant additional roundtrips to the database (one write operation can result in up to five additional roundtrips in each event receiver).
• Calls to the Update method on these instances can cause subsequent Update calls in other registered event receivers to fail.

1. Code Design
   

This section is not intended to be a comprehensive listing of TGT’s software development best practices but rather an outline of SharePoint specific code design standards related to the SharePoint ALM

To provide more flexibility for your code, you should not place your upgrade code directly inside the FeatureUpgrading event receiver. Instead, put the code in some centralized location and refer to it inside the event receiver

By placing your upgrade code inside a centralized utility class, you increase both the reusability and the testability of your code, because you can perform the same actions in multiple locations. You should also try to design your custom upgrade actions as generically as possible, using parameters to make them applicable to specific upgrade scenarios. (Juvonen, 2011)

1. Upgrade Process Standards
   

When a feature has previously been deployed to a non-development environment (SIT, QA, PROD) it must be versioned and upgraded appropriately. The following steps must be followed.

1. Upgrade the version number of the feature per the standards outlined in section 6.2 of this document.
2. Make the appropriate changes to the Feature.xml file to deal with any relevant upgrade actions that must occur to move to the next version.
3. If the feature has the potential to be used in multiple places ensure that scenarios for a new activation as well as an upgrade are handled. This is accomplished by writing any appropriate code in the FeatureUpgrading and FeatureActivating event handlers
4. Package the WSP
5. Communicate to the infrastructure team that this is an Upgrade in order to ensure required changes are pushed down to existing instances of the feature if required.

1. Bibliography
   

   Juvonen, V. (2011, February). Application Lifecycle Management in SharePoint 2010. Retrieved from MSDN: http://msdn.microsoft.com/en-us/library/gg604045.aspx

   O’Brien, C. (2011). Real World SharePoint 2010. Indianapolis, Indiana: Wiley Publishing.

   O’Brien, C. (n.d.). Feature Upgrade Fundamentals. Retrieved from Fun and Games with the Nuts and Bolts of SharePoint: http://www.sharepointnutsandbolts.com/2010/06/feature-upgrade-part-1-fundamentals.html