Was bedeutet eigentlich DevOps?

DevOps mit Visual Studio: Build – Deploy – Monitor
Kommentare

Bisher wurde beim Application-Lifecycle-Management-Prozess meistens die eigentliche Wertschöpfungskette, und zwar die Entwicklung selbst, betrachtet. Die Verbesserung des Anforderungsmanagement-, Entwicklungs- und Testprozesses stand dabei im Fokus. Agile Praktiken und der Einfluss von Lean-Management-Methoden haben dabei zu einer deutlichen Steigerung der Effizienz und somit kürzeren Releasezyklen von Software beigetragen. Dieses gilt es jetzt auch für die „letzte Meile“ – also den Release-Management-Prozess und die Übergabe der funktionsfähigen Software an den IT-Betrieb – zu übertragen und hier kommt DevOps ins Spiel.

Der Begriff „DevOps“ leitet sich aus „Dev“, dem Softwareentwickler, und „Ops“, dem IT-Betrieb (Operations), ab und beschäftigt sich mit der Zusammenarbeit und Integration von Softwareentwicklern und IT-Professionals aus dem Betrieb. Zentraler Gedanke von DevOps ist die Automatisierung von Vorgängen, die sonst manuell durchgeführt werden, und somit wenig transparent und schlecht nachvollziehbar für die Qualitätskontrolle sind.

Abb. 1: DevOps im Kontext von Application Lifecycle Management

DevOps als integraler Bestandteil des Application Lifecycle Managements ermöglichen es der Softwareentwicklung und dem IT-Betrieb, kontinuierlich funktionale und betriebsbereite Software auszuliefern (Abb. 1). Dies setzt Maßnahmen voraus, wie die Sicherstellung der Qualität, einen definierten und wiederkehrenden Releaseprozesses zu etablieren und Applikationstelemetrie zu nutzen. Aber auch reaktive Maßnahmen wie die Erfassung von Fehlern in der Produktion und deren Rückmeldung in die Entwicklungsabteilung.

Continuous Delivery mit Visual Studio Online

Ein Beispielszenario: Die Fabrikam Fiber Corporation nutzt für die Erfassung ihrer Kundenaufträge ein Internetportal, das auf einem Windows-Azure-Cloud-Dienst betrieben wird. Die Applikation ist eine moderne ASP.NET-MVC-Anwendung mit einer SQL-Azure-Datenbank als Backend. Das Entwicklungsteam nutzt Visual Studio Online für das Anforderungsmanagement, die Versionskontrolle sowie den kontinuierlichen Team-Build-Prozess, um einen durchgängigen und transparenten Entwicklungsprozess umzusetzen. Über einen weiteren Team-Build-Prozess wird ein automatisiertes Deployment des vom Testteam freigegebenen Softwarestands auf der Azure-Produktionsumgebung angestoßen. Um die Quality-of-Service-Metriken zu erfüllen, nutzt das Fabrikam-Fiber-Team den Visual-Studio-Lasttest-Dienst sowie die Möglichkeit, Fehlerinformationen auch zur Laufzeit über IntelliTrace-Logs auszulesen. Darüber hinaus werden Daten zur Nutzung der Anwendung sowie Performancedaten über den Application-Insights-Telemetriedienst ausgewertet.

Anhand dieses Szenarios konzentriert sich dieser Artikel auf zwei Themen: Den Aufbau eines Continuous-Delivery-Prozesses mit Visual Studio Online (VSO) und Windows Azure, sowie die Überwachung der Applikation (Applikationstelemetrie) mit Application Insights (AI).

Eine Continuous-Delivery-Pipeline

Eine zentrale Komponente für einen kontinuierlichen Softwarelieferprozess ist der Team Build des Team Foundation Servers (TFS). Über einen Continuous Integration Build (CI Build) kann das Entwicklungsteam jederzeit die Qualität und den Integrationsstatus der Software validieren. Darüber hinaus werden nicht funktionale Akzeptanzkriterien, wie z. B. die Performance der Software über Web- und Lasttests mit Visual Studio 2013 validiert.

Continuous Integration mit Visual Studio Online

Sobald der Quellcode in die Versionskontrolle des TFS eingecheckt wurde, kann ein CI Build eingerichtet werden. Dieser Build validiert den Qualitäts- sowie den Integrationsstatus der Software durch die Ausführung von Unit und Integrationstests. Die Tests werden in einem Visual-Studio-Testprojekt definiert und mitsamt dem Applikationscode in die Versionskontrolle eingecheckt. Dieser CI Build läuft gewöhnlich gegen einen Development Branch, auf dem die aktuelle Version des Projekts entwickelt wird. Ausgehend vom Build Hub im Team Explorer kann man eine neue Build Definition anlegen. Für das Beispielszenario legt man diese mit den von TFS vorgeschlagenen Standardwerten an. Dazu muss nur der Name der Build Definition angegeben sowie auf dem nächsten Reiter der Trigger „Continuous Integration“ ausgewählt werden. Wichtig ist die Angabe des entsprechenden Branchs – in diesem Fall „Development“ –, aus welchem gebaut werden soll. Auf Visual Studio Online kann man den „Hosted Build Controller“ als Build-Infrastruktur nutzen. Damit läuft der gesamte Build-Prozess in der Cloud ab und man muss sich nicht um die Bereitstellung eines eigenen Build-Controllers sowie Build-Agenten kümmern. Die restlichen Werte können einfach übernommen werden. Der TFS Build arbeitet mit einer Workflow Engine und entsprechenden Build-Prozess-Templates. Das „Default Template“ stellt auch die Möglichkeit bereit, Tests während des Builds auszuführen. Abschließend validiert man die Build Definition, indem aus dem Build Hub in Visual Studio ein neuer Build über „Queue New Build“ angestoßen wird. Sobald dieser Build fertiggestellt wurde, sieht man das Ergebnis im Bereich „My Builds“.

Aufbau einer Continuous-Delivery-Pipeline

Ist der CI Build angelegt und auch erfolgreich durchgelaufen, kann man eine weitere Build Definition für den Continuous-Delivery-Prozess (CD) anlegen. Dies geschieht jedoch nicht aus Visual Studio heraus, sondern muss über das Dashboard im Azure-Portal erfolgen. Sowohl Azure-Cloud-Dienste als auch Azure-Websites bieten die Möglichkeit, eine Bereitstellung über die Versionsverwaltung einzurichten. Dabei muss nicht zwingend ein VSO Repository genutzt werden, der Quellcode kann auch aus einem GitHub, CodePlex oder Bitbucket Repository geladen werden. Die nachfolgenden Schritte beziehen sich aber auf das VSO Repository.

Um eine Bereitstellung einzurichten, ruft man das Dashboard des entsprechenden Cloud-Diensts auf und richtet über den Link „Veröffentlichung mit Visual Studio Online“ den Continuous Delivery Build ein. Dazu muss im nachfolgenden Dialog der Accountname des jeweiligen VSO-Accounts angegeben und das zugehörige Teamprojekt ausgewählt werden. Hinter den Kulissen wird dann ein neuer Continuous Integration Build in VSO eingerichtet. Diesen findet man im Build Hub unter dem Namen des Cloud-Diensts, dem ein _CD – für Continuous Delivery – angehängt wird. Diese Build Definition muss noch entsprechend angepasst werden, um ein kontinuierliches Deployment auf dem Cloud-Dienst aus einem Release oder Main Branch zu ermöglichen.

Zuerst muss man auf dem Reiter „Source Settings“ den richtigen Branch, in diesem Fall den „Main“ Branch auswählen. Folgende Parameter sollten auf dem „Process“-Tab geändert bzw. eingetragen werden:

  • Unter „Projects“ die zu bauende Solution aus dem entsprechenden Branch.
  • Unter „Configuration“ die Konfiguration z. B. ANY CPU | RELEASE.
  • Verwendet man für das Deployment des Cloud-Diensts spezielle Einstellungen, kann das entsprechende Azure Publish Profile unter „Path to Deployment Settings“ mit angegeben werden. Der Pfad bezieht sich ebenfalls auf den Pfad im Repository.

Sobald die Build Definition gespeichert ist, kann man den ersten CD Build sowie das eigentliche Deployment über „Queue New Build“ anstoßen. Dabei werden die Sourcen nicht nur gebaut, sondern der gesamte Deployment-Prozess auf den Azure-Cloud-Dienst, über das Prozesstemplate gesteuert. Dazu wird bei der Einrichtung der Bereitstellung aus dem Azure-Portal das TfvcContinuousDeploymentTemplate im Build hinterlegt. Dieses Build-Prozess-Template ist nur auf VSO verfügbar. Möchte man einen CD-Prozess auf Azure mit einem On-Premise TFS nutzen, muss das „Default Template“ manuell angepasst werden. Details dazu findet man in der Dokumentation. Ist der Build erfolgreich durchgelaufen, kann das aktive Deployment im Azure-Portal auf dem „Deployment“-Reiter überprüft werden.

Überwachung der Applikation und Diagnose von Fehlern in Produktion

Nachdem die Anwendung erfolgreich auf den unterstützenden Azure-Diensten deployt wurde, können Benutzer die Website besuchen. Auch wenn viel Aufwand in die Sicherstellung der Qualität geflossen ist, sowie die nicht funktionalen Anforderungen mittels Akzeptanztests validiert wurden, können im Livebetrieb Fehler auftreten. Fehler in der Anwendung werden durch die Entwickler untersucht und behoben. Schwieriger wird es, wenn sich die Anwendung nur in bestimmten Situationen komisch verhält. In diesem Fall ist die Sammlung von Telemetridaten über alle Komponenten der Anwendung hilfreich, um einen ganzheitlichen Blick auf die Applikation zu haben. Hierbei hilft der Application-Insights-Dienst in Visual Studio Online.

[ header = Seite 2: Applikationstelemetrie mit Application Insights ]

Applikationstelemetrie mit Application Insights

Ähnlich wie im Motorsport, wo man schon Runden vorher absehen kann, dass ein Auto liegen bleiben wird, kann Telemetrie in Applikationen dabei helfen, Fehler zu erkennen, bevor Nutzer diese bemerken. Über die Homepage des VSO-Accounts kann man Application Insights freischalten und für seine Anwendung registrieren. Dabei kann Application Insights nicht nur einen URL über einen Ping-Test überwachen, sondern Telemetriedaten für .NET- und Java-Anwendungen sammeln (Abb. 2). Darüber hinaus gibt es ein Telemetrie-SDK für Windows-Phone- und Windows-Store-Anwendungen als NuGet-Packages.

Abb. 2: Funktionsweise von Application Insights

Die Freischaltung für Application Insights läuft im Moment über einen Einladungscode, da der Dienst sich noch in einer limitierten Previewphase befindet. Sobald man seine Anwendung in Application Insights registriert, kann man einen einfachen Ping-Test über den „New Single URL Test“ einrichten. Nach ungefähr fünf bis fünfzehn Minuten erscheinen die ersten Telemetriedaten im Application Insights Dashboard (Abb. 3).

Abb. 3: Application Insights Dashboard: die Dashboards können beliebig angepasst und dargestellt werden

Über das „Synthetic Monitoring“-System können auch im Vorfeld in Visual Studio aufgezeichnete Webperformancetests verwendet werden. Somit können auch komplexe Szenarien, wie z. B. die Funktionsfähigkeit eines Einkaufskorbs überwacht werden. Dabei kann man auf das Global System Monitoring (GSM) zurückgreifen. GSM ermöglicht die Überwachung der Anwendung aus weltweit verteilten Datenzentren.

Mit dem Microsoft Monitoring Agent können Performancedaten an den Application-Insights-Service übertragen werden. Die notwendigen Konfigurationsschritte für jede unterstützte Technologie sind im Portal beschrieben und auch als kurzes Lernvideo verfügbar. Für Anwendungen, die als Azure-Cloud-Dienst betrieben werden, muss Folgendes konfiguriert werden:

  • Die „Azure PaaS Instrumentation Files“ aus dem Portal herunterladen und extrahieren.
  • Im Visual-Studio-Web-Role-Projekt einen Unterordner mit dem Namen AppInsightsAgent erstellen und die beiden Dateien unifiedbootstrap.bat und unifiedbootstrap.ps1 hineinkopieren. Die „Copy to Output Directory“-Eigenschaft muss für beide Dateien auf „Copy always“ gesetzt werden.
  • In der ServiceDefinition.csdef und ServiceConfiguration.Cloud.cscfg des Cloud-Dienst-Projekts den im Portal angezeigten XML-Code hinzufügen.

Die Änderungen in die Versionsverwaltung einchecken und dadurch ein neues Deployment auf den Cloud-Dienst starten. Wie beim „Synthetic Monitoring“ können erste Telemetriedaten nach ca. fünf bis fünfzehn Minuten im Dashboard eingesehen werden.

Die Nutzung bestimmter Funktionen bzw. der Aufruf bestimmter Webseiten durch Nutzer kann über die „Usage Reports“ in Application Insights ausgewertet werden. Die zu überwachenden Seiten müssen hierzu instrumentiert werden. Dazu ruft man im Portal das „JavaScript Usage Anayltics Code“-Skript ab und fügt die eigens für die Anwendung generierte Instrumentation GUID in das Skript ein. In jede Seite, die an den Dienst gemeldet werden soll, kopiert man nun das Skript vor den schließenden -Tag.

Wer darüber hinaus noch mehr Informationen aus seiner Anwendung erhalten möchte, kann mit dem Application Insights SDK z. B. eingehende Requests, definierte Key-Performance-Indikatoren (KPIs) bis hin zu eigenen Metriken und Eigenschaften implementieren. Die MSDN-Dokumentation hilft hier weiter.

Wenn man länger mit Application Insights arbeitet und die Ergebnisse in die zukünftige Entwicklung der Anwendung einfließen lässt, stellt man fest, dass ein gewisser Paradigmenwechsel in der Softwareentwicklung stattfindet. Telemetrie verknüpft den Nutzer der Anwendung mit dem Entwickler und zeigen ihm z.B. wie Nutzer mit der Anwendung interagieren, welchen Einfluss Konfigurationsänderungen auf die Performance haben und ob die Website auch wirklich verfügbar ist.

Diagnose von Fehlern in der Produktivumgebung

Fehler im Produktivsystem sollten durch den Entwickler schnellstmöglich behoben werden können. Idealerweise kann der Entwickler durch den Einsatz von Telemetrie vorzeitig über Fehler informiert werden und diese beheben, bevor weitere Nutzer diese entdecken. Der Monitoring Agent bietet hier die Möglichkeit, auch aufgetretene Exceptions der Anwendung an Application Insights zu melden. Nutzt man Azure-Cloud-Dienste, kann für das Deployment im Azure Publishing Profile IntelliTrace für die Anwendung aktiviert werden. Somit hat der Entwickler im IntelliTrace Logfile Informationen zur Fehlerbehebung wie z. B. den Call Stack zum Zeitpunkt des Fehlers, historische Debug-Informationen und alle geladenen DLLs.

Treten in der Applikation behandelte oder unbehandelte Exceptions auf, werden diese vom Monitoring Agent gesammelt und im Application Insights Dashboard unter „Diagnostics“ zusammengefasst (Abb. 4).

Abb. 4: Fehlerinformationen im Application Insights Dashboard

Die Details zu einer Exception geben erste Hinweise, warum der Fehler aufgetreten ist. Hier kann man sich auch das zugehörige IntelliTrace Logfile herunterladen, um es in Visual Studio zu analysieren. Eine große Zeitersparnis für den Entwickler.

Das aktuelle Azure SDK 2.2 unterstützt für Azure-Cloud-Dienste und Azure-Websites auch das Remote Debugging. Um den Remote Debugger an den Cloud-Dienst oder die Website anzuhängen, ruft man im Server Explorer die Option „Attach Debugger“ auf. Zwar kann der Debugger auch an Produktivumgebungen angehängt werden, jedoch benötigt man einen „Debug“ Build auf der Azure-Instanz, um alle Diagnosemöglichkeiten auszuschöpfen.

Wie geht es weiter?

Das Thema DevOps wird die Softwareentwicklung mehr und mehr dominieren. Um auf Kundenwünsche schnell und flexibel reagieren zu können, erfordern immer kürzere Produkt- und Releasezyklen einen nachvollziehbaren und kontinuierlichen Softwarelieferprozess. Telemetrie, die Möglichkeit, Fehler in Produktion schnell zu erkennen und zu beheben, um kurzfristig einen Bugfix auszuliefern, sind der Schlüssel hierzu. Einfach ausprobieren und einen Account auf Visual Studio Online anlegen sowie die kostenlose Azure Trial nutzen. Bei Fragen können Sie sich gerne an den Autor wenden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -