次の方法で共有

SharePoint Software Development Lifecycle using TFS 2012 Part 1

  • [アーティクル]

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.

  1. High bug rate on live
  2. Uncontrolled production environment
  3. Inconsistent test procedure
  4. Inconsistent developer environments
  5. Inconsistent testing environments
  6. No central logging policy
  7. No central bug list

 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:

  1. Custom code development. This is for compiled code that makes file-system changes to the SharePoint environment, as well as potentially effecting configuration changes. This is for traditionally developed code projects. Custom code should be deployed via SharePoint Global Solutions (wsp files).
  2. SharePoint Designer / Content Changes. Changes made with this approach only alter the SharePoint content database. No physical changes are made to physical files on the file system.
  3. Sandboxed Solutions.  This is a new mechanism with SharePoint 2010 that allows custom code (with limited SharePoint object model access) to be deployed to a specific “sandboxed” location. Outside of this location, code has no effect. This can be locked down on a per Site Collection basis.

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:

  • Control changes and releases made to the live (production) environment. The aim of this is to ensure rigour is applied when deploying to this environment, in order to minimise risks and ensure contingency (e.g. rollback plans).
  • Clarified responsibility. By clarifying responsibility and ensuring that suppliers / development teams know what standard they must adhere to, code quality will improve and risk of instability on production will be reduced.
  • Introduce automated deployment processes. The aim of this is to expedite deployment of solutions to other developer environments, test environments as well as release and pre-production.
  • Ensure environment consistency. There is less potential for bugs to occur and deployment steps to be missed if environments are consistent throughout the development a release process. This allows ease of bug reproduction on development environments that accelerate the rate in which fixes can be built.
  • Allow devolved development where feasible. Where development is low-risk (i.e. SharePoint Designer based development), the procedure should act to facilitate ease of development (i.e. still permit this alterations on the production environment), but isolate scope at which alterations can be made and provide contingency. The aim here is not to negate the benefit of how the product should work by applying overly heavy procedures.

Establish Quality Gates

To facilitate development, testing and release of custom code, five key environments in the Software Development Lifecycle are recommended:

  • Development – these are the environments that developers actually build solutions on. Each developer should have their own environment that includes an install of SharePoint to ensure that dependencies on other code are controlled.
  • Development Integration -  The devlopement environment should be used for intergation and regression testing by all development teams.
  • Test – The test environment should be used for functional and regression testing etc whilst a solution is in development.
  • Pre-Production – This should be as close to live as possible and is used to simulate the live environment for formal solution integration and deployment testing before solutions are pushed to live.
  • Production – This is the live environment where solutions will finally be released to once they pass all testing.  

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

Happy Coding!

John

Comments

  • Anonymous
    August 05, 2012
    <a href="www.lavainfotech.com/"><b>Software Development</b></a> You shared some interesting points here and very well explained. The thing which really hurts me is what you mentioned 'in the meantime'. This is what encourages the use of shady techniques and those who try to do it the clean way, the are left frustrated !

  • Anonymous
    August 05, 2012
    Thanks for your comments, I do not see anywhere in my blog that I mention the term "in the meantime". Please provide me a example and I will be happy to explain what I was trying to say.

  • Anonymous
    September 19, 2012
    Fantastic news!

  • Anonymous
    December 17, 2012
    Thank You Your blog is very informative & important : <a href ="http://www.trustdeal.in">software development company</a>

  • Anonymous
    January 22, 2013
    Thanks for great post. Any idea for Part2?

  • Anonymous
    August 16, 2013
    Do you have part 2 or recent lessons learned for SDLC?