Best Practices for SharePoint Application Lifecycle Management
•
14 j'aime•6,896 vues
These are my slides from the ShareCamp2013 in Munich http;//www.sharecamp.de SharePoint is typically a strategic decision for companies who intend to use it on a long-term basis. Customizations and enhancements, which means usually farm solutions or apps, are often designed and implemented with disregard to the overall life cycle of the platform. Future changes of the solutions, changing developers with different preferences in the code design, technical knowledge, documentation standards and quality understanding cause a considerable additional expense for maintenance and operation of solutions. By applying consistent SharePoint Application Lifecycle Management with Team Foundation Server 2010/2012 and simple "rules of conduct" will allow you to prevent having to start over again when the "expert who knew everything" suddenly leaves the company or the CIO decides once again to replace the consulting firm. This session presents best practices for SharePoint ALM and tools which can help to spare you the “why didn’t we think about that”-moment in a couple of years from now.
Recommandé
Recommandé
Contenu connexe
Plus de Matthias Einig
Plus de Matthias Einig (6)
Dernier
Dernier (20)
Best Practices for SharePoint Application Lifecycle Management
- 2. Matthias Einig SharePoint Architect SharePoint developer since 2005 Steria AB, www.steria.com Stockholm, Sweden MCSE, MCPD, MCITP MSCA in , SharePoint 2007-2013 SCRUM Master and Product Owner Contact Main Focus: @mattein • Solution Architecture, mail@matthiaseinig.de • Solution Development, www.matthiaseinig.de • SharePoint ALM, • Solution Quality Assurance
- 3. Application Lifecycle Management “is a continuous process of managing the life of an application through governance, development and maintenance“ * * wikipedia.org
- 4. SharePoint ALM 1. Requirements Management Run Specify 2. Solution Architecture 3. Development Deploy 4. Quality Assurance / Testing SharePoint Application Design 5. Build and Package Lifecycle Build 6. Solution Deployment & Package Code 7. Operation Validate & 8. Project and Release Test Management
- 5. Specify Objectives Challenges • Stakeholder Analysis • Align requirements with SP usability • Requirements analysis • Avoid re-implementing standard • Manage and track requirements functionality • Identifying „missing“ requirements
- 6. Best Practices • Business analyst know SharePoint! • Demo SharePoint to Stakeholders • Use Wireframes and UI mockups • Standardize the syntax of requirements • Avoid changing SharePoint standard behaviour • Manage and track requirements ie. in Team Foundations Server
- 8. Design Objectives Challenges • Re-use components • Complexity of SharePoint • Stability and Performance • Requirements deviate from • „Build to last, build to change“ SharePoint standards • Existing solutions on environment
- 9. Best Practices • Know SharePoint out-of-the-box capabilities! • Use SharePoint standard features where possible • Design reusable modules • Use existing patterns i.e. service locator, repository pattern etc. • Build vs. buy?
- 10. Code Objectives Challenges • High quality • Multiple languages C#, XML, • Conformance to coding HTML, CSS, JavaScript guidelines / conventions • Cryptic dependencies • Testability • Team development
- 11. Best Practices • Use source control and workitems • Structure application in multiple solutions • Be consistent in coding approach (declarative vs. programmatic) • Convention over Configuration • Specialized developers • Standardize development environment • Use SPSF
- 14. Build & Package Objectives Challenges • Deployable solution package • Developer environment might • Build against production-like deviate from production environment • “It builds on my machine…” • Continuous integration • DEBUG build on PROD
- 15. Best Practices • Use central team build Check In • Build server should run on production-like system • Integrate periodically to find problems sooner Team Build
- 17. Validate Objectives Challenges • Ensure maintainability of code • SP Solutions have loads of files • Validate against company • XML is not validated specific rules and policies • Do the same a 100 ways • Identify unneeded • Deploy into SharePoint “Hive” dependencies
- 18. Best Practices • Assure quality on check in • Establish software quality gates • Use FxCop, StyleCop and SPDisposeChecker • Make regular code reviews • Check SharePoint “code” automatically with SPCAF SP CAF SharePoint Code Analysis Framework
- 19. SP CAF
- 20. Test Objectives Challenges • Test against requirements • Unit testing complicated • Identify bugs early • Solution affects standard • Test stress scenarios functionality • XML code cannot be tested • Manual testing costs time
- 21. Best Practices • Specify test cases in TFS • Link tests to workitems • Separate business logic from SP Code • Use mocking frameworks (TypeMock, JustMock, Moles, Shims) • Use Coded UI Tests in VS • Use VS TestManager
- 22. Deploy Objectives Challenges • Complete (customization, • Manual steps often required configuration, content) • Multiple environments (DEV, TEST, • Fully automated / reproducable ACC, PROD) • Support retraction / upgrade • IT Pros don’t trust developers
- 23. Best Practices • Standardize deployment • Use PowerShell • Include configuration and content • Parameterize deployment for different environments • Log all deployment steps • Automate staging through TFS
- 25. Run Objectives Challenges • Maintain a stable farm • Multiple solutions on a farm environment • SP Updates might affect solutions • Allow application changes with • Some bugs can be only minimal impact reproduced on production • Reduce downtimes
- 26. Best Practices • Have a test farm! • Expect change and prepare • Classify and prioritize changes • Use scripts for changes • Import live content to test farm regularly • Use third party tools to manage your farm (i.e. DocAve)
- 27. SharePoint ALM works for … any team size (even one person) … any project size … any project process (agile or classic) Introduce it step by step! Use ALM tools like TFS!
- 28. Interested? Follow us! The SharePoint Code Quality Team Torsten Mandelkow @tmandelkow blogs.msdn.com/b/torstenmandelkow Matthias Einig @mattein www.matthiaseinig.de
Notes de l'éditeur
- Best PracticeBusiness Analyst should know SharePoint from a user perspectiveStructure requirements analysis based on information lifecycleStandardize syntax of requirementsQuestion and re-question the necessity of every standard SharePoint functionality changeUse tools to manage requirements i.e. Quality Center, Team Foundation Server etc.
- Best PracticeBusiness Analyst should know SharePoint from a user perspectiveStructure requirements analysis based on information lifecycleStandardize syntax of requirementsQuestion and re-question the necessity of every standard SharePoint functionality changeUse tools to manage requirements i.e. Quality Center, Team Foundation Server etc.
- - Multiple Skills required, XML is a pain- Dependencies: content type ids, feature guids, SharePoint artefacts (SiteTemplates etc.)-
- Best PracticeBusiness Analyst should know SharePoint from a user perspectiveStructure requirements analysis based on information lifecycleStandardize syntax of requirementsQuestion and re-question the necessity of every standard SharePoint functionality changeUse tools to manage requirements i.e. Quality Center, Team Foundation Server etc.
- ObjectivesError free compilation and packaging of a deployable SharePoint solution package (WSP-file)Build against assembly versions as present on production environmentBuild in “Release” configurationIntegrate continuouslyChallengesCode builds locally but not integrated with code of other developersDeveloper build against different solution versions (i.e. forgot to update local sources)Integration problems are often realised too late
- Best PracticeBusiness Analyst should know SharePoint from a user perspectiveStructure requirements analysis based on information lifecycleStandardize syntax of requirementsQuestion and re-question the necessity of every standard SharePoint functionality changeUse tools to manage requirements i.e. Quality Center, Team Foundation Server etc.
- ObjectivesIdentify weaknesses in SharePoint code (memory leaks, upgradeability, performance)Ensure maintainability of code (e.g. coding guidelines)Validate code against company specific rules and policiesIdentify unneeded dependencies in the codeChallengesSharePoint solutions contain a lots of files XML, assemblies, resources, etc.XML is not validated by any available tool, but wrong “code” can cause serious problemsToo many ways to implement the same code (naming, solution structure, dependencies)Solution could overwrite system files upon deployment
- Best PracticeBusiness Analyst should know SharePoint from a user perspectiveStructure requirements analysis based on information lifecycleStandardize syntax of requirementsQuestion and re-question the necessity of every standard SharePoint functionality changeUse tools to manage requirements i.e. Quality Center, Team Foundation Server etc.
- Demo VS integrationSPCopSPDependSPMetricsSPInventoryDevelop a rule
- ObjectivesAssure that solution meets user requirementsFind bugs before deploying solution to productionAutomate tests for easier regression testingTest stress scenarios (performance testing, load testing, server failure) ChallengesUnit tests require SharePoint installation to runStandard SharePoint functionality can be affected by solutionXML code cannot be tested directly, only the resultManual tests are time-consuming
- Best PracticeBusiness Analyst should know SharePoint from a user perspectiveStructure requirements analysis based on information lifecycleStandardize syntax of requirementsQuestion and re-question the necessity of every standard SharePoint functionality changeUse tools to manage requirements i.e. Quality Center, Team Foundation Server etc.
- ObjectivesComplete installation of a SharePoint application (content, configuration, customization)Automated installation with detailed deployment logSupport uninstallationSupport upgrade of existing releasesChallengesDeployment often requires manual stepsDeployment has to be done on multiple environments (integration, acceptance, production)Deployment process over the different stages should be managed to prevent shortcuts
- Best PracticeBusiness Analyst should know SharePoint from a user perspectiveStructure requirements analysis based on information lifecycleStandardize syntax of requirementsQuestion and re-question the necessity of every standard SharePoint functionality changeUse tools to manage requirements i.e. Quality Center, Team Foundation Server etc.
- ObjectivesMaintain a stable farm environmentAllow application changes with minimal impact on rest of the farmBe able to roll back changesReduce downtimesChallengesSharePoint solutions are running run side-by-side with other custom solutionsSharePoint server updates may have negative impact on custom solutionsBugs can still occur only on production, as no SharePoint installation is exactly the sameErrors are often not detected immediately after the change
- Best PracticeBusiness Analyst should know SharePoint from a user perspectiveStructure requirements analysis based on information lifecycleStandardize syntax of requirementsQuestion and re-question the necessity of every standard SharePoint functionality changeUse tools to manage requirements i.e. Quality Center, Team Foundation Server etc.