SharePoint Development Requirements and Process

SharePoint Development Requirements and Process

1. Introduction

The process of developing solutions in SharePoint falls into several categories:

1. Interface Configurations Only

These are any modifications made to the environment that are carried out via the SharePoint user interface only.

2. SharePoint Designer

Some required changes cannot be effected via the interface as they require a deeper interaction. Microsoft have developed and supplied a tool for this called SharePoint Designer (this is a free tool).

3. Visual Studio

On occasion the user requirement may necessitate an even deeper level of customisation. This can only be implemented via a code solution.

The code solution comes in several variations but the scope of this document has been limited to sandboxed or full trust.

The main difference between sandboxed and full trust is fundamentally the depth and scope of the code reach. This means if the code has the ability to be programmed and can cause a severe problem which is server wide then it is referred to as full trust. If the code solution merely has access to some data and some benign objects, such as alerts then it is referred to as sandboxed. SharePoint Development

A deeper technical explanation on this matter is beyond the scope of this document. This is also the case with the App model which is the now preferred best practice but specific to SharePoint 2013.

2. Scope of this Document

2.1. In Scope

This document provides guidance which covers the following topics:

• General SharePoint development approach.

• Environments required

• High level process description

2.2. Out of Scope

• Environment patching

• Service packing

• Third party tools

• Farm topology

2.3. Assumptions

It has been assumed that those involved in the development of SharePoint will be trained and accountable for any tasks that they perform.

It has to be noted that even trivial changes to the interface, such as the addition of a column, can be considered as development and should be governed accordingly.

2.4. Interface Configurations Only Process

The governance for who can do what, where and when via the user interface is outwith the scope of this document. This can usually be found in the overarching SharePoint governance document.

2.5. SharePoint Designer Process

The governance for who can do what, where and when via SharePoint Designer is out with the scope of this document. This can usually be found in the overarching SharePoint governance document.

 

3. Visual Studio Process

This document has been created to focus on the process of developing via visual studio for solutions that require to be more technically encoded.

It is widely recognised that the difference between sandboxed and full trust is fairly academic. The choice is directly related to the solution that is being written and once again this is normally covered in a technical specification.

3.1. General Process

Under normal circumstance the developer should receive a detailed Functional Specification document. The developer will prepare a full technical explanation of the solution with further detailed explanations of how things work and which technologies have been utilised, more specifically a full description of the security model.

This document, TAD (Technical Architecture Document) is to be kept on a shared drive and deemed to be organic, as in the document to be updated on a daily basis.

The developer should keep a task list and a risk log also shared and once again updated daily. This is a feed into the Project Managers reports and not a substitute.

The source code should also be checked-in daily. The developers should on a daily basis update the full documentation and implement a test build on the integration server.

Once the development is complete and has been signed off. The developers should provide a hand over workshop to the internal development team. This is to ensure that the client has assimilated the development understanding.

4. Environments

4.1. Primary Development Environments

It is more efficient for all developers, including external partners to develop within the client environment.

This is critical as the main source of errors and deployment issues often centres around the permissions model. Many solution user experiences benefit from deep user personalisation.

Both these items require access to the AD.

To facilitate this we will need the following to be in place:

• Each developer (internal and external) will require a client desktop with a fixed IP.

• Normal user account with email.

• MS Office.

• External remote desk top access.

4.2. Development Hardware Specification

To perform the development the developers will need the following:

Server A (SharePoint) Server B (SQL)

Hard Drive C: 80gb 80gb

Hard Drive D: 50gb 150gb

Hard Drive E: N/A 100gb

Processor 64 bit 4 core 64 bit 4 core

RAM 8gb 8gb

OS Windows Server 2008 Standard Windows Server 2008 Standard

IP Fixed Fixed

Software SharePoint 2010 Enterprise SQL Server 2008 R2

Visual Studio 2010 Professional SQL Management Tools

Permissions Admin Admin

Access Remote Remote

5. Other Requirements

To provide adequate testing the developers will be required to have access to 6 generic user names and passwords. For example User01 / passowrd1 etc.

10 domain names pre-established in DNS are very useful for initial development as they can be aliased and thus new web applications can be provisioned efficiently.

5.1. Deployment Environments

The developers should aim to have a daily build on the integration server (this can be automated and kicked off when the code is saved depending on the source code repository software selected).

No development should be allowed on this server however, it is useful to have some debugging tools on the integration server for the purposes of final debug.

The developers should have reasonability for deploying onto the integration farm.

Developers will create a test plan as part of the TAD and once the deployment has been tested the decision can be made to either continue developing and deploying to integration or whether to deploy to the test where it can be tested by the client sometimes referred to as UAT.

A regular two hour slot twice a week can be reserved with infrastructure. It is the client responsibility to deploy to test.

The client should be supplied with a package and the full deployment will be scripted using PowerShell. Where possible the developer should aim for a one click deployment.

It is not the responsibility of Infrastructure to debug or modify any scripts.

The deployment can reside here and be tested by the users until it is signed off. Normally a minimum “Rest and Test” of one week to ensure that there are now conflicts.

 


Leave a Reply

Your email address will not be published.