Vývoj a nasazování řešení pro SharePoint 2010 Průvodce základními principy, možnostmi a doporučenými postupy 11. 10. 2011, Microsoft Ondřej Tučný, CEO, BoldBrick

Infrastruktura: cloud vs. on-premise Nasazení do produkce Agenda Vývoj pro SharePoint 2010 Sandboxed solutions Infrastruktura: cloud vs. on-premise Nasazení do produkce

1. Vývoj pro SharePoint 2010

Dostupné nástroje pro vývoj Microsoft Třetí strany SharePoint Designer Visual Studio InfoPath Nintex Workflow Mossquito … Web Přizpůsobení out-of-the-box vlastností Stačí browser Konfigurace Deklarativní vývoj a přizpůsobení Deklarativní nástroje třetích stran Vývoj Vývoj vlastních řešení Znovupoužitelná řešení Visual Studio a další

Porovnání standardních nástrojů Deklarativně můžete… Vyvíjet můžete… Zakládat a editovat stránky Definovat datový model Vytvářet formulářové aplikace Vytvářet komplexní workflow Editovat pokročilé nastavení web partů Vytvářet vlastní XSLT view Vlastní business logiku Vlastní sloupce Web party Event handlery Workflow aktivity WCF služby / integraci Timer joby Vlastní SPService

Client Object Model XSLT View Sandboxed solutions Zajímavé novinky v SP2010 Client Object Model ⇒ práce s Object Modelem z JS a Silverlightu XSLT View ⇒ otevírá kreativitu v deklarativnímu vývoji UI Sandboxed solutions ⇒ cesta, jak vyvíjet pro Office365 (a spousta dalšího užitečného pro vývoj: REST, PowerShell, Business Connectivity Services, Managed Metadata, vlastní SPServices, …)

XSLT View Příklad: zobrazení kandidáta (1/2) Standardní view se spoustou sloupců může být pěkně nepřehledné… Základní verze této aplikace jako open source na http://sp2010recruitment.codeplex.com/

XSLT View Příklad: zobrazení kandidáta (2/2) Základní verze této aplikace jako open source na http://sp2010recruitment.codeplex.com/

Client Object Model + XSLT View Příklad: jednoduchý workflow editor (1/2) Podobně nepřehledná situace jako u předchozího příkladu Základní verze této aplikace jako open source na http://sp2010recruitment.codeplex.com/

Client Object Model + XSLT View Příklad: jednoduchý workflow editor (2/2) Přesun položek nahoru a dolů Rušení položek Editace položek Skrývání detailů AJAX aktualizace seznamu Základní verze této aplikace jako open source na http://sp2010recruitment.codeplex.com/

Best practices pro vývoj Z reálného světa  Používejte funkce k tomu, k čemu jsou určeny  Využívejte WSP i pro jednorázová řešení  Už při vývoji myslete na deployment a upgrade  Nemodifikujte systémové soubory  Vhodně omezte kreativitu uživatelů  Na hodně aplikací stačí Blank Template

Best practices pro vývoj 1/5  Používejte funkce k tomu, k čemu jsou určeny Vyvarujte se zneužívání funkcí pro jiné než jejich primární účely Může to mít nepředvídané funkční či výkonnostní dopady Příklad: Managed metadata jsou určena pro ukládání termínů, značek Nepoužívejte je pro ukládání uživatelských dat

Best practices pro vývoj 2/5  GUID = Globally Unique Identifier GUID má být unikátní. Tečka. Používejte „Guid.NewGuid()“ nebo funkci Visual Studia Vyvarujte se výroby Guidů po „domácku“ např. odvozením z jiného Guidu Vyvarujte se opakovaného použití Guidu! A to i když vám to SharePoint dovolí

Best practices pro vývoj 3/5  Už při vývoji myslete na deployment Vhodný návrh architektury řešení, výběr nástrojů a postupů dokáže zásadně usnadnit deployment Bude vaše řešení na serveru zaručeně jediné? Typicky: Ne, nebude Je vaše řešení v něčem privilegované proti jiným? Typicky: Ne, není Obvyklé programátorské poučky platí u SharePointu dvojnásob

Best practices pro vývoj 4/5  Už při vývoji myslete na upgrade Vhodný návrh architektury řešení, výběr nástrojů a postupů dokáže zásadně usnadnit upgrade Jak se vypořádáte se změnami provedenými uživateli? Jak budete v budoucnu upgradovat data? Kolik let bude řešení asi tak žít?

Best practices pro vývoj 5/5  Nemodifikujte systémové soubory Spousta souborů v instalaci SharePointu přímo svádí k modifikaci: ASPX stránky a ASCX controly JavaScript CSS Proč to nedělat: Přestáváte mít podporu od výrobce Přestanou (v tichosti) fungovat systémové updaty Nebudete umět modifikace replikovat jinam Po čase už nebudete vědět, proč jste to dělali

2. Sandboxed solutions

Vlastní rozšíření Office365 webů Použití Vlastní rozšíření Office365 webů Bezpečnostně silně omezená řešení v on-premise nasazeních Delegace nasazení na správce site kolekcí Sandboxed řešení mají řadu restrikcí

Architektura sandboxed řešení Neovlivňuje ostatní procesy Řízení spotřeby systémových zdrojů Provádění pouze na vybraných serverech Nasazování správcem site collection Diagram převzat z http://blogs.msdn.com/b/sharepointpictures/

 Limitovaná oprávnění kódu  Vlastní typy sloupců Co v sandboxu nemůžete  Limitovaná oprávnění kódu  Vlastní typy sloupců  Web party (kromě ASP.NET)  Stránky + master page + site template  Limitované používání API  Workflow s kódem  Volání externích web servisů  Práce s file systémem  Vytváření timer jobů

Jaké máte naopak možnosti Zejména v kontextu Office365 Použití SharePoint Designeru ⇒ leccos dokážete vyřešit deklarativně bez programování Silverlight a využití Client Object Model ⇒ bohaté UI i přes jistá omezení sandboxu Hybridní řešení Azure / Office365 ⇒ SharePoint jako administrační back-end Formulářové aplikace pomocí InfoPath

Jak vytvořit web part pro sandbox 1/3

Jak vytvořit web part pro sandbox 2/3 Vytváříte standardní ASCX kontrol pomocí ASP.NET značek…

Jak vytvořit web part pro sandbox 3/3 …Visual Studio generuje C# kód pro sandbox

 RunWithElevatedPrivileges + „nebezpečná“ práva Co v sandboxu nemůžete 1/10  RunWithElevatedPrivileges + „nebezpečná“ práva Nelze elevovat oprávnění na úroveň administrátora Nelze používat reflection Nelze používat Full Trust nastavení assembly Dopady: Zapomeňte na „triky“ pomocí reflection Nemůžete si se systémem dělat, co chcete

Nelze definovat a používat vlastní typy sloupců Co v sandboxu nemůžete 2/10  Vlastní typy sloupců Nelze definovat a používat vlastní typy sloupců Nelze vytvářet vlastní editory Dopady: Jste omezení na out-of-the-box datové typy Office365: Musíte se spokojit se standardním chováním editorů

Nelze definovat a používat vlastní web party Co v sandboxu nemůžete 3/10  Web party Nelze definovat a používat vlastní web party WebPart z ASP.NET je povolena Kompozice stránky s vlastními controly probíhá také v sandboxu Dopady: Sice lze vytvářet UI, ale s omezeními Vaše web party nejsou ve stránce „first class citizen“ Komunikace s ostatními (out-of-the-box) web party nelze

 Vlastní stránky + master page + site template Co v sandboxu nemůžete 4/10  Vlastní stránky + master page + site template Minimální možnosti customizace UI Dopady: Musíte se spokojit se standardními šablonami webů To moc nevadí, protože „blank template“ je základ všeho Vaše web party nejsou ve stránce „first class citizen“ Komunikace s ostatními (out-of-the-box) web party nelze

Co v sandboxu nemůžete  Používání API 5/10  Používání API Lze používat jen část všech assembly SP a .NETu: Musí být dostupné v GAC nebo v sandboxed solution Musí dovolovat partially-trusted volající Povoleno: 12 DLL, například: Microsoft.SharePoint.dll + řada omezení Microsoft.Office.Server.dll Zakázáno: 16 DLL Microsoft.SharePoint.Taxonomy.dll Dopady: Může se snadno stát, že skončíte u konstatování „Nelze“ Věnujte v MSDN pozornost větě „Available in Sandboxed Solutions“ u jednotlivých tříd a metod

Jsou zakázána workflow s vlastním kódem Co v sandboxu nemůžete 6/10  Workflow s kódem Jsou zakázána workflow s vlastním kódem Nelze vytvářet vlastní plnohodnotné workflow aktivity Dopady: Nelze plnohodnotně vyvíjet workflow ve VS Jste omezení na deklarativní workflow (ať už pomocí SPD nebo VS) Vlastní workflow akce jsou sice možné, ale dost omezeně Office365: Nepoužívat jako workflow systém

 Volání externích web servisů Co v sandboxu nemůžete 7/10  Volání externích web servisů Nelze provádět jakoukoliv síťovou komunikaci Dopady: Nelze integrovat SharePoint s externími službami Nelze ani využívat Business Connectivity Services Office365: řešení jsou prakticky izolovaná od zbytku cloud světa

Nelze modifikovat web.config Co v sandboxu nemůžete 8/10  Práce s file systémem Nelze modifikovat web.config Nelze pracovat se soubory na disku, ani temporary Dopady: Nijak zásadní: správná SharePoint aplikace nepoužívá file systém V podstatě je to podpora dobrých praktik 

SPJobDefinition nelze používat Dopady: Co v sandboxu nemůžete 9/10  Používání timer jobů SPJobDefinition nelze používat Dopady: Nemůžete realizovat scénáře s dávkovým zpracováním dat Office365: nelze plánovaně provádět asynchronní úlohy

 Klíčové slovo „static“ Co v sandboxu nemůžete 10/10  Klíčové slovo „static“ Nelze definovat statické („globální“) proměnné (fieldy) Dopady: Nijak zásadní: správně objektově navržená aplikace má pouze velmi málo potřeb používat statické proměnné V některých případech to může být nepříjemný zádrhel

Infrastruktura: cloud vs. on-premise

Tři modely infrastruktury pro SharePoint On-Premise Private Cloud Office365

Cloud od Microsoftu: Office365 Výhody Nevýhody Žádné starosti s infrastrukturou Jednoduchá administrace a integrace s firemním AD Spolehlivá infrastruktura garantovaná Microsoftem Pay-as-you-go Včetně licencí MS Office Přirozený mobilní přístup Omezené možnosti customizace a vývoje Žádné možnosti zásahů do infrastruktury Omezení vyplývající z rychlosti připojení Omezené integrace

Smluvní garance správy Řešení na míru Pay-as-you-go Private Cloud řešení Výhody Nevýhody Smluvní SLA Smluvní garance správy Řešení na míru Pay-as-you-go SPLA licencování Přirozený mobilní přístup Vývoj na míru Infrastruktura není pod přímou kontrolou Omezení vyplývající z rychlosti připojení Složitější integrace Pronájem HW a licencí je dlouhodobě dražší

On-premise infrastruktura Výhody Nevýhody Infrastruktura pod přímou kontrolou Software pod přímou kontrolou Bezproblémové integrace Využití všech možností a variant nasazení Vývoj na míru Zodpovědnost za správu Počáteční investice Nákup hardware Nákup licencí Může být zásadní položka Složitější mobilní přístup

Kdy se hodí který model? Office365 Private Cloud On-Premise Správa Nechcete se starat o IT Nepotřebujete sofistikované centrální řízení Nechcete se starat o SharePoint Máte vlastní správu IT Potřebujete centrální správu Náklady Minimalizujete náklady na IT Využijete licencování Office pay-as-you-go Upřednostňujete rozložení nákladů v čase Stačí vám Foundation Investujete do velkých projektů Funkce Potřebujete jednoduše řešit extranety Stačí vám out-of-the-box funkce Potřebujete jednoduchý mobilní přístup Potřebujete konkrétní custom řešení Potřebujete specifické integrované řešení Potřebujete komplexní řešení pro mnoho různých využití Máte hodně specifických požadavků

Na co si dát pozor u Private Cloud řešení Bezpečnost Zálohování dat Budoucí rozšiřitelnost Propojení infrastruktur SLA na řešení jako celek Dopady změn na licencování Self-service funkce pro uživatele Multi-tenant vs. Single-tenant model Private Cloud ≠ hosting za 1000 Kč / měsíc

Nasazení do produkce

Podpora nasazování na úrovni infrastruktury Jednoduchý model Složitější model Vývojové prostředí (DEV) Testovací prostředí (TEST) Produkční prostředí (PROD) Vývojové prostředí (DEV) Integrační prostředí (INT) Akceptační prostředí (ACC) Produkční prostředí (PROD) all-in-one / standalone zjednodušené 1:1 k produkčnímu

Úskalí deploymentu: opakovatelnost Jak zajistit přenos mezi prostředími? Instalační postup + konfigurační tabulka prostředí Jak zajistit aktualizace datového modelu? Mossquito nabízí režim vývoj → porovnání → nasazení změn Vývoj Test Produkce

Úskalí deploymentu: bezpečnost Vývoj typicky probíhá s admin právy Testování už ale musí používat produkční nastavení práv SharePoint nabízí značně škálovatelný bezpečnostní model Neprovozujte produkční farmu jen s jedním účtem Zvlášť: Účet pro přístup do SQL Hlavní účet farmy Účty aplikačních poolů jednotlivých web aplikací Účty systémových servisů Účty vlastních servisů Vaše aplikace běží v kontextu různých účtů

Best practices pro nasazení Z reálného světa  Dobrý deployment začíná u vývoje  Mějte připraven rollback plán  Dokumentujte si celý proces  Neinstalujte hotfixy a service packy naslepo  Jednorázový proces… s dlouhodobými dopady  Archivujte zdrojové kódy nasazeného řešení

Best practices pro nasazování 1/4  Mějte připraven rollback plán Jak nasazení ovlivní funkce? Jak vrátíme předchozí stav funkcí? Jak nasazení ovlivní data? Jak vrátíme předchozí stav dat? Důsledně zálohujte před nasazením čehokoliv nového Akceptační prostředí 1:1 vůči produkčnímu ušetří hodně starostí

Best practices pro nasazování 2/4  Neinstalujte hotfixy a service packy naslepo Pokud používáte hodně custom řešení, testujte kompatibilitu s novými updaty (zejména service packy) Service Packy obsahují i tzv. „breaking changes” ⇒ custom řešení může přestat fungovat Service Packy mohou mít dopady na okolní infrastrukturu

Best practices pro nasazování 3/4  Jednorázový proces… s dlouhodobými dopady Špatně připravený deployment může mít nepříjemné důsledky v budoucnosti Na deployment a zejména pozdější změny se musí myslet už při vývoji

Best practices pro nasazování 4/4  Archivujte zdrojové kódy nasazeného řešení Může se stát, že budete potřebovat v budoucnu řešení instalovat do jiného prostředí vyžadující úpravy Může se stát, že budete řešení migrovat Co potřebujete archivovat: Zdrojové kódy nasazeného řešení — skutečně použitou verzi Dokumentaci pro buildování a instalaci řešení Informace o potřebných nástrojích a vývojovém prostředí

Rád zodpovím Vaše další otázky tucny@boldbrick.com Děkuji za pozornost Rád zodpovím Vaše další otázky tucny@boldbrick.com