Artikel
09/18/2015

September 2015

Band 30, Nummer 9

DevOps – Ermöglichen von DevOps für den Microsoft-Stapel

Von Michael Learned | September 2015

DevOps erfährt derzeit viel Aufmerksamkeit. Die benutzerdefinierte Software einer Organisation ist entscheidend dafür, den Benutzern in den Geschäftsbereichen nützliche Arbeitsumgebungen und Daten zu bieten. Die schnelle Bereitstellung von Software hoher Qualität ist nicht mehr nur eine Option, sondern eine Anforderung. Vorbei sind die Tage langer Planungssitzungen und Entwicklungsschritte. Durch Cloudplattformen, wie z. B. Microsoft Azure, werden herkömmliche Engpässe beseitigt und Infrastruktur leicht zugänglich gemacht. Software spielt in allen Unternehmen die entscheidende Rolle als Garant guter Geschäftsergebnisse. Unternehmen, Entwickler und IT-Mitarbeiter können bzw. dürfen der DevOps-Initiative nicht aus dem Weg gehen.

DevOps lässt sich aus verschiedenen Perspektiven definieren, beschreibt aber meist das Beseitigen kultureller und technologischer Barrieren zwischen IT-Entwicklungs- und Betriebsteams, damit Software so effizient wie möglich in die Produktion überführt werden kann. Sobald Software in der Produktionsumgebung ausgeführt wird, müssen Sie dafür sorgen, dass Sie umfangreiche Nutzungsdaten erfassen und diese Daten zu den Entwicklungsteams und Entscheidungsträgern leiten.

Es gibt viele Technologien und Tools, die DevOps unterstützen können. Diese Tools und Prozesse unterstützen rasche Releasezyklen und die Datensammlung für Produktionsanwendungen. Für den Microsoft-Stapel ermöglichen Tools wie Release Management das Fördern schneller und planbarer Releases, während Application Insights bei der Sammlung umfassender Nutzungsdaten hilft. In diesem Artikel untersuchen wir eingehend einige wichtige DevOps-Tools und -Methoden sowie die verschiedenen Aspekte von DevOps (siehe Abbildung 1).

Abbildung 1: Die verschiedenen Aspekte von DevOps

Die Rolle von DevOps

Die meisten Unternehmen möchten ihre DevOps-Lösung in den folgenden Bereichen verbessern:

Automatisierte Releasepipelines, in denen Sie neue Versionen in wesentlich kürzeren Zyklen zuverlässig testen und freigeben können.
Sobald die Anwendung in der Produktion ausgeführt wird, benötigen Sie die Möglichkeit, schnell auf Änderungswünsche und Fehler zu reagieren.
Sie müssen Telemetrie- und Nutzungsdaten ausgeführter Produktionsanwendungen erfassen und für die datenbasierte Entscheidungsfindung nutzen, anstatt zur "Kristallkugel" greifen zu müssen.

Gibt es in Ihrer Organisation sog. "Silos", d, h, isolierte Bereiche, die diesen Aspekten von DevOps im Weg stehen? Diese Silos gibt es in vielen Formen, wie z. B. unterschiedliche Tools, Skriptsprachen, Abteilungsrichtlinien und -grenzen. Ihr Zweck ist das Trennen von Zuständigkeiten und das Sorgen für Sicherheitskontrollen und Stabilität in der Produktion.

Trotz ihres Zwecks können diese Silos eine Organisation mitunter am Erreichen zahlreicher DevOps-Ziele hindern, wie z. B. schnelle, zuverlässige Releases bzw. Behandlung von und Reaktion auf Produktionsfehler. In vielen Fällen wird in einer solchen Silostruktur eine alarmierende Menge an Energie verschwendet. IT-Entwicklungs- und Betriebsteams haben üblicherweise in verschiedenen Teams mit verschiedenen Zielen gearbeitet. Diese Teams verbrachten viel Zeit mit dem Beheben von Problemen, die durch diese Barrieren verursacht wurden, und weniger Zeit damit, das Unternehmen weiter nach vorn zu bringen.

Entscheidungsträger im Unternehmen benötigen einen neuen Blickwinkel auf die verschiedenen Abgrenzungen, um den wahren Nutzen oder die Vorteile zu bestimmen, die diese Silos vorgeblich bieten. Eines wird immer klarer: Je mehr diese Hindernisse aus dem Weg geräumt werden, desto einfacher wird die Umsetzung von DevOps-Lösungen und Vermeidung von Zeitverschwendung.

Die Herausforderung besteht darin, Sicherheit, Kontrollen und Compliance in Abstimmung mit den Anforderungen an Agilität weiter zu gewährleisten. Sicherheitsteams in Unternehmen müssen dafür sorgen, dass Daten sicher und vertraulich behandelt werden. Sicherheit ist wohl genauso wichtig wie alle anderen Aspekte in einem Unternehmen.

Doch mit jeder Sicherheitsgrenze, die Sie ziehen, gehen Kosten einher. Wenn Sicherheitsgrenzen in Ihren Teams unnützen Aufwand und Reibung verursachen, sollten diese Grenzen aus einem neuen Blickwinkel heraus auf ihren tatsächlichen Nutzen untersucht werden. Sie können die sicherste Organisation der Welt sein, doch wenn Sie Software nicht rechtzeitig freigeben können, haben Sie einen Wettbewerbsnachteil.

Das Abwägen dieser Prioritäten ist keine neue Herausforderung, doch ist es an der Zeit für einen frischen, ehrlichen Blick auf die verschiedenen Prozesse und Silos, die es in Ihrer Organisation gibt. Alle Teams sollten sich auf den geschäftlichen Nutzen und nicht auf individuelle Ziele konzentrieren.

Die Releasepipeline

In der Releasepipeline wird Ihr Code mit einer Versionskontrolle entwickelt. Anschließend durchläuft er mehrere Umgebungen, um schließlich für die Produktion freigegeben zu werden. Im gesamten Verlauf erfolgen automatisierte Builds und Tests. Die Pipeline muss sich in einem Zustand befinden, in dem das Einführen von Änderungen in die Produktion transparent, wiederholbar, zuverlässig und schnell stattfindet. Dabei wird zweifellos auf Automatisierung gesetzt. Die Releasepipeline kann auch die Bereitstellung der Hostumgebung von Anwendungen umfassen.

Ihre Releasepipeline ist möglicherweise nicht optimiert, wenn diese Faktoren vorzufinden sind:

Fehlende Übereinstimmungen von Tools und Prozessen aufgrund unterschiedlicher Tools und Prozesse pro Umgebung. (Das Entwicklerteam führt beispielsweise die Bereitstellung mit einem andere Tool als das Betriebsteam durch.)
Manuelle Schritte können Fehler verursachen und sollten daher vermieden werden.
Neuerstellung von Builds, nur damit die Bereitstellung in der nächsten Umgebung erfolgen kann.
Fehlende Rückverfolgbarkeit und Probleme beim Verstehen, welche Versionen freigegeben wurden.
Langwidrige Freigabezyklen, sogar für Hotfixes.

Bereitstellung

Die Bereitstellung von Containern gilt mitunter als optionaler Teil einer Releasepipeline. Häufig ist ein klassisches lokales Szenario vorzufinden, in dem eine Umgebung bereits betrieben wird, um eine Webanwendung zu hosten. Der IIS-Webserver oder andere Host- und Back-End-SQL-Server haben zahlreiche Iterationen durchlaufen. Bei schnellen Releases in diesen Umgebungen wird nur der Anwendungscode bereitgestellt, und nachfolgende Änderungen an SQL-Schema und Daten müssen auf die entsprechenden Updatestufen gebracht werden. In diesem Fall stellen Sie keine neue Infrastruktur (sowohl IIS als auch SQL) zum Hosten der Anwendung bereit. Sie verwenden eine Releasepipeline, die die Bereitstellung ignoriert und sich nur auf den Anwendungscode selbst konzentriert.

Es gibt andere Szenarien, in denen Sie möglicherweise verschiedene Containerkonfigurationseinstellungen ändern möchten. Sie müssen möglicherweise einige App-Pool-Einstellungen in IIS optimieren. Sie könnten dies als Teil der Releasepipeline implementieren oder manuell vornehmen. Anschließend könnten Sie sich entscheiden, diese Änderungen in einer Art von Versionskontrollsystem mit einer Infrastruktur-als-Code-Strategie (IaC) nachzuverfolgen.

Es gibt verschiedene andere Szenarien, in denen Sie ggf. die Bereitstellung als Teil einer automatisierten Releasepipeline durchführen möchten. Sie möchten beispielsweise frühzeitig in den Entwicklungszyklen SQL-Datenbanken nach Belieben löschen und für jedes Release neu erstellen, um die Umgebung vollständig und automatisch zu testen.

Auf Cloud Computing-Plattformen wie Azure müssen Sie nur für das zahlen, was Sie tatsächlich nutzen. Das Arbeiten mit automatischen Auf- und Abbauprozessen kann sich als wirtschaftlich erweisen. Durch eine Automatisierung von Bereitstellung und Umgebungsänderungen können Sie Fehler vermeiden und die gesamte Anwendungsumgebung kontrollieren. Szenarien wie diese sind ein Anreiz, die Bereitstellung in ein ganzheitliches Releaseverwaltungssystem einzubeziehen.

Es gibt viele Optionen und Methoden zum Einbeziehen der Bereitstellung in die Releasepipeline. Diese hängen davon ab, welche Anwendungstypen Sie wo hosten möchten. Ein Beispiel ist das Hosten einer klassischen ASP.NET-Webanwendung im Vergleich mit einer Azure-Web-App oder anderen PaaS-Anwendung (Platform-as-a-Service), wie z. B. Azure Cloud Services. Der Container für diese Anwendungen unterscheiden sich und erfordern unterschiedliche Tools und Methoden zur Unterstützung der Bereitstellungsschritte.

Infrastruktur als Code (IaC)

Eine beliebte Bereitstellungsmethode ist IaC. Eine Anwendung ist eine ausführbare Datei, die aus kompiliertem Code, Skripts usw. in Kombination mit einer Betriebsumgebung kompiliert werden kann. Sie werden feststellen, dass diese Umgebung zahlreiche Vorteile bietet.

Microsoft hat vor Kurzem Forrester Research Inc. mit einer Studie der Auswirkungen von IaC beauftragt (siehe bit.ly/1IiGRk1). Die Untersuchung hat gezeigt, dass IaC eine wichtige DevOps-Komponente ist. Ferner wurde festgestellt, dass Bereitstellung und Konfiguration eine wesentliche Ursache von Spannungen bei für die Bereitstellung von Software zuständigen Teams sind. Sie müssen auf Automatisierung und IaC-Techniken setzen, wenn Sie vorhaben, Ihre DevOps-Ziele vollständig zu erreichen.

Eine der herkömmlichen IT-Betriebsaufgaben ist die Automatisierung der Fähigkeit zum Bereitstellen geeigneter Umgebungen, in denen Anwendungen und Dienste ausgeführt werden, und den ordnungsgemäßen Zustand dieser Umgebungen beizubehalten. Virtualisierung und andere Verfahren zur Automatisierung sind nützlich, haben aber immer noch Probleme, Knoten synchron zu halten und Konfigurationsabweichungen im Griff zu behalten. IT-Betriebs- und Entwicklungsteams müssen sich weiterhin mit unterschiedlichen Toolsets, Fachkenntnissen und Prozessen abmühen.

IaC basiert auf der Annahme, dass wir in der Lage sein sollten, unseren Infrastrukturcode mittels einer automatisierten Releasepipeline zu beschreiben, zu versionieren, auszuführen und zu testen. Beispielsweise können Sie mit einem einfachen Windows PowerShell-Skript einen virtuellen Windows-Computer (VM), der mit IIS konfiguriert ist, problemlos erstellen. Das Betriebsteam sollte die gleichen ALM-Tools nutzen können, um für die Infrastruktur Skripts zu erstellen, Versionen zu kontrollieren und Tests durchzuführen.

Ein weiterer Vorteil ist die Möglichkeit, bekannte Versionen Ihrer Umgebungen hoch- und wieder herunterzufahren. Sie können lästige Probleme aufgrund von Unterschieden zwischen Entwicklungs- und Produktionsumgebung vermeiden. Sie können die anwendungsumgebungsspezifischen Abhängigkeiten in Code ausdrücken und sie der Versionskontrolle unterziehen. Kurz gesagt, können Sie manuelle Prozesse hinter sich lassen und sicherstellen, dass Sie für die Anwendung automatisierte Umgebungscontainer zuverlässig getestet haben. IT-Entwicklungs- und Betriebsteams können die gleichen Skriptsprachen und Tools verwenden und diese Effizienz zu erzielen.

Der Anwendungstyp und vorgesehene Hoststandort bestimmen die benötigten Tools für die Ausführung Ihres Infrastrukturcodes. Es gibt mehrere Tools, die zur Unterstützung dieser Methoden immer beliebter werden, so z. B. DSC (Desired State Configuration, Konfiguration des gewünschten Zustands), Puppet und Chef. Je nach vorhandenem Szenario können Sie mit diesen Tools ähnliche Ziele erreichen.

Die Codekomponente von IaC kann eines von mehreren Dingen sein. Es kann sich um einfache Windows PowerShell-Skripts handeln, mit denen Ressourcen bereitgestellt werden. Wiederum bestimmen die Anwendungstypen und Hostingumgebung Ihre verfügbaren Optionen.

Für Azure können Sie Cloudbereitstellungsprojekte verwenden, die Azure-Ressourcenverwaltungs-APIs zum Erstellen und Verwalten von Azure-Ressourcengruppen nutzen. Dies ermöglicht Ihnen das Beschreiben Ihrer Umgebungen mit JSON. Azure-Ressourcengruppen lassen auch das gemeinsame Verwalten gruppenbezogener Ressourcen wie Websites und SQL-Datenbanken zu. Mit Cloudbereitstellungsprojekten können Sie Ihre Bereitstellungsanforderungen in der Versionskontrolle speichern und die Azure-Bereitstellung als Teil einer automatisierten Releasepipeline ausführen. Es folgen die Abschnitte, die die grundlegende Struktur einer Bereitstellungsvorlage bilden:

{
  "$schema": "http://schema.management.azure.com/schemas2015-01-01/
    deploymentTemplate.json#",
  "contentVersion": "",
  "parameters" { },
  "variables": { },
  "resources": [ ],
  "outputs": { }
}

Weitere Informationen zu Vorlagen finden Sie unter bit.ly/1RQ3gvg. Weitere Informationen zu Cloudbereitstellungsprojekten finden Sie unter bit.ly/1flDH3m.

Die Skriptsprachen und Tools sind nur ein Teil der Änderungen, die erforderlich sind, um eine IaC-Strategie erfolgreich umzusetzen. IT-Entwicklungs- und Betriebsteams müssen zusammenarbeiten, um ihre Arbeitsabläufe zu integrieren und auf gemeinsame Ziele auszurichten. Dies kann schwierig sein, da sich Betriebsteams in der Vergangenheit darauf konzentriert haben, Umgebungen stabil zu halten, während der Schwerpunkt bei Entwicklungsteams darauf lag, neue Features in diesen Umgebungen einzuführen. Leistungsfähige Technologien sind bald einsatzbereit, doch die Grundlage einer erfolgreichen IaC-Implementierung hängt von der Fähigkeit der Betriebs- und Entwicklungsteams ab, effektiv zusammenzuarbeiten.

Orchestrierung von Releases

Release Management ist eine Technologie im Visual Studio-ALM-Stapel. Eigentlich ist es eher ein Konzept, bei dem Sie die verschiedenen Objekte und Aufgaben orchestrieren können, aus denen eine Softwareversion besteht. Einige dieser Artefakte sind u. an. die Nutzlast oder das Paket, die/das von einem Buildsystem erstellt wird, die automatisierten Tests, die im Rahmen einer Releasepipeline erfolgen, Genehmigungsworkflows, Benachrichtigungen und Sicherheitsvorschriften, um Umgebungen kontrolliert an die Produktion heranzuführen.

Sie können Technologien wie z. B. DSC, Windows PowerShell-Skripts, Azure-Ressourcen-Manager, Chef usw. zum Verwalten des Zustands der Umgebung verwenden und Software und Abhängigkeiten in laufende Umgebungen installieren. Stellen Sie sich hinsichtlich der Tools, die von Visual Studio ALM bereitgestellt werden, Release Management als den Dienst vor, der als Wrapper für beliebige benötigte Technologien und Tools zum Ausführen der Bereitstellungen dient. Release Management ermöglicht die Nutzung einfacher Befehlszeilen oder Windows PowerShell-Skripts, das Verwenden von DSC oder sogar die Ausführung Ihrer eigenen selbstentwickelten Tools. Für Ihre Releases sollten versuchen, die einfachste Lösung wie möglich zu verwenden.

Es ist auch empfiehlt zudem, Windows PowerShell zu nutzen, da dieses Tool weit verbreitet ist. Sie können z. B. Windows PowerShell-Skripts als Teil einer Releasepipeline zum Bereitstellen von Azure-Clouddiensten einsetzen. Release Management bietet zahlreiche integrierte Tools (siehe Abbildung 2), aber Sie können auch flexibel Ihre eigenen erstellen.

Abbildung 2: Für Release Management verfügbare Tools und Optionen

Mithilfe von Release Management können Sie eine automatisierte Releasepipeline elegant erstellen und automatisierte Anwendungsversionen zuverlässig erzeugen. Sie können nach Wunsch auch die Bereitstellung einbeziehen. Mit den Release Management-Tools in Visual Studio und Team Foundation Server können Sie diese Artefakte innerhalb der allgemeinen Releasetransaktion orchestrieren. Darüber hinaus werden umfassende Dashboardansichten Ihrer aktuellen und vergangenen Zustände geboten. Es gibt auch eine weitreichende Integration in Team Foundation Server und Visual Studio Online.

Wie passt DSC ins Bild?

DSC hatte in letzter Zeit viel Presse. DSC ist allerdings kein allumfassendes Tool, mit dem sämtliche Anforderungen erfüllt werden können. Sie nutzen DSC als eines der Tools in Ihrer DevOps-Struktur und nicht als alleiniges Tool.

Sie können DSC im Pull- oder Pushmodus verwenden. In der anschließend Phase "So machen wir das" (in Anlehnung an Jean-Luc Picard vom Raumschiff Enterprise) können Sie dann den Serverstatus steuern. Das Steuern dieses Status kann so einfach sein wie das Sicherstellen, dass eine Datei oder ein Verzeichnis vorhanden ist, oder etwas komplexer sein, wie z. B. Registrierung ändern, Dienste beenden oder starten oder Skripts zum Bereitstellen einer Anwendung ausführen. Sie können diese Vorgänge fehlerfrei wiederholen. Sie können auch Ihre eigenen DSC-Ressourcen definieren oder eine große Anzahl integrierter Ressourcen nutzen.

DSC ist als lokaler Konfigurations-Manager implementiert, der auf einem Zielknoten ausgeführt wird. DSC verwendet eine MOF-Konfigurationsdatei (Management Object File), mit der die Konfiguration auf den Knoten selbst angewendet wird. Es handelt sich also nicht um ein fest gekoppeltes Tool. Sie müssen noch nicht einmal Windows PowerShell verwenden, um die MOF-Datei zu erzeugen.

Um mit der Nutzung von DSC zu beginnen, erstellen Sie einfach die MOF-Datei. Diese beschreibt letztlich die verschiedenen auszuführenden Ressourcen, die am Ende größtenteils in Windows PowerShell geschrieben werden. Einer der großen Vorteile von DSC auf Windows Server-basierten Systemen ist, dass der lokale Konfigurations-Manager für das Betriebssystem systemeigen ist, wodurch Sie in den Genuss eines integrierten Agents kommen. Es gibt auch Szenarien für die Nutzung von DSC mit Linux. In Abbildung 3 sehen Sie ein Beispiel der Trennung der Konfigurationsdaten für das DSC-Skript.

Abbildung 3: Getrennte Konfigurationsdaten in einem DCS-Skript

Configuration InstallWebSite
{
  Node $AllNodes.NodeName
  {
    WindowsFeature InstallIIS
    {
      Ensure = "Present"
      Name = "Web-Server"
    }
  }
}
InstallWebSite –ConfigurationData .\config.ps1
Where config.ps1 contains
$ConfigData = @{
  AllNodes = @(
  @{
    NodeName = “localhost”
  })
}

DSC kann ein wichtiger Bestandteil einer Releasepipeline sein, sofern die Ressourcen zur Verfügung stehen, die Ihre Bereitstellung unterstützen. Bei lokalen und IaaS-Anwendungen ist DSC ist eine ausgezeichnete Option zum Steuern der Umgebungskonfiguration und Unterstützung Ihrer Bereitstellungsszenarien.

Dennoch eignet sich DSC nicht für jedes Szenario. Wenn Sie z. B. Azure-PaaS-Ressourcen bereitstellen, wird Azure-Ressourcen-Manager für das Starten der VMs und Konfigurieren des Netzwerks empfohlen. Denn DSC ist nicht darauf nicht ausgelegt. Sobald die virtuellen Computer ausgeführt werden, können Sie DSC verwenden, um die lokale Konfiguration wie gewünscht einzurichten und sicherzustellen, dass die Konfigurationselemente, die Ihnen wichtig sind, sich nicht ändern.

Überwachung mit Application Insights

Sobald sich eine Anwendung und die Umgebung in der Produktion befinden, ist es wichtig, Daten zu sammeln und die Betriebsintegrität zu überwachen. Sie müssen zudem Nutzungsmuster verstehen. Diese Daten sind entscheidend für die Verwaltung eines fehlerfreien Diensts. Das Sammeln und Überwachen dieser Daten ist ein wichtiger Bestandteil von DevOps. Microsoft hat z. B. Produktionsdaten verwendet, damit die Visual Studio Online-Teams ihre Leistung verbessern können. Diese umfangreichen Daten helfen den Visual Studio Online-Teams, die Verfügbarkeit von Diensten zu gewährleisten, zeigen Ihnen, wie Entwickler das Produkt nutzen, und beeinflussen die Priorisierung von Features. Weitere Informationen zu DevOps bei Microsoft finden Sie unter bit.ly/1AzDL9V.

Visual Studio Application Insights fügt Ihrer Anwendung ein SDK hinzu und sendet Telemetriedaten an das Azure-Portal. Das SDK unterstützt viele verschiedene Plattformen und Sprachen, z. B. iOS, Android, ASP.NET und Java. Sie können Leistungsdaten, Betriebszeiten von Anwendungen und verschiedene Nutzungsanalysen erfassen. Sie können diese umfangreichen Daten Entscheidern und Projektbeteiligten zur Verfügung stellen, damit diese bessere Entscheidungen treffen, Probleme erkennen und Ihre Anwendungen kontinuierlich verbessern können. Weitere Informationen zu Application Insights finden Sie unter bit.ly/1IbRnrF.

Abbildung 4 und Abbildung 5 sind Beispiele für die Arten von Daten, die von Application Insights gesammelt werden.

Abbildung 4: Application Insights kann Daten zu Benutzern und Seitenaufrufen bereitstellen

Abbildung 5: Application Insights dient auch zum Überwachen von Webtests

Zusammenfassung

DevOps ebnet Teams den Weg in Richtung einer kontinuierlichen Bereitstellung und Nutzung von aus laufenden Anwendungen stammenden Daten, um Entscheidungen besser informiert zu treffen. In diesem Artikel wurden verschiedene Microsoft-Technologien untersucht, die zum Erreichen dieser Ziele geeignet sind:

Release Management ermöglicht Ihnen den Einsatz beliebiger Technologien zur Optimierung der Bereitstellung. Dazu gehören einfache Windows PowerShell-Skripts, DSC-Konfigurationen oder sogar Drittanbietertools, z. B. Puppet.
Infrastruktur-als-Code-Strategien sorgen dafür, dass IT-Entwicklungs- und Betriebsteams effizient zusammenarbeiten.
Visual Studio Application Insights ermöglicht das Erfassen umfangreicher Daten aus laufenden Anwendungen, mit deren Hilfe Entscheider die Integrität von Anwendungen und Nutzungsmuster bestimmen können, um Entscheidungen besser informiert zu treffen.

Dank dieser Technologien können Sie Ihr DevOps-Niveau erheblich verbessern. Sie müssen außerdem einen entsprechenden Satz von Technologien integrieren, um kulturelle Barrieren zu überwinden.

Weitere Ressourcen

Weitere Informationen zu Infrastruktur als Code bietet die von Brian Keller geleitete Diskussion auf Channel 9 unter bit.ly/1IiNqmr.
Weitere Informationen zu Bereitstellungsprojekten für Azure-Ressourcengruppen finden Sie unter bit.ly/1flDH3m.
Weitere Informationen zur TFS-Planung, Vermeidung von Notfällen und Wiederherstellung sowie zu TFS in Azure IaaS finden Sie in der Anleitung unter vsarplanningguide.codeplex.com.
Weitere Informationen zur Konfiguration als Code für DevOps- und ALM-Fachleute finden Sie unter vsardevops.codeplex.com.

Micheal Learned ist ein Visual Studio ALM Ranger mit aktuellem Schwerpunkt auf DevOps und Microsoft Azure. Er ist seit über 15 Jahren in zahlreichen Softwareprojekten innerhalb und außerhalb von Microsoft aktiv. Er lebt in Illinois, engagiert sich ehrenamtlich in seiner Freizeit und sucht im Familienleben mit seiner Frau, zwei Söhnen und einer Tochter Entspannung. Sie können ihm auf Twitter unter twitter.com/mlhoop folgen.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Donovan Brown (Microsoft), Wouter de Kort (unabhängiger Entwickler), Marcus Fernandez (Microsoft), Richard Hundhausen (Accentient), Willy-Peter Schaub (Microsoft) und Giulio Vian (unabhängiger Entwickler)