SPALM - SharePoint Application Lifecycle Management Praxisbeispiele für durchgängige SharePoint Entwicklungsprozesse
Vorstellung Vorstellung Torsten Mandelkow Diplom-Informatiker(FH) Seit 2007 bei Steria Mummert Mehrjährige SharePoint-Erfahrung als Berater, Architekt, Entwickler Kernkompetenzen Architekturen von großen, globalen SharePoint-Farmen Einführung von SharePoint-Entwicklungsprozessen in Unternehmen Kontakt: torsten.mandelkow@steria-mummert.de 21.01.2010 3
Das Unternehmen Steria: Beratung, IT- und Outsourcing Services Off-/Nearshore in Indien, Osteuropa und Marokko Präsenz in Europa Belgien Dänemark Deutschland Frankreich Hongkong Vor Ort in Asien Indien Präsenz in 16 Ländern... Luxemburg Marokko Norwegen Österreich Polen Singapur Spanien Schweden Schweiz UK 21.01.2010 4
Das Unternehmen Ein Top 10 Player in Europa 1,8 Mrd. Umsatz (Top 10 in Europa) 19.000 Mitarbeiter Präsenz in Europa 25% Mitarbeiter in Indien (größter Anteil für ein europäisches Unternehmen) Off-/Nearshore in Indien, Osteuropa und Marokko Vor Ort in Asien 21.01.2010 5
Das Unternehmen Leistungsstarke, kundennahe Organisation Präsenz in Deutschland und Österreich Off-/Nearshore in Indien, Osteuropa und Marokko Präsenz in Europa Vor Ort in Asien Berlin Düsseldorf Frankfurt Hamburg Köln Leipzig München Münster Wien 21.01.2010 6
Das Unternehmen Marktposition Ranking 2008 TOP 15 der Managementberatungs-Unternehmen in Deutschland 2008 Unternehmen Umsatz in Mio. Euro 2008 im Inland 1 McKinsey & Company Inc. Deutschland, Düsseldorf *) 645,0 2 Roland Berger Strategy Consultants GmbH, München *) 398,0 3 The Boston Consulting Group GmbH, Düsseldorf/München *) 369,0 4 Deloitte Consulting GmbH, Hannover 286,0 5 Booz & Company GmbH, Düsseldorf *) 1) 262,0 6 BearingPoint GmbH, Frankfurt am Main *) 246,0 7 Steria Mummert Consulting AG, Hamburg 239,0 8 Capgemini Consulting, Berlin 2) 231,0 9 Oliver Wyman Group, München *) 228,0 10 A.T. Kearney GmbH, Düsseldorf 209,0 11 Bain & Company Germany Inc., München 193,0 12 Droege International Group AG, Düsseldorf *) 3) 122,0 13 Horváth AG (Horváth & Partners-Gruppe), Stuttgart 83,1 14 Simon, Kucher & Partners GmbH, Bonn *) 80,7 15 Mercer Deutschland GmbH, Frankfurt am Main *) 79,5 Quelle: Lünendonk, 2009 *) Daten teilweise geschätzt 21.01.2010 7 1) Bis 05/2008 Booz Allen Hamilton GmbH, Veränderung durch SMC_Unternehmen_20091202.ppt Split des Unternehmens beeinflusstt 2) Ohne Steria IT-Beratung Mummert und Systemintegration Consulting AG 3) Umsatz inkl. Erfolgshonorare
Das Unternehmen Kompetenz in Microsoft Technologien Steria Mummert Consulting AG Enge Microsoft Partnership Information Worker Custom Development TFS Inner Circle Partner Team System Quality Board member
SPALM SPALM = SharePoint ALM Architect Designer Developer Tester Durchgängiger SharePoint Entwicklungsprozess Automatisierung wiederkehrender Prozesse Nachvollziehbarkeit aller Änderungen Business Analyst Project Manager 21.01.2010 9
SPALM SPALM = SharePoint ALM Architect Designer Developer Tester Durchgängiger SharePoint Entwicklungsprozess Automatisierung wiederkehrender Prozesse Nachvollziehbarkeit aller Änderungen Business Analyst Project Manager 21.01.2010 10
Agenda Ausgangspunkte ALM Besonderheiten im SharePoint Umfeld Wie weit hilft eine Unterstützung durch VS 2010 Was muss man noch manuell oder automatisiert machen Deployment Quality Assurance Anforderungen Architektur Development Test 21.01.2010 11
Agenda Anforderungen Anforderungen Deployment Architektur Quality Assurance Development Test 21.01.2010 12
Anforderungserhebung Anforderungserhebung Ziele: Detailierte Analyse der Anforderungen Stakeholderanalyse Größtmögliche Abdeckung des strukturierten Systems, Unterschiedliche Systemrollen, Unterschiedliche organisatorische Position, Rechtliche Relevanz (Betriebsrat, Datenschutz etc.). Anforderungsanalyse Anforderungen erfassen (Workshop, Interview, Umfrage) Anforderungen verfeinern (Ist-Analyse, Gap-Analyse, angrenzende Systeme) Anforderungen konsolidieren / reviewen / abstimmen Anforderungen priorisieren (fachlich, technisch, strategisch) Spezifizieren 21.01.2010 13
Anforderungserhebung Anforderungserhebung Besonderheiten Technisches Wissen bei Anwendern vorhanden -> Anwender formulieren häufig sehr technisch Homogenität der Plattform: Anforderungen wiederholen oder ähneln sich Generelle Anforderung: Nah am Standard Vermeidung von Zusatzentwicklung, wenn ähnliche Funktion bereits vorhanden Erleichterung einer späteren Migrierbarkeit 21.01.2010 14
Anforderungserhebung SMC Best Practices Erhebungsmethoden Einsatz eines abstrakten Abfragerasters (z.b. Informationraster) Formulierung mit Hilfe einer Anforderungsschablone ( Das System muss dem User die Möglichkeit bieten Metadaten einzugeben. ) Funktionales Clustering der Anforderungen (z.b. Dokumenten Management, Personalisierung, Suche, Navigation etc.) 21.01.2010 15
Anforderungserhebung RE-Erfahrungen in MOSS Projekten Klaren RE Prozess vereinbaren Frühe Beteiligung der Fachabwendern Demonstration von MOSS Standard vor Fachanwendern vereinfacht RE Prototyping schafft Transparenz der Anforderungen Design und Layout ist die halbe Miete 21.01.2010 16
Systemsicht Anwendersicht Anforderungserhebung Best Practice: Abfrageraster Abstrakte Einordung der Anforderungen mit Hilfe des SMC Informationrasters Abfragebereich Information aufbereiten Information verwalten Information verteilen Information suchen/finden Information austauschen Information integrieren Information schützen Beschreibung Information für die Zielgruppen bearbeiten, überarbeiten und mit einem geeigneten Layout versehen. Information strukturieren und organisieren. (Hierarchie, Metadaten,..) Aufbereitete Information den Zielgruppen zur Nutzung bereitstellen. Gewünschte Information finden und nutzen. (Suche, Navigation usw.) Interaktiver Informationsaustausch zwischen Anwendern. Information mit anderen Systemen über eine technische Schnittstelle austauschen. Unberechtigten Zugriff auf Information verhindern. Information sammeln Zugriff auf Informationen protokollieren und aufbereiten. 21.01.2010 17
Anforderungserhebung Best Practise: Anforderungsschablone Abstrakte Einordung der Anforderungen mit Hilfe des SMC Informationrasters Das System muss - fähig sein <Objekt & Ergänzung des Objekts> <Prozesswort> sollte <wem?> die Möglichkeit bieten Beispiele Das System muss dem Redakteur die Möglichkeit bieten Metadaten einzugeben. Das System sollte eingegebene Metadaten abhängig vom Dokumenttyp prüfen. Das System muss fähig sein Organisationsdaten aus SAP zu importieren. 21.01.2010 18
Agenda Architektur Anforderungen Deployment Architektur Quality Assurance Development Test 21.01.2010 19
Architektur Ziele und Besonderheiten Häufige Ziele Architektur von Lösungen, die nah am Standard sind (Vermeidung von Zusatzentwicklungen) keine Verschlechterung der Performance und Stabilität Abgrenzung zu anderen Lösungen und Reduzierung von Abhängigkeiten Besonderheiten Wiederkehrende Anforderungen müssen umgesetzt werden Viel SharePoint-Fachwissen notwendig Erfahrung wichtig: vieles, was gehen soll, geht doch nicht wie beschrieben ASP.NET Kenntnisse sehr hilfreich 21.01.2010 20
Architektur SMC Best Practices Wiederverwendbarkeit von Lösungen ermöglichen Entwicklung im Rahmen von SharePoints Featuremodell (nicht alles in ASP.NET neu machen) Verwendung von Pattern für die Entwicklung (ServiceLocator, RepositoryPattern), analog zu Empfehlung von Microsoft Klassifizierung von Anwendungsfällen (z.b. Contentorientiert, Applikationsorientiert, Listenorientiert usw.) Testbarkeit von Lösungen ermöglichen (z.b. MVP- Pattern für Webparts) 21.01.2010 21
Agenda Development Anforderungen Deployment Architektur Quality Assurance Development Test 21.01.2010 22
Development Ziele Unterstützung des Entwicklers (Developer Productivity) wichtig Konformität des erstellten Codes zur Microsoft Vorgaben sicherstellen Konformität zu Unternehmensvorgaben (Aufbau der Projekte, Namenskonventionen) sicherstellen Hohe Codequalität (Performance, Stabilität) erreichen Managebarkeit der Lösung sicherstellen (zentrale Komponenten z.b. für Logging, Konfiguration usw. bereitstellen) 21.01.2010 23
Development Besonderheiten SharePoint Code besteht aus vielen einzelnen Dateien, die untereinander referenziert sind Code besteht viel aus.xml, der häufig manuell erstellt werden muss Referenzen zwischen Artefakten läuft häufig über Guids, die vom Entwickler (mühsam) ausgelesen werden müssen Stark eingeschränkte Freiheitsgrade innerhalb SharePoint Viel Spezialwissen notwendig 21.01.2010 24
Development Demo Vorstellung SPSF SharePoint Software Factory (Eigenentwicklung, basierend auf Microsoft Guidance Automation Extension (GAX)) 21.01.2010 25
Agenda Build Anforderungen Deployment Architektur Quality Assurance Development Test 21.01.2010 26
Build Ziele Zentraler Build einer Lösung Erzeugung eines installierbaren Packages Ablage und Versionierung des Buildergebnisse, um es jederzeit verwenden zu können Build gegen eine Konfiguration analog zur produktiven Farm (keine zusätzlichen DLLs) Build eines Releases (keine Debug-Lösung geht produktiv) Build von den Artefakten zum installierbarem Package 21.01.2010 27
Build Besonderheiten Erstellung eines installierbaren Packages häufig sehr aufwändig Häufige Lösung: Erstellung von Batch- Dateien, Konfigurationsdateien für Parameter und URLs u.ä. Erstellung eines MSIs meist nicht zielführend 21.01.2010 28
Build Demo Vorstellung SPSF SharePoint Software Factory Erstellung eines Setuppackages 21.01.2010 29
Agenda Testing Anforderungen Deployment Architektur Quality Assurance Development Test 21.01.2010 30
Testing Ziele Hauptziel: Automatisierung von Tests Regressionstests: Funktionieren noch alle bestehenden Applikationen, wenn neue Applikationen oder ein Patch installiert werden Funktionale Tests: sind die Anforderungen des Business erfüllt Smoke Tests: Minimaler Test, um die Grundfunktionen zu testen, z.b. nach einem Deployment Performance Tests: Wie verändert sich die Performance durch Installation einer Applikation oder Veränderung der Konfiguration 21.01.2010 31
Testing Besonderheiten Starke Homogenität von Lösungen Standardtests sind möglich, z.b. Standard TeamSite-Test: Create Subsite, Upload Document, Create List usw Wiederverwendbarkeit von Tests ist möglich SharePoint ist webbasiert Testtool muss entsprechende Funktionen von SharePoint unterstützen (z.b. AJAX, verschiedene UIs, WebDav usw.) Großes Problem: Unittests Unittests sind sehr schwierig bis unmöglich: Mocking von SharePoint-Objekten nur über Drittanbieter, z.b. TypeMock 21.01.2010 32
Testing Demo Vorstellung: Durchführung von parametrisierbaren Webtests (basierend auf VS.NET Webtests und MSBuild/MSTest.exe) 21.01.2010 33
Agenda Quality Assurance und Code Analyse Anforderungen Deployment Architektur Quality Assurance Development Test 21.01.2010 34
Code Analyse Ziele einer Code Analyse Analyse des Codes, z.b. Sicherheitsverstöße (CAS- Policies, RunWith- ElevatedPrivileges) Supportability der SharePoint Farm nicht gefährden Verstöße gegen Best practices (MS-Vorgaben, Erfahrungswerte) Verstöße gegen allgemeine Vorgaben (Unterstützung von Multilanguage, Namenskonventionen) 21.01.2010 35
Code Analyse Besonderheiten für SharePoint Entwicklungsergebnis besteht nur zu einem Teil aus C#-Code Großer Teil besteht aus XML (feature.xml, manifest.xml, usw.) Entwicklung ist verteilt auf viele einzelne Artefakten (XML, Bilder, CSS, DLL usw.) Hohe Abhängigkeit zwischen Artefakten, verteilt auf einzelne Dateien (z.b. Feature referenziert einen ContentType) 21.01.2010 36
Code Analyse Anwendungsfälle Code Analyse unterstützt z.b. Quality Assurance (Zertifizierung einer WSP- Lösung) Prüfung auf Verwendbarkeit als Sandboxed Solutions, Prüfung auf Supportlevel (Silver, Gold, Platinum) Prüfung auf WSS oder MOSS- Abhängigkeiten Prüfung von Drittanbieterlösungen oder externen WSP 21.01.2010 37
Code Analyse Demo Toolbasierte Code Analyse auf Basis einer Eigenentwicklung ShareCop 21.01.2010 38
Code Analyse Code Metriken Messbarkeit von SharePoint Applikationen mit Zahlen, z.b. Anzahl von Features, Worflows, ContentTypes etc. Anzahl von externe Abhängigkeiten Anzahl von Dateien in einem WSP- Package Ziele Supportability Erkennen, ab wann wird eine Lösung nicht mehr verwaltbar 21.01.2010 39
Code Analyse Dependency Management Verwaltung bzw. Analyse der Abhängigkeiten zwischen Applikationen und Artefakten Notwendig für Aktualisierung von Komponenten oder Deinstallation Beispiel: Feature X aus Applikation Intranet 2.0 referenziert Feature Y aus Applikation Compontents 1.0 Problem: Abhängigkeiten stehen im Code, in XML-Dateien oder sind gar nicht erkennbar (z.b. durch late binding ) 21.01.2010 40
Code Analyse Demo Toolbasierte Überprüfung von Entwicklungscode auf Basis einer Eigenentwicklung ShareLog 21.01.2010 41
Agenda Deployment Anforderungen Deployment Architektur Quality Assurance Development Test 21.01.2010 42
Deployment Ziele Automatisierte Verteilung einer Applikation in einer SharePoint Farm Verteilung eines Installationspakets durch mehrere Server (DEV, Staging, Produktion) Deinstallation einer Applikation soll möglich sein (möglichst spurlos) Häufig auch Deployment von Konfigurationsänderungen notwendig Test Integration Produktion 21.01.2010 43
Deployment Besonderheiten Applikation besteht häufig aus mehreren WSPs, die deployed werden müssen Installationspaket benötigt häufig Parameter (z.b URLs für das Deployment), deshalb muss das Installationspaket parametrisierbar sein Nachträgliche Konfigurationsschritte sind notwendig, z.b. ActivateFeature, Anpassungen der Suchkonfigurationen o.ä. Bei Aktualisierung eines Applikation (z.b. Version 2.0) sind häufig sehr lang laufende Aktualisierungen notwendig (z.b. zur Aktivierung eines neues Features in allen bestehenden Webs) 21.01.2010 44
Deployment Demo Vorstellung MSBuild Deployment Designer (Eigenentwicklung) 21.01.2010 45
Zusammenfassung ALM ist wichtig für professionelle Entwicklung im Unternehmen Anforderungen VS 2010 ist unabdingbar für Entwicklung im Team und für große Projekte Deployment Architektur Besonderheiten von SharePoint machen durchgängiges ALM schwierig Quality Assurance Development VS.NET 2010 bringt gute Unterstützung in einigen Bereichen Test 21.01.2010 46