The document discusses application lifecycle management (ALM) from the perspective of SharePoint apps and solutions. It covers the main ALM phases including requirements management, software architecture, computer programming, software testing, release management, and software maintenance. Specific techniques are discussed for each phase as they relate to developing SharePoint apps and solutions, such as using Visual Studio, Office 365, and provider-hosted apps. The overall goal is to discuss best practices for managing the lifecycle of SharePoint customizations.

1. Lifecycle Management with SharePoint Apps and Solutions
PAOLO PIALORSI, PIASYS.COM
paolo@pialorsi.com -@PaoloPia

3. About Me
•Project Manager, Consultant, Trainer
•More than 40 Microsoft certification exams passed, including MC(S)M
•Focused on SharePoint since 2002
•Author of 10 books about XML, SOAP, .NET, LINQ, and SharePoint
•Speaker at main IT conferences worldwide
•http://www.piasys.com/

4. Agenda
•Introduction to Application Lifecycle Management
•Main ALM phases from a SharePoint perspective
•I simply want to share with you my own experiences, collected along more than 12 years of SharePoint projects
•Maybe sometime you will agree with me
•Maybe not … let’s discuss it while drinking some beers, in that case!

5. Application Lifecycle Management

6. Application Lifecycle Management
•Applicationlifecyclemanagement(ALM),calledalsoADLM(ApplicationDevelopmentLife-cycleManagement),istheproductlifecyclemanagement(governance,development,andmaintenance)ofapplicationsoftware.Itencompassesrequirementsmanagement,softwarearchitecture,computerprogramming,softwaretesting,softwaremaintenance,changemanagement,continuousintegration,projectmanagement,andreleasemanagement.
http://en.wikipedia.org/wiki/Application_lifecycle_management

7. Our focus today
•Requirements management
•Software architecture
•Computer programming (tools and techniques)
•Software testing
•Release management
•Software maintenance
•In the SharePoint world, of course!

8. ALM and SharePoint

9. ALM and SharePoint
•A SharePoint “application” can be:
•Intranet solutions
•Extranet solutions
•Public facing Web Site solutions
•Custom development solutions
•Integration/LOB solution
•Etc.
•All of these kind of solutions require Lifecycle Management
•Today we will focus on Custom development solutions

10. What’s your target SharePoint flavor?
•Your flavor(s) will influence the overall solution
•Microsoft SharePoint 2007 (no, please … really?!)
•Microsoft SharePoint 2010 (it happens …)
•Microsoft SharePoint 2013 (keep on running …)
•Microsoft SharePoint Online and Microsoft Office 365 (well done! )
•Hybrid Scenarios (SharePoint 2013 + SharePoint Online)
•Today the focuses are
•Microsoft SharePoint 2013
•Microsoft SharePoint Online and Microsoft Office 365
•Hybrid Scenarios

11. Evolution of SharePoint Customizations
Full Trust Solutions
No real control
Support is a nightmare
Upgrade is quite a challenge
Securing code to run in hosted environments is effectively impossible
SP Code
More custom code: aspx, dlls, web services, GAC
Sandbox
Partial control
App Model
Control, Trust, Manage
Way too strict for developers
Hard to maintain and expand
Managed by your self
SP Code
Sandboxed Custom Code
App code (client or server)
SP Code
Isolated App client side code
Host/language independent
Management and update easily doable per app
Emprases reusability
No server side sandbox, improved CSOM

12. Development and Deployment Options
Farm
•Full trust solutions
•Customizations to file system of servers
•Hosted in same process as SharePoint
•Server side SharePoint API access
•Classic model from 2007Sandbox
•Declarative elements
•Partially trusted code service still included for limited server side support
•Hosted in isolated process
•Limited server side SharePoint API access
SP Apps
•New Apps model
•Deployed from corporate catalog or SharePoint store
•Manage permission and licenses specifically
•Simple install and upgrade process
•Preferred option
Code based sandbox solutions deprecated in SP2013

13. “SOLUTIONS OR APPS? THAT IS THE QUESTION!”

14. Solutions or Apps?
New SharePoint ProjectIs it ok a SharePoint Appregardless the target platform? YesCreate a SharePoint AppLet s Startthe ProjectNoWhat is the target platform? Office 365/SharePoint OnlineSharePoint on-premisesAnalyze requirements and define constraints that can t make it possible to crate a SharePoint AppCan you slightly change requirements to make it a SharePoint App? YesNoIsolate requirements that need full-trust code and create a dedicated FTC module. Document and report those constraintsto your customer! Are the remainder requirements ok for a SharePoint app? YesNo

15. What methodology?
•Waterfall
•Prototyping
•Spiral development
•Agile
•eXtremeProgramming (XP)
•Kanban
•SCRUM
•Etc.
•My typical choice is a kind of “disciplined Agile approach”
•Upfront analysis => Prototyping => Agile

16. Requirements management

17. “USUALLY, JUST AFTER YOU COLLECT REQUIREMENTS, CUSTOMERS CHANGE THEM”

18. To gather better requirements
•Collect them in meetings with key users and matter experts
•Write a requirements document
•Let the key users and matter experts approve or fix that document
•Create a PoCusing the web browser and a sample site
•Based on the requirements gathered
•Meet users and experts again to check the result
•Fix the requirements
•Adapt and improve the PoC
•Finalize the requirements document
•Double-check the final result
•Move any other new requirement in the next project iteration
•If any, of course …

19. Software architecture

20. Architecture key aspects
•SharePoint Apps and Solutions are just another kind of software
•Share the same architectural principles of any other software
•The main pillars are
•The Domain Model
•The Persistence Layer
•The Data Access Layer
•The Business Rules and Requirements
•The Service Layer
•The Presentation Layer

21. The Domain Model
•Think about the Domain Model aside from SharePoint
•Your are developing a software solution, not “just” a SharePoint one
•Determine the entities, their relationships and cardinality
•And identify those entities that fit into the SharePoint world
•A well defined Domain Model is fundamental for the success of the project
•Think about Domain Driven Development (DDD) …

22. The PersistenceLayer
•SharePoint is for sure a good repository for documents
•Versioning, Check-in/Check-out, Templates, Metadata, Search, Etc.
•SharePoint can be a good repository for some other elements
•Contacts, Calendars, Tasks, Etc.
•SharePoint for sure is nota good repository for large data sources of relational elements
•Customers, Orders and Order Details, Etc.
•SharePoint is not an RDBMS
•As well as an RDBMS can’t easily substitute SharePoint
•Join their forces and think about both SharePoint and an RDBMS
•Just in case of need, of course

23. The Data Access Layer
•Abstract from the physical persistence layer
•Allows creating a software architecture that is independent from the physical persistence layer
•You will probably consume SharePoint items and documents using the SharePoint Client/Server Object Model
•You will probably consume RDBMS data using Entity Framework
•Or any other OR/M of your choice
•The Data Access Layer hides these choices and implementation details to the upper layers

24. The Business Rules and Requirements
•The Business Layer incorporates business rules and requirements
•Assures business integrity of data
•Applies rules
•Guarantees satisfaction of requirements
•Manages transactional context
•Even across different persistence layers
•Allows validating data, aside from the physical repository
•Ensures security rules and constraints
•Implies authorization checks

25. The Service Layer
•Allows decoupling from the Presentation Layer
•In a SharePoint Solution can be “optional”
•You typically work only server-side in full-trust code
•Often you don’t need to decouple front-end and back-end
•But you should in Service Applications, Workflows, custom WCF Services
•In Service Applications is their architecture that is natively decoupled
•In a SharePoint App can be “useful”
•To provide REST API services, as like as SharePoint/Office 365 do
•To extend workflow implementations via REST
•To support jQuery/AJAX

26. The Presentation Layer
•Provides UI to support users’ data input and reading/querying
•In a SharePoint Solution leverage standard SharePoint UI
•Web Parts
•Custom Data Views
•Custom Pages
•In a SharePoint App
•Can still be SharePoint-based, in a SharePoint-hosted app
•Often is independent from SharePoint, in a provider-hosted app
•You can leverage whatever technology you like (ASP.NET, Java, PHP, Node.js, ecc.)
•Usually is based on ASP.NET MVC
•Don’t forget User eXperience, UI without UX is a mess

27. Computer programming

28. Supporting tools
•Visual Studio 2013 regardless the model (FTC, CAM)
•Together with Team Foundation Server/Services
•Or any other Code Versioning System (CVS)
•SharePoint Solutions
•SPDisposeCheck(http://bit.ly/1xJmi8V)
•SharePoint Code Analysis Framework (http://www.spcaf.com/)
•SharePoint Apps
•SharePoint Code Analysis Framework (http://www.spcaf.com/)
•Office 365 Developers PnP (https://github.com/OfficeDev/PnP)

29. Server Object Model or CSOM?
•CSOM and REST APIs are the future
•Server Object Model is the past/legacy way of working
•Use Server Object Model
•When you can’t use CSOM
•Some kind of Web Parts
•Service Application
•Custom WCF Services
•Custom Claims Providers
•Keep an eye on Office 365 Developer PnP
•You will find a lot of answers to common doubts and myths
•Using CSOM and CAM you can do a lot of things
•Way more than you expect … and even more will come in the future

30. Development Environment
•SharePoint Solutions
•Use customer/project’s dedicated virtualized environment
•Deploy a farm, not just a single all-in-one development VM
•Consider using Azure IaaS
•You can script everything
•You can define pre-configured environments
•You pay only when you use it, on a per-minute basis
•You can deploy developers’ machines in the cloud, as well
•SharePoint Apps
•Use Office 365 Developer Edition (~100€/year)
•Use a dedicated development machine for each and every developer
•In both scenarios: consolidate code through TFS/CVS

31. Roll your own Frameworks
•Reuse code as much as you can
•Not through copy and paste …
•… but using Object Oriented Programming
•Create libraries of code
•Regardless your target is a solution or an app
•Share libraries across multiple projects
•To increase return of investments and overall profits for you
•Deploy libraries carefully (more about this topic later …)

32. Common Sense Rules and Conventions
•Clearly comment code
•With comments that make sense …
•Use company-wide naming conventions
•Name shared framework types with your company name
•PiaSys.Common.Utilities.*
•Name customers’ specific types with their company name
•CustomerName.ProjectName.*
•Avoid SharePointApp1 style names
•As well as OrdersAppstyle names

33. Software testing

35. Testing practices
•Unit Test
•Code testing, usually automated
•Tools: Visual Studio 2013 Testing Tools
•Integration Test
•Modules combination, automated and/or manual (by dev/tester)
•Tools: Visual Studio 2013 Testing Tools
•Functional Test
•Based on test cases (by tester)
•Tools: Visual Studio 2013Testing Tools
•Performance Test
•How the solution performs (by dev/tester)
•Tools: Visual Studio 2013Testing Tools, ANTS Performance Profiler, Fiddler

36. Key aspects of testing SharePoint software
•SharePoint Solutions
•Try to decouple code from UI/UX, in order to being able to automate unit and integration tests
•Create a virtualized project-dedicated testing environment
•Each on-premises farm has its own specific constraints
•SharePoint Apps
•Use Microsoft Office 365 instead of an on-premises environment
•Use the same tenant, with different site-collections (DEV, TEST, PROD)
•Different tenants can have different versions of the platform
•Keep in mind that SharePoint Online is v.16 while on-premises is v.15
•Only in case of need use an on-premises environment
•Custom authentication
•Integration with full-trust solutions or legacy systems
•Etc.

37. Release management

38. Releasing SharePoint Solutions
•Release dedicated WSPs for framework libraries
•Release dedicated WSPs for specific customer/project solutions
•Avoid releasing a unique all-in-one WSP
•Be modular and live modular 
•Upgrade will be easier and less error prone
•Automate release and upgrade phases through PowerShell
•Easier to publish packages on testing, staging, production, etc.
•Easier to automate release/deployment phases

39. Releasing SharePoint Apps
•Prefer provider-hosted apps, for real business solutions
•You can manage release as like as any other software solution
•Use SharePoint-hosted apps just in a few cases
•Workflow-only apps
•Apps based on SharePoint data only
•Very simple and only JS/jQuery-based apps
•Use Corporate App Catalog for customer-dedicated apps
•Don’t use Developer Site collection for testing and production
•Use Azure Web Sites or Azure WebRole(PaaS) for Office 365
•Consider using Azure for on-premises scenarios, as well
•Mind the OAuthsecurity infrastructure
•In Office 365 you will use Azure ACS … easy path
•On-premises you will use Server to Server/High Trust scenario … more complex

40. Evergreen and release cycle – Old model
SP2013 O16 O17 O18
Tightly coupled
SharePoint customizations
Upgrade Upgrade Upgrade Upgrade
Specific upgrade project each time new version is introduced
Customizations have to be upgraded to get access on new capabilities in product
Will cause additional costs during each release cycle of customizations
Customization updates cause downtime each time something is changed
Complex ALM processes for ensuring quality of the code

41. Evergreen and release cycle – NEW model
SP2013
Loosly coupled
SharePoint customizations
O16 O17 O18
Development
You choose when and how applications are updated...
Backwards compatibility for API level to move customizations cross versions
Customizations don’t block new capabilities from SharePoint
Customizations extend, not change SharePoint
Customizations can be updated with minimal impact on SharePoint
Customizations will utilize services from
SharePoint and other services, but won’t
usually change out of the box services.

42. Release documentation, as well
•Describe the architecture
•Define and design the final topology
•Define the procedures
•Deployment
•Backup, restore, and recovery
•Upgrade
•Release users’ manuals, if covered by the budget
•Available tools:
•Microsoft Visio
•Microsoft Word
•SPDocKit(http://www.spdockit.com/)

43. Software maintenance

44. “A WORKING PROGRAM IS ONE THAT HAS ONLY UNOBSERVED BUGS” MURPHY’SLAWS

45. Tracking bugs, issues, change requests
•Use a software tool to track bugs, issues, and change requests
•For instance you can use TFS and its web-based interface
•It is fully integrated with the development/maintenance process
•Can be measured and monitored
•Give a TFS account to your customers, if you can ...
•Let them input work items and moderate them

46. Releasing Updates and Fixes
•Ship fixes and new features through dedicated milestones
•Learn from the others (mainly from Microsoft)
•Service Pack: all previous bug fixes and new features
•Cumulative Update: bug fixes
•Public Update: required and/or security fixes (mandatory)
•Accustom your customers to wait for stable minor and major releases
•Avoid releasing code on a daily-basis
•Take care of complete testing, pre-production/staging validation, release
•SharePoint Solutions
•Schedule releases to avoid farm down-time (IISRESET, process recycle)
•SharePoint Apps
•Keep in mind app-related events and remote event receivers
•One more time … prefer provider-hosted apps to reduce down-times

47. THAT’S ALL FOLKS!

48. questions?
HTTP://WWW.SHAREPOINT-REFERENCE.COM/BLOG/
@PAOLOPIA

49. thank you.
SHAREPOINT AND PROJECT CONFERENCE ADRIATICS
ZAGREB, 10/14/2014 -10/15/2014