Entwickler- und Administratorenkräfte vereinen

SharePoint DevOps – ein Fahrplan
Keine Kommentare

Zum Thema DevOps gibt es in der Fachwelt zahlreiche Theorien, Definitionen, Beispiele und Ratschläge. Im Zusammenhang mit Microsoft SharePoint Server gibt es allerdings diverse Herausforderungen, wie beispielsweise die Komplexität der Plattform mit ihren diversen Services, Timer-Jobs, 3rd-Party-Produkten oder die Tatsache, dass in der Regel eine SharePoint-Farm mehrere Applikationen und Use Cases hostet, die sich die Plattform und Dienste teilen.

Seit einigen Jahren geistert der DevOps-Trend durch die IT-Landschaft und verspricht, das Heilmittel für den ewigen Konflikt zwischen Entwicklung und Betrieb sowie Administratoren zu sein, um mehr Qualität zu schaffen und Fachfunktionen schneller implementieren, testen und an die Endanwender ausrollen zu können. Früher haben Entwickler im Projektmodus ihre Applikationen oder Artefakte dem Betrieb mit einer entwicklertypischen Minimaldokumentation vor die Füße geworfen und sind dann ins nächste Projekt entschwunden. Dem Administrator gelang zwar häufig das initiale Deployment, aber wenn es um Themen wie Maintenance, Bugfixing oder gar Produktpflege ging, waren häufig keine Entwickler mehr greifbar und die fühlten sich auch nicht mehr für die bereits implementierte Applikation verantwortlich. Die Trennung von Betrieb und Projektorganisation, in der die Entwickler agieren, führte häufig zu langwierigen Releasezyklen von Anwendungen. Einige der großen monolithischen Anwendungen bekommen bis heute nur ein Major Release pro Jahr und ein Minor Release pro Quartal.

Mit DevOps sind die folgenden Kernziele beziehungsweise Erwartungen verknüpft:

  • Hoher Automatisierungsgrad senkt die Querschnittsaufwände und reduziert die Time-to-Market
  • Richtige Integration von Entwicklern im Betrieb führt dazu, dass sie dauerhaft für die von ihnen entwickelten Assets Verantwortung übernehmen
  • Erhöhung der Qualität der Softwareentwicklung bei effizienteren Prozessabläufen

Für Entwickler gibt es die Herausforderung, sich verstärkt mit den Belangen des Betriebs, der IT-Sicherheit und -Infrastruktur auseinanderzusetzen. Für Administratoren hingegen sind Infrastructure as Code, Continuous Integration beziehungsweise Continuous Delivery und automatisierte Tests neue Bereiche, die es zu berücksichtigen gilt und die auch erlernt werden müssen.

BASTA! Spring 2020

Dr. Holger Schwichtenberg

Von .NET Framework zu .NET Core migrieren oder nicht migrieren, das ist hier (nicht die einzige) Frage!

mit Dr. Holger Schwichtenberg (www.IT-Visions.de/5Minds IT-Solutions)

Rainer Stropek

C#-8- und .NET-Core-3-Workshop

mit Rainer Stropek (software architects/www.IT-Visions.de)

Adrienne Tacke

Azure Automation: The Good Parts

mit Adrienne Tacke (Adrienne Tacke)

Abgesehen von neuen unterstützenden Tools wie Azure DevOps, ehemals Visual Studio Team Services, ist DevOps vor allem eine organisatorische Herausforderung, im Rahmen derer sich Prozesse, Regeln und Verantwortlichkeiten ändern. Seinem bisherigen Entwicklerteam lediglich Administrationsrechte im Produktionsbetrieb zu geben und das Team jetzt DevOps zu nennen, wird nicht die erhofften Benefits bringen. Bei Amazon zum Beispiel gibt es für die diversen AWS Services, aber auch für die Shophomepage, diverse 2-Pizza-Produktteams, die verantwortlich für einzelne Services oder Komponenten sind. Die werden dann sehr häufig – teilweise täglich – mit neuen Funktionen aktualisiert.

Herausforderung SharePoint

Microsoft SharePoint ist für eine Software quasi ein Dinosaurier: Bald zwanzig Jahre alt und über die Jahre enorm an Funktionen und Komplexität gewachsen. Viele Unternehmen nutzen SharePoint als Plattform für Zusammenarbeit, Dokumentenmanagement und Line-of-Business-Prozesse, aber auch für individuelle Applikationen. Eins der Key Learnings aus der SharePoint-Boomphase nach 2007 ist es, eine geeignete Governance zu definieren, darunter Informationsarchitektur, Verantwortlichkeiten, Rollen und Berechtigungen sowie Prozesse, um ein nicht mehr zu managendes Chaos von Websites, Apps, Anwendungen und (toten) Daten zu vermeiden und das System betriebs- und supportfähig zu halten. Dabei spielt es kaum eine Rolle, ob man ein SharePoint-System on premises oder online nutzt, für nur wenige oder zigtausende Anwender – die Herausforderungen bleiben ähnlich. Selbst ein wenig genutztes SharePoint-System benötigt schon Aufmerksamkeit hinsichtlich diverser betrieblicher Aspekte:

  • Back-up und Restore
  • Monitoring: Überwachung von Systemressourcen und Logs
  • regelmäßiges Patching
  • Health Checks
  • Support

Dazu kommen in der Regel noch unternehmensspezifische Anforderungen, die nicht selten dazu führen, dass 3rd-Party-Tools wie das Workflowtool Nintex eingesetzt oder ganze Anwendungen und Apps programmiert werden. Das können bei On-Premises-SharePoint-Systemen sogar Anwendungen sein, die noch das Server-side Object Model nutzen und Programmcode direkt auf dem Server ausführen, oder aber Apps, die mit unterschiedlichem Client-side-Code (in der Regel JavaScript) implementiert werden, bis hin zu Schnittstellen zu Drittsystemen wie SAP, Dynamics oder DOMEA-basierte Systeme. Egal, ob kommerzielles 3rd-Party-Tool für SharePoint oder selbstimplementierte Anwendung – das Aufgabenspektrum für den Administrator, der die Systemstabilität gewährleisten soll, erweitert sich enorm. Häufig wissen die Administratoren auch gar nicht, welche Apps deployt wurden, weil Anwender sogenannte Single Page Applications und diverse JS-Skripte quasi wie Content über das SharePoint-Web-UI hochladen können. Inzwischen sind die Programmiermodelle und Frameworks bei SharePoint sehr vielfältig geworden. Mit JavaScript können ganze Anwendungen per Client-side API oder REST-Webservice auf nahezu alle Funktionen des SharePoint-Systems zugreifen.

Folgende Herausforderungen ergeben sich häufig in der Praxis – nicht nur in On-Premises-Systemen, sondern teilweise auch in der Cloud:

  • Serverseitige Lösungen (WSP solutions), die Einfluss auf die Systemstabilität haben können (bei On-Premises-SharePoint-Systemen)
  • Keine einheitlichen Entwicklungsstandards, wie zum Beispiel Codedokumentation, Versionierung, Branching-Modell und Framework-Vorgaben
  • Kein definierter Deployment-Prozess, manuelle Deployments, testen und konfigurieren von Hand
  • Erhöhter Abstimmungsbedarf zwischen Entwicklern, Betrieb und Product Owner
  • Langwieriger Prozess bis Applikationen, Fachfunktionen oder Updates beim Endanwender ankommen
  • Auch clientseitiger Code, der im Browser ausgeführt wird, kann über REST und Client-side API Frameworks die SharePoint-Systeme unter Last setzen, selbst wenn diverse Schutzmechanismen wie etwa Request Throttling eingebaut sind
  • Ausfallsichere SharePoint-Systeme sollen 24/7 laufen und quasi keine Wartungsfenster brauchen

Damit ein DevOps-Team auch SharePoint-Systeme in Enterprise-typischen Größenordnungen von beispielsweise 40 Serverfarmen, 400 Servern beziehungsweise VMs, 100 Terabyte Netto-Content in den SharePoint-Datenbanken und 200 000 weltweit verteilten Anwendern sowie dutzende Applikationen managen kann, ist ein Mindestmaß an Governance und eine Toollandschaft unerlässlich.

How-to – ein praktischer Guide

Die folgenden Ausführungen beziehen sich nicht notwendigerweise nur auf SharePoint, sondern lassen sich auch auf die Entwicklung normaler (Web-)Applikationen anwenden, da das SharePoint-Entwicklungsframework inzwischen auf offene Standards, Technologien und Tool-Chains setzt.

Im Folgenden werden sowohl organisatorische als auch technologische Maßnahmen empfohlen, die je nach Situation und Personalstärke auf die Gegebenheiten im eigenen Unternehmen angepasst werden müssen. Dabei spielt es keine Rolle, ob man ein SharePoint-Online-System hat oder es on premises betreibt (Abb. 1).

Abb. 1: Branch-Policy-Einstellungen in Azure DevOps

Abb. 1: Branch-Policy-Einstellungen in Azure DevOps

Organisatorische Empfehlungen:

  • DevOps-Team erstellen, bestehend aus (SharePoint-)Entwicklern, Architekt, Administratoren, Tester und Servicemanager, der auch die Rolle des Product Owners der Plattform annehmen kann
  • Die Hoheit über das System liegt beim DevOps-Team, das seine To-dos verwaltet – sowohl reguläre Day-by-Day-Aufgaben als auch Projekt-, Maintenance- und Weiterentwicklungsaufgaben in Backlog Items
  • Priorisierung und Verwaltung der Backlog Items steuert der Servicemanager
  • Das Team nutzt eine agile Vorgehensweise wie Scrum, plant Sprints und hält Daily Scrums ab
  • Zusätzliche SharePoint-Projekte können nur unter Einbindung der DevOps-Teams realisiert werden
  • Ein Softwarearchitekt oder Senior-Entwickler gibt im Vier-Augen-Prinzip den Code frei, den der Entwickler per Pull Request übermittelt hat
  • Für Deployments auf dem Produktionssystem in der Release-Pipeline entsprechende Freigaben und Benachrichtigungen einrichten (Abb. 2).
  • Festlegung eines einheitlichen Standards für Versionsnummern und Verwendung von Tags in Git zum Festlegen der Version im Code-Repository (z. B. Master und Release-Branches, Abb. 3); diese können auch für die Assembly-Versionierung genutzt werden
Abb. 2: Beispiel einer Release-Pipeline über mehrere Stages

Abb. 2: Beispiel einer Release-Pipeline über mehrere Stages

Abb. 3: Einheitliche Versionsnummern in Tags helfen, die Übersicht zu behalten

Abb. 3: Einheitliche Versionsnummern in Tags helfen, die Übersicht zu behalten

Technologische Empfehlungen:

  • Verpflichtende Coding-Guidelines, darunter Namensräume, Codedokumentation und Strukturstandards
  • Git als Code-Repository-Standard
  • Einrichten von einheitlichen Branch Models wie Gitflow und Festlegung von Branchpolicies (Textkasten: „Branch Policies in Azure DevOps konfigurieren“)
  • Verpflichtendes Work/Backlog Item Assignment: kein Code-Check-in ohne Verknüpfung zu der Anforderung beziehungsweise dem Task
  • Für bessere Transparenz: Extension installieren zum Generieren von Markdown-Beschreibungen und Release-Notes zu jeder Version aus den verknüpften Work oder Backlog Items
  • Einrichtung von Build Pipelines; alle entwickelten Apps und Applikationen implementieren die gleichen Schritte zum Builden, Paketieren, Versionieren und für Quality Gates wie beispielsweise die Rencore-SharePoint-Plattform
  • Automatisierte Tests, Unit-Tests, Coded-UI-Tests zur Build-Zeit
  • Infrastructure as Code: Azure-ARM-Templates oder Desired State Configuration nutzen, damit die zugrunde liegende Infrastruktur dem Sollzustand entspricht und alle Voraussetzungen installiert sind [1]
  • Automatisierte Deployments über mehrere Stages: Deployments sind vollständig geskriptet, umgebungsspezifische Konfiguration per Stage in TFS-Variablen
  • Nach dem Deployment: Ausführen von automatisierten Regressionstests pro SharePoint-Applikation, beispielsweise mit Selenium oder Tosca; sehr nützlich, auch wenn nur kleine Fehler gefixt oder Patches eingespielt wurden

Branch Policies in Azure DevOps konfigurieren

Ein standardisiertes Branch-Modell hat den Vorteil, dass das DevOps-Team auch bei vielen Projekten und Applikationen immer sofort den aktuellen Codestand findet und ein einheitliches Vorgehen hat, wie beispielsweise beim Mergen. Wer gar keine Idee hat, welches Branch-Modell sinnvoll sein könnte, der kann zum Beispiel das sehr schlanke GitHub-Modell oder das komplexere GitFlow nutzen.

Die Branch Policies helfen dabei, bestimmte Branches zu schützen und Codechaos sowie Merge-Höllen zu vermeiden. In den Branch Policies von Azure DevOps (Abb. 1) oder auch neueren TFS-Versionen lassen sich unter anderem die folgenden wichtigen Punkte festlegen:

  • Code-Reviewer: Vier-Augen-Prinzip sichert die Qualität; zusätzliche Freigabe beispielsweise durch Architekten erforderlich. Entwickler können nicht ihren eigenen Code freigeben.
  • Work-Item-Zuordnung: Stellt sicher, dass der Code mit den entsprechen Anforderungen oder Aufgaben verknüpft ist. Das ist nützlich für die Generierung von Release-Notes, hilft aber auch im Falle einer Fehleranalyse, weil man immer nachvollziehen kann, für welchen Zweck der Code geschrieben wurde.
  • Build-Validierung: Nur wenn der Code stabil ist und einen validen Build Run durchläuft, kann der Code gemerget werden.
  • Automatische Reviewer: Hier können für verschiedene Verzeichnisse automatische Code-Reviewer definiert werden.

Erfahrungsgemäß ist eine strikte Policy auf den wichtigen Master und Release Branches enorm sinnvoll. Auf den Development, Topic oder Feature-Branches können die Policies teilweise gelockert werden.

Auf geht’s

Natürlich können alle diese Punkte nicht immer sofort implementiert werden und nicht alles ergibt zwingend in jedem SharePoint-DevOps-Team Sinn. Die Einführung von DevOps ist ein Prozess, der sich über einen längeren Zeitraum erstreckt, und die oben genannten Empfehlungen können auch eine nach der anderen umgesetzt werden, um schrittweise Teilaspekte, wie zum Beispiel den Automatisierungsgrad, zu erhöhen. Am Ende sollte nach Möglichkeit eine Verbesserung für die SharePoint-Teams erreicht werden, die sich in KPIs wie der Durchlaufzeit für Anwendungsupdates oder dem durchschnittlichen Aufwand für den Betrieb zeigen.

Links & Literatur

[1] Czerwinski, Boris; Pehlke, Bern: „Azure VMs als Entwicklungsmaschinen nutzen“; in: Windows Developer 9.2019

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. Außerdem ist der Windows Developer weiterhin als Print-Magazin im Abonnement erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -