Transcription
Lifecycle Management withSharePoint Apps and SolutionsPAOLO PIALORSI, PIASYS.COMpaolo@pialorsi.com - @PaoloPia
About Me Project Manager, Consultant, Trainer More than 40 Microsoft certification examspassed, 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/
Agenda Introduction to Application Lifecycle Management Main ALM phases from a SharePoint perspective I simply want to share with you my own experiences, collectedalong 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!
Application Lifecycle Management
Application Lifecycle Management Application lifecycle management (ALM), called also ADLM(Application Development Life-cycle Management), is the andmaintenance) of application software. It encompassesrequirements management, software architecture, computerprogramming, software testing, software maintenance, changemanagement, continuous integration, project management, andrelease n lifecycle management
Our focus today Requirements management Software architecture Computer programming (tools and techniques) Software testing Release management Software maintenance In the SharePoint world, of course!
ALM and SharePoint
ALM and SharePoint A SharePoint “application” can be: Intranet solutionsExtranet solutionsPublic facing Web Site solutionsCustom development solutionsIntegration/LOB solutionEtc. All of these kind of solutions require Lifecycle Management Today we will focus on Custom development solutions
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
Evolution of SharePoint CustomizationsFull Trust SolutionsNo real controlSandboxPartial controlSP CodeSP CodeMore custom code:aspx, dlls, webservices, GACSandboxedCustom CodeApp ModelControl, Trust, ManageSP CodeIsolated Appclient sidecodeApp code(client orserver)Host/language independentSupport is a nightmareWay too strict for developersUpgrade is quite a challengeHard to maintain and expandManagement and update easily doableper appSecuring code to run in hostedManaged by your selfEmprases reusabilityenvironments is effectively impossibleNo server side sandbox, improved CSOM
Development and Deployment OptionsFarm Full trust solutions Customizations to filesystem of servers Hosted in same processas SharePoint Server side SharePointAPI access Classic model from 2007SandboxSP Apps Declarative elements Partially trusted codeservice still included forlimitedserver sideCode basedsandboxsupportsolutionsdeprecated in Hosted in isolatedSP2013process Limited server sideSharePoint API access New Apps model Deployed from corporatecatalog or SharePointstore Manage permission andlicenses specifically Simple install andupgrade process Preferred option
“SOLUTIONS OR APPS? THAT IS THEQUESTION!”
Solutions or Apps?Office 365/SharePoint OnlineYesNew SharePointProjectIs it ok a SharePoint Appregardless the target platform?NoCreatea SharePoint AppWhat is the target platform?SharePoint on-premisesYesAnalyze requirements and defineconstraints that can tmake it possible tocrate a SharePoint AppCan you slightly changerequirements to make it aSharePoint App?NoAre the remainder requirements okfor a SharePoint app?YesIsolate requirements that need full-trustcode and create a dedicated FTC module.NoDocument and report those constraintsto your customer!Let s Startthe Project
What methodology? Waterfall Prototyping Spiral development Agile eXtreme Programming (XP) Kanban SCRUM Etc. My typical choice is a kind of “disciplined Agile approach” Upfront analysis Prototyping Agile
Requirements management
“USUALLY, JUST AFTER YOU COLLECTREQUIREMENTS, CUSTOMERS CHANGE THEM”
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 PoC using 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
Software architecture
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 ModelThe Persistence LayerThe Data Access LayerThe Business Rules and RequirementsThe Service LayerThe Presentation Layer
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 ofthe project Think about Domain Driven Development (DDD)
The Persistence Layer 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 not a good repository for large data sourcesof 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
The Data Access Layer Abstract from the physical persistence layer Allows creating a software architecture that is independent from thephysical persistence layer You will probably consume SharePoint items and documents usingthe 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 implementationdetails to the upper layers
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
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
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
Computer programming
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)
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 CSOMSome kind of Web PartsService ApplicationCustom WCF ServicesCustom 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
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 everythingYou can define pre-configured environmentsYou pay only when you use it, on a per-minute basisYou 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
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 )
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 OrdersApp style names
Software testing
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 2013 Testing Tools Performance Test How the solution performs (by dev/tester) Tools: Visual Studio 2013 Testing Tools, ANTS Performance Profiler, Fiddler
Key aspects of testing SharePoint software SharePoint Solutions Try to decouple code from UI/UX, in order to being able to automate unitand 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.
Release management
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
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 OAuth security infrastructure In Office 365 you will use Azure ACS easy path On-premises you will use Server to Server/High Trust scenario more complex
Evergreen and release cycle – Old ecific upgrade project each time new version is introducedTightly coupledSharePoint customizationsCustomizations have to be upgraded to get access on new capabilities in productWill cause additional costs during each release cycle of customizationsCustomization updates cause downtime each time something is changedComplex ALM processes for ensuring quality of the code
Evergreen and release cycle – NEW modelSP2013O16O18O17Customizations will utilize services fromSharePoint and other services, but won’tusually change out of the box services.DevelopmentYou choose when and how applications are updated.Loosly coupledSharePoint customizationsBackwards compatibility for API level to move customizations cross versionsCustomizations don’t block new capabilities from SharePointCustomizations extend, not change SharePointCustomizations can be updated with minimal impact on SharePoint
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/)
Software maintenance
“A WORKING PROGRAM IS ONE THAT HASONLY UNOBSERVED BUGS”MURPHY’S LAWS
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
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
THAT’S ALL FOLKS!
/@PAOLOPIA
thank you.SHAREPOINT AND PROJECT CONFERENCE ADRIATICSZAGREB, 10/14/2014 - 10/15/2014
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.)
