Upload
others
View
31
Download
0
Embed Size (px)
Citation preview
Lifecycle Management with
SharePoint Apps and SolutionsPAOLO PIALORSI, PIASYS.COM
[email protected] - @PaoloPia
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/
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!
Application Lifecycle Management
Application Lifecycle Management
• Application lifecycle management (ALM), called also ADLM(Application Development Life-cycle Management), is the productlifecycle management (governance, development, andmaintenance) of application software. It encompassesrequirements management, software architecture, computerprogramming, software testing, software maintenance, changemanagement, continuous integration, project management, andrelease management.
http://en.wikipedia.org/wiki/Application_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 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
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 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 CodeApp 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
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 2007
Sandbox
• 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
“SOLUTIONS OR APPS? THAT IS THE
QUESTION!”
Solutions or Apps?
New SharePoint Project
Is it ok a SharePoint Appregardless the target platform?
Yes
Create a SharePoint App
Let s Startthe Project
NoWhat is the target platform?
Office 365/SharePoint Online
SharePoint on-premises
Analyze requirements and define constraints that can t
make it possible to crate a SharePoint App
Can you slightly change requirements to make it a
SharePoint App?
Yes
No
Isolate 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?
Yes
No
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 COLLECT
REQUIREMENTS, 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 Model
• The Persistence Layer
• The Data Access Layer
• The Business Rules and Requirements
• The Service Layer
• The 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 of the 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 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
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
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 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
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
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 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.
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 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
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.
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 HAS
ONLY 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!
questions?
HTTP://WWW.SHAREPOINT-REFERENCE.COM/BLOG/
@PAOLOPIA
thank you.
SHAREPOINT AND PROJECT CONFERENCE ADRIATICS
ZAGREB, 10/14/2014 - 10/15/2014