Update, February 10, 2011: See the MSDN version of this article: Application Lifecycle Management in Microsoft SharePoint 2010.
November 2010
Applies to: Microsoft SharePoint Foundation 2010, Microsoft SharePoint Server 2010, Microsoft Visual Studio 2010 SharePoint Developer Tools, Microsoft Visual Studio 2010 Team Foundation Server and Microsoft SharePoint Designer 2010
Summary: Learn how to plan and manage Application Lifecycle Management (ALM) in Microsoft SharePoint 2010 projects using Visual Studio 2010 and Microsoft SharePoint Designer 2010. Also learn what things should be considered when setting up team development environments, establishing upgrade management processes, and creating a standard development model.
Introduction to Application Lifecycle Management in SharePoint 2010
The Microsoft SharePoint 2010 development platform, which includes SharePoint Foundation 2010 (SPF2010) and SharePoint Server 2010 (SPS2010), contains many capabilities to help you develop, deploy, and update customizations and custom functionalities for your SharePoint sites. The activities that take advantage of these capabilities all fall under the category of Application Lifecycle Management (ALM).
Key considerations when establishing ALM processes include not only the development and testing practices that you use before the initial deployment of a single customization, but also the processes that you must implement in order to manage updates and integrate customizations and custom functionality on an existing farm. This article discusses the capabilities and tools that you can use when implementing an ALM process on a SharePoint farm, and also specific concerns and considerations to take into account when you create and hone your ALM process for SharePoint development.
This article assumes that each development team will develop a unique ALM process that fits its specific size and needs, so its guidance is necessarily broad. It also assumes, however, that regardless of the size of your team and the specific nature of your custom solutions, you will need to address similar sets of concerns and utilize capabilities and tools that are common to all SharePoint developers. The guidance in this article will help you as create a development model that exploits all the advantages of the SharePoint 2010 platform and addresses the needs of your organization.
SharePoint Application Lifecycle Management: An Overview
Figure 1 depicts a sample ALM process for a midsize or large SharePoint 2010 deployment. Obviously the process and required tasks depend on the project size.
Image may be NSFW.
Clik here to view.
These are the steps illustrated in figure 1:
1. Initial requirements are collected and turned into tasks.
2. Developers use Visual Studio 2010 Team Foundation Server or other tools to track the development progress and store custom source code.
3. Since source code is stored in a centralized location, you can create automated builds for integration and unit testing purposes. You can also automate testing activities to increase the overall quality of the customizations.
4. In larger projects, there could also be an additional build verification or user acceptance testing (UAT) farm, which is used by QA personnel to test and verify the builds in an environment that more closely resembles the production environment. Typically a build verification farm has multiple servers to ensure that custom solutions are deployed properly. Figure 2 illustrates a potential model for relating development integration and testing environments, build verification farms, and production environments. In this particular model, the pre-production or QA farm and the production farm switch places after each release. This model minimizes any downtime related to maintaining the environments.
Image may be NSFW.
Clik here to view.
5. After custom solutions have successfully undergone acceptance testing, you can continue to the pre-production or quality assurance environment.
6 and 7. The pre-production environment should resemble the production environment as much as possible. This often means that the pre-production environment has the same patch level and configurations as the production environment. The objective of this environment is to ensure that your custom solutions will work in production. The production database can be copied to this environment occasionally, so that you can imitate the upgrade actions that will be performed in the production environment.
8 and 9. After the customizations are verified in the pre-production environment, they are deployed either directly to production or to a production staging environment and then to production.
10. The production environment is used by end users, who give feedback and ideas concerning the different functionalities. Issues and bugs are reported and tracked through established reporting and tracking processes.
11. Feedback, bugs, and other issues in the production environment are turned into requirements, which are prioritized and turned into developer tasks. Figure 3 illustrates how multiple developer teams can work with and process bug reports and change requests received from end users of the production environment. The model in this figure also illustrates how development teams might also coordinate their solution packages. For example, the framework and the functionality development teams might follow separate versioning models that need to be coordinated as they track bugs and changes.
Image may be NSFW.
Clik here to view.
Another significant consideration in your ALM model is SharePoint Designer 2010. SharePoint 2010 is an excellent platform for no-code solutions, which can be made and deployed directly to the production environment by using SharePoint Designer 2010. These customizations are stored in the content database and are therefore not stored in your source code repository. Designer activities in general are another consideration. Will you be creating new page layouts directly within your production environment, or will you deploy them as part of your packaged solutions? There are advantages and disadvantages to both options.
Your own ALM model depends completely on the custom solutions and the customizations that you plan to make, and on your own policies. Your ALM process does not have to be as complex as the one described in this section. However, you will need to establish a firm ALM model early in the process as you plan and create your development environment and before you start creating your custom solutions.
The following section discusses specific tools and capabilities related to SharePoint 2010 development that you can use when considering how to create a model for SharePoint ALM that will work best for your development team.
Solution Packages and the SharePoint Tools Continuum
One major advantage of the SharePoint 2010 development platform is that it provides the ability to save sites as solution packages. A solution package is a deployable, reusable package stored in a .cab format file with a .wsp extension. You can create a solution package either by using the SharePoint 2010 user interface in the browser, SharePoint Designer 2010, or Microsoft Visual Studio 2010. In the browser and SharePoint Designer 2010 user interfaces, solution packages are also called templates. This flexibility allows you to create and design site structures in a browser and/or in SharePoint Designer and then import these customizations into Visual Studio 2010 for further development. Figure 4 illustrates this continuum.
Image may be NSFW.
Clik here to view.
When the customizations are complete, you can deploy your solution package to SharePoint and use it there. After modifying the existing site structure with a browser, you can start the cycle all over again by saving the updated site as a solution package.
This tools continuum also enables you to use other tools. For example, you can design a workflow process in Microsoft Visio 2010 and then import it to SharePoint Designer 2010 and from there to Visual Studio 2010. For instructions on how to do this, see Create, import, and export SharePoint workflows in Visio.
For more information on creating solution packages in SharePoint Designer 2010, see Save a SharePoint Site as a Template. For more information on creating solution packages in Visual Studio 2010, see Creating SharePoint Solution Packages.
Using SharePoint Designer 2010 as a Development Tool
SharePoint Designer 2010 differs from Microsoft SharePoint Designer 2007 in that its orientation has shifted from the page to features and functionality. The improved user interface provides greater flexibility for creating and designing different functionalities. It provides rich tooling for building complete, rich, reusable and process-centric applications. For more information about the new capabilities and features of SharePoint Designer 2010, see Getting Started with SharePoint Designer.
You can also use SharePoint Designer 2010 to modify modular components developed with Visual Studio 2010. This means, for example, that you can create web parts and other controls with Visual Studio 2010, deploy them to a SharePoint farm, and then edit them in SharePoint Designer 2010.
The primary target users for SharePoint Designer 2010 are IT personnel and information workers who can use this application to create customizations in a production environment. For this reason, you will need to decide on an ALM model for your particular environment that defines which kinds of customizations will follow the complete ALM development process and which customizations can be done by using SharePoint Designer 2010. Developers are secondary target users. They can use SharePoint Designer 2010 as a part of their development activities, especially during initial creation of customization packages and also for rapid development and prototyping. Your ALM process also needs to define where and how to fit SharePoint Designer 2010 into the broader development model.
A key challenge of using SharePoint Designer 2010 is that when you use it to modify files, all of your changes are stored in the content database instead of the file system. For example, if you customize a master page for a specific site by using SharePoint Designer 2010 and then design and deploy new branding elements inside a solution package, the changes will not be available for the site with the customized master page, since that site is using the version of the master page that is stored in the content database.
To minimize these kinds of challenges, SharePoint Designer 2010 contains new features that enable you to control usage of SharePoint Designer 2010 in a specific environment. You can apply these control settings at the web application or site collection level. If you disable some action at the web application level, that setting cannot be changed at the site collection level.
SharePoint Designer 2010 makes the following settings available:
- Allow site to be opened in SharePoint Designer 2010.
- Allow customization of files.
- Allow customization of master pages and layout pages.
- Allow site collection administrators to see the site URL structure.
These settings are ignored if you use the farm administration account.
Since the primary purpose of SharePoint Designer 2010 is to customize content on an existing site, it does not support source code control. Pages that you customize by using SharePoint Designer 2010 are by default stored inside a versioned SharePoint library. This provides you with simple support for versioning, but not for full-featured source code control.
Importing Solution Packages into Visual Studio 2010
When you save a site as a solution package in the browser (from the Save as Template page in Site Settings), SharePoint 2010 stores the site as a .wsp file and places it in the Solutions Gallery of that site collection. You can then download the solution package from the Solutions Gallery and import it into Visual Studio 2010 by using the Import SharePoint Solution Package template, as illustrated in figure 5.
Image may be NSFW.
Clik here to view.
SharePoint 2010 solution packages contain a number of improvements that take advantage of new capabilities that are available in its feature framework. The following list contains some of the new feature elements that will be helpful to you in managing your development projects and upgrades (many of which are discussed later in this article).
- SourceVersion for WebFeatures and SiteFeatures
- WebTemplate feature element
- PropertyBag feature element
- $ListId:Lists
- WorkflowAssociation Feature Element
- CustomSchema attribute on ListInstance
- Solution Dependencies
After you have imported your project, you can start customizing it any way you like. Note that since this capability is based on the WebTemplate feature element, which is based on a corresponding site definition, the resulting solution package will contain definitions for everything within the site. See Web Templates for more information about creating and using web templates.
Visual Studio 2010 supports source code control (as shown in figure 6), so you can store the source code for your customizations in a safe and secure central location and enable easy sharing of customizations among developers.
Image may be NSFW.
Clik here to view.
The precise manner in which your developers will access this source code and interact with each other depends on the structure of your team development environment. The next section of this article discusses key concerns and considerations that you should consider when you build a team development environment for SharePoint 2010.
Team Development Environment for SharePoint 2010: An Overview
As any ALM planning process, your SharePoint 2010 planning should include the following steps:
- Identify and create a process for initiating new projects.
- Identify and implement a versioning system for your source code and other deployed resources.
- Plan and implement version control policies.
- Identify and create a process for work item and defect tracking and reporting.
- Write documentation for your requirements and plans.
- Identify and create a process for automated builds and continuous integration.
- Standardize your development model for repeatability.
Visual Studio 2010 Team Foundation Server (illustrated in figure 7) provides a good potential platform for many of these elements of your ALM model.
Image may be NSFW.
Clik here to view.
When you have established your model for team development, you will need to choose either a collection of tools or Microsoft Visual Studio 2010 Team Foundation Server to manage your development. Team Foundation Server provides direct integration into Visual Studio, and it can be used to manage your development process efficiently. It provides many capabilities, but your actual usage of it will depend on your projects.
You can use the Team Foundation Server for the following activities.
- Track work items and report the progress of your development. Team Foundation Server provides tools to create and modify work items that are delivered not only from Visual Studio 2010, but also from the Visual Studio 2010 web client.
- Store all source code for your custom solutions.
- Log bugs and defects.
- Create, execute and manage your testing with comprehensive testing capabilities.
- Enable continuous integration of your code by using the automated build capabilities.
Visual Studio 2010 Team Foundation Server also provides a basic installation option that installs all required functionalities for source control and automated builds. These are typically the most heavily used capabilities of Team Foundation Server and this helps you set up your development environment more easily.
Setting up a Team Development Environment for SharePoint 2010
SharePoint 2010 must be installed on a development machine in order to take full advantage of its development capabilities. If you are developing only remote applications, such as solutions that use SharePoint web services, the client object model or REST, you could potentially develop solutions on a computer where SharePoint 2010 is not installed. Even in this case, however, your developers' productivity would suffer, since they would not be able to take advantage of the full debugging experience that comes with having SharePoint 2010 installed directly on the development computer.
The design of your development environment will depend on the size and needs of your development team. Your choice of operating system will also have a significant impact on the overall design of your team development process. You have three main options for creating your development environments.
You can run SharePoint directly on your computer's client operating system. This option is available only when you use the 64-bit version of Windows 7, Windows Vista Service Pack 1, or Windows Vista Service Pack 2.
You can use the boot to VHD option, which means that you start your laptop using the operating system in VHD. This option is only available when you use Windows 7 as your primary operating system.
You can use virtualization capabilities. If you choose to take advantage of virtualization capabilities, you have a choice of numerous options, but from an operational point of view, the option that is most likely to be the easiest to implement is a centralized virtualized environment that hosts each developer's individual development environment.
The following sections take a closer look at these three options.
SharePoint on a Client Operating System
If you are using the 64-bit version of Windows 7, Windows Vista Service Pack 1, or Windows Vista Service Pack 2, you can install SharePoint Foundation or SharePoint Server. See Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7, and Windows Server 2008 for more information on installing SharePoint 2010 on supported operating systems.
Figure 8 illustrates how a computer running a client operating system would operate within a team development environment.
Image may be NSFW.
Clik here to view.
A benefit of this approach is that you can take full advantage of any existing hardware that you own that is running one of the targeted client operating systems. You can also take advantage of pre-existing configurations, domains, and enterprise resources that your enterprise supports. This could mean that little or no additional IT support would be required. Your developers would also face no delays (such as booting up a virtual machine, accessing an environment remotely, etc.) in accessing their development environments.
If you take this approach, however, you will need to make sure that your developers have access to sufficient hardware resources. In any development environment, you should use a computer with an x64-capable CPU, and at least 2 gigabytes (GB) of RAM to install and run SharePoint Foundation; 4 GB of RAM is preferable for good performance. You should use a computer with 6 GB to 8 GB of RAM to install and run SharePoint Server.
A disadvantage of this approach is that your environments will not be centrally managed, and it will be difficult to keep all of your project-dependent environmental requirements in sync. It might also be advisable to write batch files that start and stop some of the SharePoint-related services so that when your developers are not working with SharePoint, these services will not consume resources and degrade the performance of their computers.
The lack of centralized maintenance could hurt developer productivity in other ways. For example, this might be an unwieldy approach if your team is working on a large SharePoint Online project that is developing custom solutions for multiple services (for example, the equivalents of http://intranet, http://mysite, http://teams, http://secure, http://search, http://partners, and http://www.internet.com) and deploying these solutions in multiple countries. If you are developing on a computer that is running a client operating system in a corporate domain, each development computer would have its own name (and each local domain name would be different, such as http://dev 1, http://dev2, etc.). If each developer is implementing custom functionalities for multiple services, you will have to use different port numbers to differentiate each service (for example, http://dev1 for http://intranet and http://dev1:81 for http://mysite ). If all of your developers are using the same Visual Studio 2010 projects, the project debugging URL will have to be changed manually whenever a developer takes the latest version of a project from your source code repository. This would create a manual step that could hurt developer productivity, and it would also diminish the efficiency of any scripts that you have written for setting up development environments, since the individual environments are not standardized. Some form of centralization with virtualization is preferable for large enterprise development projects.
Windows 7 and Boot to VHD
If you are using Windows 7, you can also create a virtual hard drive (VHD) out of an existing Windows Server 2008 image on which SharePoint is installed in Windows Hyper-V, and then configure Windows 7 with BDCEdit.exe so that it boots directly to the operating system on the VHD. See Deploy Windows on a Virtual Hard Disk with Native Boot and Boot from VHD in Win 7 to learn more about this kind of configuration.
Figure 9 illustrates how a computer running Windows 7 and booting to VHD would operate within a team development environment.
Image may be NSFW.
Clik here to view.
An advantage of this approach is the flexibility of having multiple dedicated environments for an individual project, enabling you to isolate each development environment. Your developers will not accidently cross reference any artifacts within their projects, and they can create project-dependent environments.
This option also comes with considerable hardware requirements, though, since you are directly utilizing the available hardware and resources on your computers.
Centralized Virtualized Environments
In a centralized virtualized environment, you host your development environments in one centralized location, and developers access these environments through remote connections. This means that you use Windows Hyper-V in the centralized location and copy a VHD for every developer as required. Each VHD is configured to be accessible from the corporate network, so that when it starts, it can be accessed using remote connections.
Figure 10 illustrates how a centralized virtualized team development environment would operate.
Image may be NSFW.
Clik here to view.
An advantage of this approach is that the hardware requirements for individual developer computers are relatively light since the actual work happens in a centralized environment. Developers could even use computers with 1 GB of RAM as their clients and then connect remotely to the centralized location. You can also easily manage environments from one centralized location, making adjustments to them whenever necessary.
Your centralized host will have significantly high hardware requirements, but developers can easily start and stop these environments. This enables you to use the hardware that you have allocated for your development environments more efficiently. Additionally, this approach provides a ready platform for more extensive testing environments for your custom code (such as multi-server farms).
Once you have set up your team development environment, you can start taking advantage of the deployment and upgrade capabilities that come with the new solution packaging model in SharePoint 2010. The following sections describe how to take advantage of these new capabilities in your ALM model.
Models for Solution Lifecycle Management in SharePoint 2010
The SharePoint 2010 solution packaging model provides a number of useful features that will help you plan for deploying custom solutions and managing the upgrade process. You can implement assembly versioning by applying binding redirects in your web application configuration file. You can also apply versioning to your feature upgrades, and feature upgrade actions enable you to manage changes that will be necessary on your existing sites in order to accommodate feature upgrades. These upgrade actions can be handled declaratively or programmatically.
The feature upgrade query object model enables you to create queries in your code that look for features on your existing sites that can be upgraded. You can use this object model to get relevant information about all of the features and feature versions that are deployed on your SharePoint 2010 sites. You can also configure in your solution manifest file the type of IIS recycling that you want to be performed during a solution upgrade.
The following sections go into greater details about these capabilities and how you can use them.
Assembly BindingRedirect
The BindingRedirect feature element can be added to your web applications configuration file. It enables you to redirect from older versions of installed assemblies to newer versions. The XML configuration from the solution manifest file in figure 11 instructs SharePoint to add binding redirection rules to the web application configuration file. These rules forward any reference to version 1.0 of the assembly to version 2.0. This is required in your solution manifest file if you are upgrading a custom solution that uses assembly versioning and if there are existing instances of the solution and the assembly on your sites.
Image may be NSFW.
Clik here to view.
It is a best practice to use assembly versioning, since it gives you an easy way to track the versions of a solution that are deployed to your production environments.
Feature Versioning
The support for feature versioning in SharePoint 2010 provides a large number of capabilities that you can use when you are upgrading features. For example, you can use the SPFeature.Version property to determine which versions of a feature are deployed on your farm, and which features therefore need to be upgraded. See SPFeature.Version Property for a code sample that demonstrates how to do this.
Feature versioning in SharePoint 2010 also allows you to define a value for the SPFeatureDependency.MinimumVersion property to handle feature dependencies. For example, you can use the MinimumVersion property to ensure that a particular version of a dependent feature is activated. Feature dependencies can be added or removed in each new version of a feature.
The SharePoint 2010 feature framework has also enhanced the object model level to support feature versioning more easily. You can use the QueryFeatures method to retrieve a list of features, and you can specify both feature version and whether a feature needs an upgrade. The QueryFeatures method returns an instance of SPFeatureQueryResultCollection instance, which you can use to access all of the features that need to be updated. This method is available from multiple scopes, since it is available from the SPWebService, SPWebApplication, SPContentDatabase and SPSite classes. For more information about this overloaded method, see SPSite.QueryFeatures, SPWebService.QueryFeatures, SPWebApplication.QueryFeatures, and SPContentDatabase.QueryFeatures. For an overview of the feature upgrade object model, see Feature Upgrade Object Model.
The following section summarizes many of the new upgrade actions that you can apply when you are upgrading from one version of a feature to another.
Feature Upgrade Actions
Upgrade actions are defined in the Feature.xml file. The SPFeatureReceiver class contains a FeatureUpgrading method, which you can use to define actions to perform during an upgrade. This method is called during feature upgrade when the feature's Feature.xml file contains one or more CustomUpgradeAction tags, as in the following example:
<UpgradeActions>
<CustomUpgradeAction Name="text">
...
</CustomUpgradeAction>
</UpgradeActions>
Each custom upgrade action has a name, which can be used to differentiate the code that needs to be executed in the feature receiver. As in following example, you can parameterize custom action instances.
Image may be NSFW.
Clik here to view.
This example contains two CustomUpgradeAction elements, one named "example" and the other named "SecondAction." Both elements have different parameters, which are dependent on the code that you have written for the FeatureUpgrading event receiver. The following example demonstrates how you can use these upgrade actions and their parameters in your code.
Image may be NSFW.
Clik here to view.
You can have as many upgrade actions as you want, and you can apply them to version ranges. The following example illustrates how you can apply upgrade actions to version ranges of a feature.
Image may be NSFW.
Clik here to view.
The AddContentTypeField upgrade action can be used to define additional fields for an existing content type. It also provides the option of pushing these changes down to child instances, which is often the desired behavior. When you initially deploy a content type to a site collection, a definition for it is created at the site collection level. If that content type is used in any sub-site or list, a child instance of the content type will be created. To ensure that every instance of the specific content type is updated, you will need to set the PushDown attribute to true, as in the following example.
Image may be NSFW.
Clik here to view.
See Introduction to Content Types for more information about working with content types programmatically.
The ApplyFeatureManifests upgrade action can be used to apply new artifacts to a SharePoint 2010 site without reactivating features. Just as you can add new elements to any new SharePoint elements.xml file, you can instruct SharePoint to apply content from a specific elements file to sites where a given feature is activated.
You can use this upgrade action if you are upgrading an existing feature whose FeatureActivating event receiver performs actions that you do not want to execute again on sites where the feature is deployed. The following example demonstrates how to include this upgrade action in a feature.xml file.
Image may be NSFW.
Clik here to view.
An example of a use case for this upgrade action involves adding new .webpart files to a feature in a site collection. You can use the ApplyElementManifest upgrade action to add those files without reactivating the feature. Another example would involve page layouts, which contain initial web part instances that are defined in the file element structure of the feature element file. If you reactivate this feature, you will get duplicates of these web parts on each of the page layouts. In this case, you can use the ElementManifest element of the ApplyFeatureManifests upgrade action to add new page layouts to a site collection that uses the feature without reactivating the feature.
The MapFile element enables you to map a URL request to an alternative URL. The following example demonstrates how to include this upgrade action in a feature.xml file.
Image may be NSFW.
Clik here to view.
This would be useful to you in a case where you need to deploy a new version of a page that has been customized by using SharePoint Designer 2010. The resulting customized page would be served from the content database. When you deploy the new version of the page, the new version will not appear because content for that page is coming from the database and not from the file system. You could work around this problem by using the MapFile element to redirect requests for the old version of the page to the newer version.
It is important to note that the FeatureUpgrading method will be called for each feature instance that is to be updated. If you have 10 sites in your site collection and you update a web-scoped feature, the feature receiver will be called 10 times for each site context. See Feature.xml Changes for more information about how to use these new declarative feature elements.
Upgrading Features: A High Level 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 has already been deployed on a large SharePoint farm, you need to 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 will first need to update all of the existing definitions and include instructions for upgrading the feature where it is already deployed.
For example, say that you have developed a content type to which you need to add an additional custom site column. You need to add a new column called City to the previously deployed content type. First, you add a new element file to the feature. This element file defines the new site column and modifies the feature.xml to include the element file. The second step is to 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. The third step is to define the required upgrade actions for the existing sites. In this case you will need to 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 will 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 will be 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.
Figure 12 illustrates how the different components of this scenario fit together when you perform the upgrade.
Image may be NSFW.
Clik here to view.
Different sites might have different versions of a feature deployed on them. In this case you can create version ranges, which define specific actions to be performed when you are upgrading from one version to another. If a version range has not been defined, all upgrade actions will be applied during each upgrade.
Figure 13 illustrates how different upgrade actions can be applied to version ranges.
Image may be NSFW.
Clik here to view.
In this example, if a given site is upgrading directly from version 1.0 to version 3.0, all configurations will be applied, since you have defined specific actions for upgrading from version 1.0 to version 2.0 and from 2.0 to version 3.0. You have also defined actions that will be applied regardless of feature version.
Code Design Guidelines
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, as illustrated in figure 14.
Image may be NSFW.
Clik here to view.
By placing your upgrade code inside a centralized utility class you increase both the reusability and the testability of your code, since 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.
Upgrading Solutions
If you are upgrading a farm (full-trust) solution, you will first have to deploy the new version of your solution package to a farm.
Execute either of the following scripts from the command line to deploy updates to a SharePoint farm. The first example uses the stsadm command-line tool.
stsadm -o upgradesolution -name solution.wsp -filename solution.wsp
The second example uses the Update-SPSolution Windows Powershell cmdlet.
Update-SPSolution -Identity contoso_solution.wsp -LiteralPath c:\contoso_solution_v2.wsp -GACDeployment
After the new version is deployed, you can perform the actual upgrade which executes the upgrade actions that you have defined in your feature.xml files.
A farm solution upgrade can be performed either farm-wide or at a more granular level by using the object model. A farm-wide upgrade is performed by using the psconfig command line tool, as in the following example.
psconfig -cmd upgrade -inplace b2b
Note that this tool causes a service break on the existing sites. During the upgrade, all feature instances throughout the farm for which newer versions are available will be upgraded. You can also perform upgrades for individual features at the site level by using the Upgrade method of the SPFeature class. This method will cause no service break on your farm, but you are responsible for managing the version upgrade from your code. See SPFeature.Upgrade for a code example that demonstrates how to use this method.
Upgrading a sandboxed solution at the site collection level is much more straightforward. Simply upload the .wsp file that contains the upgraded features. If you have a previous version of a sandboxed solution in you solution gallery and you upload a newer version, an Upgrade option will become available in the user interface, as illustrated in figure 15.
Image may be NSFW.
Clik here to view.
After you select the Upgrade option and the upgrade is started, all features inside the sandbox solution will be upgraded.
Conclusion
This article has discussed some considerations and examples of ALM design, and it has also enumerated and described the most important capabilities and tools that you can integrate into the ALM processes that you choose to establish in your own enterprise. The SharePoint 2010 feature framework and solution packaging model provide a great deal of flexibility and power that you can put to work in your own ALM processes.
Additional Resources
For more information, see the following resources:
· MSDN: Team-Based Development in Microsoft Office SharePoint Server 2007
· MSDN: Administrator and Developer Guide to Code Access Security in SharePoint Server 2007
· MSDN: ASP.NET vs. SharePoint: How Development Differs
· MSDN: Business Connectivity Services in SharePoint Foundation 2010
· MSDN: Using Visual Studio for SharePoint Development
· MSDN: Using SharePoint Designer for SharePoint Development
· Microsoft Patters & Practices: SharePoint Guidance
· SharePoint Team Blog: Managing Upgrades on Sandbox Solutions