Most companies I have been working with have a lot of problems trying to adopt to a SDLC model with SharePoint and TFS (Team Foundation Server). I will go over some if the pain points, recommended practices and ways to adhere to the practices in your own shop. If you are like most shops, you have multiple teams developing disparate solutions to be hosted on one SharePoint environment. These teams could be geographically dispersed or all in one building and can be made up of differing levels of development and SharePoint experience. Most of the time is no or very little consistent development and release approach across teams - currently changes are released directly by the developers onto the live environment. Which is very bad and will cause problems in the long run.
Current Pain Points
Most of us can relate to these pain point below. Most of them can be fixed by understand the problem and how to get a resolution applied.
Key Principles to Remember
Before defining the development and release process principles, it is useful to outline the types of development that can be done on SharePoint. These are as follows:
To achieve the high level goal of improving quality and reducing downtime, a more rigorous development and release process is recommended, driven by the following principles:
Establish Quality Gates
To facilitate development, testing and release of custom code, five key environments in the Software Development Lifecycle are recommended:
The diagram below outlines the development and release process for pushing solutions through to production. In-between each stage, there is a quality gate. Certain standards and procedures need to be met at these stages for code to make it to the next stage (e.g. checked in code has been related to a bug or task in TFS, the code has been peer reviewed etc). If code fails these quality gates, it is not allowed to progress.
Also note that as multiple development teams are working on multiple solutions to end up on one SharePoint platform (production). It is therefore recommended that each development team has their own set of development and test environments.
Note that the above diagram also shows content migration flow. It is advisable that content is frequently duplicated from Production back to Pre-Production to ensure that the environments are as close together as possible. It may also be that a subset of data be extracted for use in Test environment, although the Test environment just needs realistic test data – actual data is not critical.
Note that it is also worth considering operational readiness for a solution, such that the infrastructure / support team has the relevant documentation to support, monitor, troubleshoot and administer the solution.
In Part 2, I will go more in depth of the quality gate process and project team responsibilities