SharePoint Governance - Development and Customization Policies

Article
12/16/2010

This is a series of 9 articles. Click here for the full TOC

This article to continue the application lifecycle management talk on SharePoint.

Development and Customization Policy

Microsoft published a document called Team-Based Development in Microsoft Office SharePoint Server 2007 and ALM Resource Center | SharePoint 2010. While this is a good starting place, many additional details of team-based development for SharePoint at your company must be decided; that is the goal is to develop guidelines for the following aspects in order to define all the required development processes:

Application management – how are the files implementing an application organized and managed?
Source control – how can the application files be managed in source control?
Build Process – what procedures are used to build the system on the integration server?
Deployment Process – what processes are used to deploy the system to the integration server and then towards the production environment?
Developer synchronization – how can developers be sure they are using the correct version of all application files?

Policy Sample: Standardize the development environment

The development environments that are used for SharePoint custom application development should allow the complete set of resources that developers will need to create these new applications. These development environments should be autonomous and should allow the developer to work independently on his/her component without interfering with other developers. The unit testing should also be conducted within the developer's individual environment.

Policy Sample: on delivery strategy using the trade-off approach

The delivery strategy for design decisions is "schedule driven." That is, when making decisions such as the level of detail to which Features should be implemented, and even which Features should be implemented, the guiding criterion should be the ability to complete the Feature/detail in the allotted schedule.

This means in [Your Company], resources are fixed (since the team is fixed) and features come from internal customers (the business). Thus, the only thing that is adjustable is schedule. So Given a fixed resources, we will choose feature, and adjust schedule as necessary.

Naturally the design team will make sensible exceptions to this when appropriate. But as a general rule, Features or details that can't pass this criterion should be phased into a later delivery. Details of this process are given below.

Possible options to implement each Feature will be identified, and the effort for each one estimated.
A review is held to decide on the implementation option to be chosen for each Feature. In some cases, it may be desirable to implement a Feature to a lesser degree of fidelity to requirements than is possible, if the lesser degree can be implemented with significantly less effort.
For functions that are judged too much effort to implement in the project's timeline, a follow-on phase of implementation will be proposed, along with the estimated level of effort and time to complete. This will allow project planners to make informed decisions about phasing versus adjustment of resources or other aspects of the current release.

Policy Sample: on key design goals, use the "OOB to Custom" approach

The primary goal when designing "how to implement requirements" is to use "out-of-box" (OOB) functionality whenever possible and to consider custom development only when necessary and justified. That said, OOB functions usually entail some level of effort that's often overlooked in planning. Several examples may help to illustrate degrees of "out-of-box."

Policy Sample: on development process use the DTUP approach

We will use the process of moving between Development, Test, UAT and Production (DTUP) environments. Developers use virtualized servers (virtual PCs) on their individual workstations to develop and unit test for SharePoint. The following diagram shows relationships among the workstations, servers and farms that will be used to manage code development and deployment from end to end.

Policy Sample: how to make namespaces

The following namespaces are recommended.

CompanyName: for now it's contoso, but maybe later fabrikam (contoso partner) or something similar.
Zone: would be internet or intranet
ApplicationName: could be HR, SLA or MyApp
DeployableType: The use of "Web" is designed to indicate components that interact with SharePoint to support end-user actions directly. The "Operations" namespace should be used for components that are run offline or deal more with administration of the farm. And other as shown below:

for example: Contoso.Intranet.EmployeePortal.Web Components that are used across other web namespaces, such as GlobalMethods.

Other Policies might be:

Policy: use GAC deployment instead of bin deployments
Policy: use keyword syntax for querying search as possible
Policy: don't leave connection strings in web.config unencrypted
Policy: Cleanup when deactivating features