Application Lifecycle Management in SharePoint 2013 : Planning your Customization Model and Release Packaging Approach (part 1) - Customization Models

One of the key considerations for any SharePoint farm is the overall planning and design for the customizations and underlying components, and the solution packaging approach to deploying these customizations and components successfully through your environments into your production environment.

1. Customization Models

Now take a look at some of the common customization and component models available for SharePoint development.

Custom Component Development Model

During the planning of the SharePoint solution development, special attention should be given to the design of the customizations, and strategic design decisions related to the makeup of each of the solution packages. Unfortunately, relatively often, code architecture and structural planning in SharePoint projects is often an afterthought.

Your design defines the way your different components work, such as how web parts are developed, and how the overall code and Visual Studio project structure are created and developed. Your Visual Studio code projects structure, in turn, influences what is deployed in each solution package.

A lack of architectural and design planning can severely decrease the reusability of code inside of your project. The lack of proper design manifests itself later when it becomes difficult to test and later difficult to patch in your production.

As a rule of thumb, similar to any development work, code should be structured into different layers to provide flexibility and promote reusability of the code. Layering and structuring your code and code projects efficiently makes it easier to test, deploy, and maintain and update safely in your production environment.

You have numerous approaches to planning code architecture. The decision on the correct approach should be based partly on the skill of your development team and partly on maintainability and updatability considerations. The development skills at your disposable help guide your decision making as to whether advanced architectural patterns should be used, instead of simpler patterns.

Another key aspect to consider relates to the maintainability and future upgradeability of your code base. Will your maintenance developers be the original developers, or will they make up a slightly less-skilled team? Will new developers understand your code base when you or your original team is no longer on the project?

Most important and critically, and more often than you think, SharePoint development teams make the common mistake of putting all their customizations into one or two code projects (and solution packages). What starts as one or two web parts in one or two solution packages ends up with every customization ever built for their SharePoint deployment existing in a few solution packages.

Initially everything seems okay, but then after successive releases, each release takes longer and longer to get to production. As more and more code and customizations are added, the cost and risk profile for each production update goes up. What then occurs is the following:

• Quality assurance, using unit, regression, and integration testing become much bigger jobs than they need to be.
• Unnecessary complexity increases, and the frequency of trade-off type design decisions to keep all your components working goes up.
• Issues relating to your components in production take forever to be rectified.
• The customer or business gets annoyed and frustrated with the long time scales required, which in their eyes are simple changes that make a difference to their end-user experience.

These factors contribute to the long-term success of your code architecture, performance of your SharePoint environments, and, ultimately, the end-user experience.

If there is one lesson you take away from this section, it is always better to have a high number of relatively small solution packages in your production, as opposed to one or two massive solution packages. Now look at how you can achieve that.

Designing Reusable Frameworks in SharePoint

Reusable frameworks for SharePoint provide a cost-efficient way to reuse code for multiple projects without requiring recoding for each project. Common patterns and code classes will emerge during the creation of your initial release. These features can benefit your current and future SharePoint projects. Where possible, these should be included in separate framework-type code projects from the start.

As shown in Figure 1, look at a real-world example of how it is possible to split up your code and components into a structure that is easy to maintain, update, and grow.

FIGURE 1

Now look at this example in more detail:

• Microsoft.Practices.SharePoint — Microsoft provides a number of common components, including logging, that can be used across all your code projects.
• WiredLight.Shared — To facilitate reuse, a shared code project (and component) houses all shared functionality. All changes to this code project are closely monitored.
• Numerous web part projects — Each web part is in its own code project, and, therefore, can be maintained and updated in an isolated fashion to the rest of the solutions.
• Publishing sites — Publishing sites, along with associated deployment and assembly artifacts, are deployed using isolated solution packages.

Using the preceding model and example, new solutions are easy to add to the overall portfolio of solutions. Defects are much easier to analyze, triage, maintain, and update in production.

Another good example of a reusable framework is Microsoft’s patterns and practices guidance package for SharePoint. This package contains a lot of reusable generic code, which would be beneficial for multiple projects. Commonly, this type of code can either be copied to the project or used directly from its own packages.

The usage also depends on the skill level of the developers involved in the project. Writing generic reusable code could be difficult for less-experienced developers and could increase the overall work required for the project. However, reusable frameworks can be created relatively easily by an experienced team of developers, and the code can be used for multiple projects.

Following are some examples of common features included in reusable SharePoint frameworks:

• Logging
• Configuration management
• Caching
• Service locator model
• Generic list management
• Content type management
• Site provisioning management

Third-Party Component Considerations

One way to decrease the amount of custom code required for your SharePoint-based solutions is to use third-party components. Great components and apps are available that can help fulfill your project objectives without implementing customizations. Aim to use your development resources and focus your development effort on activities that are not available out-of-the-box, or where third-party solutions are not available. Remember, your goal is to deliver business value, not to develop features that can already be met by affordable third-party solutions.

Another reason to prefer third-party solutions is that the developers of these solutions provide continual support and enhancements over time to their products. They worry about the testing and development resources to maintain these products. This helps your development team focus on delivering business-specific customizations and value.

Key considerations with third-party components include ensuring that your project will have sufficient legal rights to the usage and source code to avoid any additional costs throughout the project. This is especially true for community code projects made available on sites such as CodePlex. For these types of projects, review the license and ensure that source code is acquired to enable you to maintain and enhance if the third-party component vendor closes, or the community code project is no longer available. Your SharePoint deployment should not be dependent on custom code that cannot be supported, or for which your business is not correctly licensed.