The document discusses SharePoint Application Lifecycle Management (ALM). It describes the key phases of ALM including requirements management, solution architecture, development, build, quality assurance, testing, solution deployment, and operation. For each phase, it outlines objectives, challenges, and Steria's approach which leverages tools like Team Foundation Server, PowerShell, and custom CodePlex projects to implement best practices for SharePoint ALM. The presentation encourages sharing ALM knowledge and experiences within the developer community.

1. SharePoint Application Lifecycle
Management  www.steria.se
Sweden SharePoint User Group
25/09/2012

2.  www.steria.se
About Matthias Einig
SharePoint
 SharePoint developer since 2005
 Certified MCPD, MCITP, MCTS in SP and TFS, SCRUM Master and PO
 Main Focus:
- Solution Architecture,
- SharePoint ALM,
- Solution Quality Assurance
Steria
 At Steria since 2008 (since 2012 in Sweden)
 Team Lead SharePoint Consulting @ Steria Sweden
Contact
 matthias.einig@steria.se
 www.matthiaseinig.de
 Twitter: @mattein
25/09/2012 2

3.  www.steria.se
What is Application Lifecycle Management?
Application Lifecycle Management
“is a continuous process of managing the life of
an application through governance, development
and maintenance“ *
* wikipedia.org

4.  www.steria.se
SharePoint Application Lifecycle Management
Operate
Requirements
Management
Solution
Deployment Solution
SharePoint Architecture
Application
Lifecycle
Testing
Development
&
Quality Build
Assurance

5.  www.steria.se
Requirements Management
Specify
Objectives
 Stakeholder Analysis
 Requirements analysis
 Manage and track requirements
Challenges
 Aligning requirements with SharePoint usability
 Avoid re-implementing standard functionality
 Identifying „missing“ requirements

6.  www.steria.se
Requirements Management
Steria approach
 Business analyst should know SharePoint!
 Educate stakeholders in SharePoint
 Create wireframes and UI mockups
 Standardize the syntax of requirements
 Avoid changing SharePoint standard behaviour
 Manage requirements in Team Foundations Server

7.  www.steria.se
Solution Architecture
Design
Objectives
 Re-use components
 Stability and Performance
 „Build to last, build to change“
Challenges
 Complexity of SharePoint
 Requirements deviate from SharePoint standards
 Existing solutions on environment

8.  www.steria.se
Solution Architecture
Steria approach
 Know SharePoint ootb functionalities!
 Use as much SharePoint standard as possible
 Design reusable modules
 Use existing patterns i.e. service locator, repository
pattern etc.
 Build vs. buy?

9.  www.steria.se
Development
Code
Objectives
 High quality (stability, performance, maintainability)
 Conformance to coding guidelines and naming conventions
 Testability
Challenges
 Multiple languages C#, XML, HTML, CSS, JavaScript
 Cryptic dependencies
 No guidelines on solution structure
 Team development

10.  www.steria.se
Development
Steria approach
 Use TFS for source control and workitems
 Structure application in multiple solutions
 Be consistent in coding approach
(declarative vs. programmatic)
 Convention over Configuration
 Enforce coding guidelines
 Specialized developers
 Standardize development environment
http://spsf.codeplex.com

11.  www.steria.se
SPSF DEMO  www.steria.se
25/09/2012

12.  www.steria.se
Build
Compile & Package
Objectives
 Deployable solution package (WSP-file)
 Build against production-like environment
 Continuous integration
Challenges
 Developer environment might deviate from production
 Not using latest sources on local build
 Integration problems are often realized too late

13.  www.steria.se
Build
Steria approach
 Use TFS team build
 Build server should run on production-like system
 Integrate periodically to realize problems sooner
Team Build

14.  www.steria.se
Quality Assurance
Validate
Objectives
 Identify weaknesses
 Ensure maintainability of code
 Validate against company specific rules and policies
 Identify unneeded dependencies
Challenges
 SP Solutions have loads of files
 Content of XML is not validated
 Too many ways to implement the same requirement
 Solutions deploy into the SharePoint “Hive”

15.  www.steria.se
Quality Assurance
Steria approach
 Assure quality before check in
 Establish software quality gates
 Use FxCop, StyleCop and
SPDisposeChecker
 Make regular code reviews
 Check SharePoint “code”
automatically
http://sharepointcop.codeplex.com

16.  www.steria.se
SPCop DEMO  www.steria.se
25/09/2012

17.  www.steria.se
Testing
Test
Objectives
 Test against requirements
 Identify bugs early
 Automate tests
 Test stress scenarios
Challenges
 Unit testing complicated
 Solution might affect standard functionality
 XML code cannot be tested directly
 Manual tests very time consuming

18.  www.steria.se
Testing
Steria approach
 Specify test cases in TFS
 Link tests to workitems
 Separate business logic from SP Code
 Use mocking frameworks
 Use Coded UI Tests in VS
 Use VS TestManager

19.  www.steria.se
Solution Deployment
Deploy
Objectives
 Complete (customization, configuration, content)
 Fully automated / reproducable
 Support undeployment
 Support solution upgrade
Challenges
 Manual steps often required
 Multiple environments (DEV, INT, ACC, PROD)
 IT Pros don’t trust developers on their farms

20.  www.steria.se
Solution Deployment
Steria approach
 Standardize deployment
 Use PowerShell
 Include configuration and content
 Parameterize deployment for
different environments
 Detailed log of all deployment
steps
http://spsd.codeplex.com

21.  www.steria.se
Operation
Run
Objectives
 Maintain a stable farm environment
 Allow application changes with minimal impact
 Be able to roll back changes
 Reduce downtimes
Challenges
 Multiple custom solutions on a farm
 SP Updates might affect custom solutions
 Some bugs can be only reproduced on production

22.  www.steria.se
Operation
Steria approach
 Have a test farm!
 Expect change and prepare
 Classify changes and prioritize them
 Create scripts for configuration changes
 Import live content to test farm regularly
 Use third party tools to manage your farm
(i.e. DocAve)

23.  www.steria.se
Summary
 ALM is a MUST for development in teams
 ALM works for both small and big projects
 ALM works both for agile and waterfall projects
 Team Foundation Server is required for SharePoint ALM
 Gaps in the ALM process can be improved with custom tools

24.  www.steria.se
The Power of Sharing
Community
 Visit us at SEForum 22/23 October
 CodePlex
http://spalm.codeplex.com
http://spsf.codeplex.com
http://sharepointcop.codeplex.com
http://spsd.codeplex.com
 @mattein
 http://www.matthiaseinig.de

25.  www.steria.se
Now let’s have a beer!  www.steria.se
25/09/2012