---

August 2016

Band 31, Nummer 8

Dieser Artikel wurde maschinell übersetzt.

Mobile DevOps - aus Code, um Kunden: Mehr zu DevOps für mobile Apps

Durch Kraig Brockschmidt | August 2016

Durch die Verlaufsdaten Standards ist das Schreiben von Code einfach. Heute profitieren wir enorm leistungsfähige Tools wie IntelliSense, automatische Vervollständigung Syntaxfarben Fehler hervorheben und Unterstützung durch Communities wie Stapelüberlauf. Wir können auch ein ständig wachsenden Repository besonders nützliche Bibliotheken und Tools, viele von ihnen frei. Es gibt jedoch eine große Lücke – eine regelrechte Kluft, man kann sagen – zwischen den reinen fungieren, Schreiben von Code und die Entwicklung von mobilen apps, die den höchsten Wert für Kunden bieten, und bei minimalen Kosten für Ihr Unternehmen tun.

Die verschiedenen Methoden, die zusammen bekannt sein, was im Wesentlichen DevOps sind mittlerweile können Sie diese Kluft zu überbrücken. Ich sage "verschiedene Vorgehensweisen", da es viele Möglichkeiten gibt, diese Bridge erstellen. Es gibt verschiedene Möglichkeiten, die Prozesse selbst definieren, und es gibt viele verschiedene Tools, mit denen Sie kommunizieren und diese Prozesse mit den beteiligten Personen verwalten – einschließlich Möglichkeiten, direkt aus Ihrer Kunden zu lernen. Daher scheint der gesamte Speicherplatz der DevOps häufig sehr chaotisch durch zu viele Auswahlmöglichkeiten und zu wenig Klarheit.

Glücklicherweise wie in dieser Serie von Artikeln ich werde, stellt Microsoft jetzt eine Antwort: eine vollständige End-to-End-Stapel, die DevOps für mobile apps und ihre zugeordneten Back-Ends ermöglicht. Dieser Stapel, siehe Abbildung 1, Visual Studio, Visual Studio Team Services und Team Foundation Server zusammen mit Xamarin-Test-Cloud, HockeyApp, Application Insights und CodePush besteht.

Abbildung 1 die primären Komponenten des Stapels Microsoft DevOps für Mobile Apps und Back-End-Dienste

Tool oder Dienst	Zweck mit DevOps
Visual Studio (bit.ly/25EVbAw)	Zentrale Entwicklungstool für app "," Services "und" Test Code zusammen mit der Diagnose und Integration mit Datenquellen-Steuerelement.
Visual Studio-Team-Dienste (bit.ly/1srWnp9)	Cloud-gehosteten Agile Planungstools, Versionskontrolle, Builddienste, Test-Services und Release Management. (Beachten Sie, dass Planungstools nicht in dieser Serie abgedeckt wird.)
Team Foundation Server (bit.ly/1TZZo9o)	Lokale Funktionen für Visual Studio Team Services vollständige Anpassungen von Servern und vollständige Kontrolle über die physischen Computer entspricht.
Xamarin Test Cloud (xamarin.com/Test-Cloud)	Automatische und manuelle Tests von allen mobiler apps (einschließlich der nicht mit Xamarin geschrieben) auf Tausende von realen, physischen Geräte über ein Webportal.
HockeyApp (hockeyapp.net)	Starten Sie vorab app direkt auf Geräte der Test-Kunden (nicht im Zusammenhang mit Plattform-app Stores) verteilt. Auch vorab starten und Überwachen der Produktion mit benutzerdefinierte Telemetrie, Absturz Analysen und Berichte Benutzer-Feedback.
Application Insights (bit.ly/1Zk9Qd3)	Telemetrie, Diagnose und Überwachung von Back-End-Dienste.
CodePush (bit.ly/28XO7Eb)	Bereitstellung der app updates für Cordova und reagieren systemeigenen apps direkt auf den Geräten der Benutzer ohne Umweg über app-Stores.

Dieser Stapel gilt für alle Arten von mobilen apps: systemeigene apps, die für eine einzelne mobile Plattform Hybriden apps mit Apache Cordova geschrieben und plattformübergreifende apps mit systemeigenen reagieren oder Xamarin geschrieben. Noch besser: kein DevOps Engagements nichts. Stattdessen wird ein System von lose verbundenen Aktivitäten und Methoden, die Sie inkrementell für die Erstellung von echten Mehrwert für Ihr Unternehmen erstellen mobiler apps umfasst. Es ist auch möglich, mit neuen Projekten, die gesamte DevOps-Pipeline zu erstellen, bevor eine einzige Codezeile geschrieben werden.

Der Ansatz, den ich in dieser Reihe erörtert wird auf verschiedenen Stufen der Pipeline"Version" konzentrieren und betrachten, welche Teile des Stapels DevOps ins Spiel. In diesem ersten Artikel jedoch müssen ich zunächst einige erforderlichen Hintergrundinformationen herstellen. Zunächst soll beschrieben wird, was eine releasepipeline ist und identifizieren die Aktivitäten, die gesamte besprechen müssen für DevOps und die Rolle des Tools und Automatisierung. Als Nächstes werde ich das Projekt MyDriving als Beispiel für DevOps in Aktion (und ein weiteres Beispiel finden Sie in dieser Ausgabe im Artikel "Einführen DevOps beim Erstellen eines Visual Studio Team Services-Erweiterung"). Schließlich wird die zentrale Rolle untersucht, die Visual Studio Team Services (und Team Foundation Server) innerhalb des gesamten DevOps-Abschnitts, spielen die Stufe für die Überwachungsphase Artikel festlegen.

Die Releasepipeline

Die Idee einer Pipeline ist, dass bestimmte Version einer app oder ihre Back-End-Dienste den Code und andere Artefakte aus irgendeinem Grund aus dem Projekt Quellcoderepository Kundengeräte und Kunden zugänglichen Server geleitet werden müssen. Einmal auf diesen Geräten und Servern Erkenntnisse aus Telemetriedaten und direktem Feedback von Kunden alle weitergegeben werden müssen als Erkenntnissen, die nachfolgende Laufwerk freigibt, Runtime Probleme (stürzt ab).

Natürlich ist keine dieser Magic. Eine Reihe von Phasen nach erfolgt Code in das Repository übernommen wird Siehe Abbildung 2. Die einzelnen Phasen umfassen:

• Build/CI: Die app erstellen und Ausführen von Komponententests. fortlaufende Integration (CI) bedeutet, dass ein Commit für das Repository Auslösen einer erstellen und den Test ausführen, wenn diese Prozesse automatisiert werden.
• Interne QA: Führen Sie eine beliebige Anzahl von zusätzlichen Tests und abzurufen Sie genehmigende Person Signoffs.
• Vor Start oder externen QA: Setzt die app in die Hände der echten Kunden vor der Veröffentlichung, Testen der app und die Dienste unter realen Bedingungen und Sammeln von Feedback. Diese Phase kann auch zusätzliche Genehmiger Signoffs umfassen.
• Produktion, Überwachung und lernen: Unabhängig davon, wie viele Tests es Sie, Kunden mit großer Wahrscheinlichkeit auftreten werden, sobald die app veröffentlicht wird (d. h. "Freigabe zur Produktion"). Kunden erhalten, Feedback zu was funktioniert und was nicht sind, und die Verwendungsmuster vom Telemetrie.

Abbildung 2 die Phasen einer normalen Release-Pipeline mit zugeordneten DevOps-Aktivitäten

Sie sehen in Abbildung 2 ich die meisten DevOps Aktivitäten wie eine Form des Testens gekennzeichnet haben. In der Tat ist es nicht viel von jeder Aktivität als eine Art von Tests darüber nachdenken. Ausführen eines Builds testet z. B. die Struktur des Repositorys und gibt an, ob alle anderen Elemente sind, in denen sie sein müssen. Ausführen von Diagnosetools ist eine Form der explorative Tests. Erfassen und Analysieren von Telemetriedaten ist eine Möglichkeit, Testen Ihre Annahmen darüber, wie Kunden die app verwenden. Und welche genehmigende Person Signoffs, wenn keine direkte Überprüfung von einem Menschen, die alles ist der Fall sein sollte?

Kontinuierliche Überprüfung der Leistung

Verschiedene Formen der Tests sein alle Aktivitäten, die in der DevOps-Schirm fallen zum Überprüfen der Qualität, Zuverlässigkeit und Wert der app bereitgestellt. Anders ausgedrückt, die Aktivitäten dienen zum Abfangen oder identifizieren Fehler, d. h. alle Elemente, die die app abweichen, erfüllen die Erwartungen der Kunden verursacht. Es versteht fast sagen dann, die häufiger Teilnahme DevOps Aktivitäten – fortlaufend, wenn möglich – die bessere Möglichkeit der Suche nach Problemen vor Veröffentlichung stehen Ihnen.

DevOps Aktivitäten dienen auch catch-Fehler so früh wie möglich in der Pipeline, die Kosten des Behebens niedrigsten (dargestellt durch die blaue Linie in Abbildung 2). Natürlich gehen Sie Kosten sehr viel höher, sobald die app veröffentlicht wurde und Fehler sind, öffnen, an welcher Stelle die Kosten verlorene Kunden umfassen möglicherweise beschädigen und Ihre sogar Haftungsrisiken!

Platzieren alle diese zusammen und apps, die bieten des höchsten Werts für Kunden, und dies bei minimalen Kosten, Ihr Bestes "und" Was sie letztendlich für Ihr Unternehmen leisten verursacht werden. Einfach ausgedrückt, hervorragende apps sind hervorragende ausführende. Aus diesem Grund wie ich DevOps als die kontinuierliche Überprüfung der Leistung im weiteren Sinne des Begriffs vorstellen. DevOps ist für die Softwareentwicklung, welche Schulung, üben, Testläufe, und nach der Leistungsdaten sind öffentliche Konzerte, Sportler und anderen ausführenden in ihren jeweiligen Feldern. Es ist, wie Sie kennen und vertrauen und überwachen den vollständigen Wert der was, sowohl für Kunden als auch für Ihr Unternehmen leistet.

Verarbeiten Sie zuerst, dann Tools und Automatisierung

In einer Reihe zu den Tools der Stapel für mobile DevOps Microsoft glauben Sie, dass der nächste Schritt besteht dieser Tools direkt und DevOps "ausführen" starten. Aber DevOps beginnt nicht mit Tools oder sogar etwas zu automatisieren. Die Grundlage für DevOps wird über die Prozesse und Richtlinien, die festlegen, wie Ihre apps und Dienste in die Hände der Entwickler in die Hände Ihrer Kunden verschieben. Es ist wirklich ganz einfach. So einfach, tatsächlich das sicherlich eine gesamte releasepipeline definieren und dann die erforderlichen Schritte auf Papier aufzuschreiben jeweils manuell ausführen.

Dies ist auch der schwierigste Teil einer Reise zum effektiven DevOps ab. Innerhalb einer teamumgebung vor allem ein junges Team, das versucht, schnell eine möglicherweise bestehen eine Reihe von Schritten, die ad-hoc-entwickelt haben, dass einzelne Teammitglieder "zu denken" führen. Dazu einige Beispiele:

• Führen Sie einen build
• Einige Tests ausführen
• Überprüfen Sie, dass die Elemente nach rechts nicht Code vorhanden sind
• Sammeln von Feedback von Benutzern
• Das app-Paket an den entsprechenden Speicher buchen
• Bereitstellen von Service-Code an den entsprechenden Server (Dev, staging, Produktion usw.)
• Ändern Sie einen API-Schlüssel von Dev in Produktion
• Tweet-Verfügbarkeit
• Aktualisieren der Seite auf Ihrer Website

Mit der von kurzen entwicklungsiterationen, alle diese Aktivitäten können problemlos werden also enmeshed in das Team tägliche Routine, die niemand durchführt, es wird keine Sie überall tatsächlich geschrieben wird – bis natürlich jemand in Urlaub geht, ruft Krankheit oder das Unternehmen verlässt. Wenn nur in der Benutzer bei der Ausführung aller Prozesse zur Veröffentlichung und Richtlinien vorhanden sind, ist es schwierig, diese durchgängig zu übernehmen. Sie erhalten unweigerlich mit Hunderten von anderen unabhängigen dennoch wichtigen Aufgaben miteinander verwoben. Dies birgt deutlich, insbesondere in Umgebungen, die eine einzelne Aufsicht verheerend sein kann.

Genügend Zeit, alle Schritte zum eindeutig zu identifizieren, definieren Sie einen Prozess, der vorhersagbaren, wiederholbare und überwacht wird. Bei allen ausgeschrieben an einem Ort, der für alle zugänglich ist erleichtert auch den Prozess überprüfen und ändern, da die gegenseitigen Abhängigkeiten sichtbar sind. Dies ist wiederum die Grundlage für das Anwenden von Tools und Automatisierung. Andernfalls wäre es z. B. eine Reihe von industriellen Maschinen einrichten, um Widgets zu erstellen, ohne zu wissen, Worum handelt es sich, dass Sie tatsächlich in erster Linie erstellen möchten.

Wir werden dies sehr deutlich. Automation ist nicht tatsächlich in jeder versionspipeline wichtig – jeder Schritt kann manuell ausgeführt werden, falls erforderlich. Dies schließt auch einfache jedoch zeitaufwändige Fragen wie Notification-e-Mails senden. Jedoch manuelle Prozesse skalieren, fehleranfällig, um menschliche Fehler häufig mühsam (und daher etwas langweilig Menschen) und gefährden jeder Schritt Wettbewerb um die Aufmerksamkeit der menschlichen Mitarbeiter die andere Arbeit teuer sind. Computer, sind auf der anderen Seite sehr fundierte Kenntnisse endlos wiederholten und innehalten einfache Aufgaben ohne die erste gebohrten oder fahrlässiger. Es ist auch viel einfacher, einige weitere Computer hinzuzufügen, wenn erhöht und sie außer Betrieb nehmen, wenn Anforderungen ausfallen, anstatt sie qualifizierte Mitarbeiter einstellen (und ausgelöst).

Der Zweck der Automatisierung, dann ist gleichzeitig die Kosten zu senken und die Häufigkeit und die Qualität Ihrer Prozesse erhöhen, wie sie definiert sind, die Tools getrennt. Also wenn die Prozesse und Richtlinien vorhanden sind, können Sie dann inkrementell automatisieren verschiedene Teile, verwenden Sie Tools, Richtlinien durchzusetzen und alles in ein Formular, das transparent und überwacht wird. Sobald Sie dies tun, freie menschlichen Mitarbeiter auf diese Bereiche konzentrieren, die sofort von einem Computer, z. B. Überprüfen und Interpretieren von Feedback der Benutzer behandelt werden nicht entwerfen Telemetriedaten Ebenen, bestimmen die effektivsten Formen von Tests und ständig verbessert die Qualität der DevOps-Aktivitäten, die vorhanden sind.

Ein Beispiel: das MyDriving-Projekt

Jetzt sehen wir, wie all dies zusammen mit Microsoft mobile DevOps Stapeln kommt anhand der bereits arbeiten mit dem Namen MyDriving (aka.ms/iotsampleapp), die von Scott Guthrie bei Microsoft Build 2016 ab. MyDriving ist ein umfassendes System, das sammelt und verarbeitet Internet der Dinge (IoT) Daten über eine anspruchsvolle Azure Sicherung beenden und Visualisierung der Ergebnisse über eine mobile Anwendung mit Xamarin geschrieben und Microsoft Power BI bietet. Es wurde als Ausgangspunkt für ähnliche IoT-Projekte erstellt und umfasst vollständigen Quellcode, Skripts der Azure-Ressourcen-Manager-Bereitstellung und eine vollständige Referenz e-Book.

Für meine Zwecke sind Pipelines Version MyDriving von besonderem Interesse. Ich verwende die Pluralform Hier stehen vier von ihnen, weil: eine für den Back-End-Code, der in Azure App Service bereitgestellt wird und jeweils eine für die Xamarin-app für iOS, Android und Windows.

Hier wird eine Übersicht über den Pipeline-Fluss, einschließlich einige Aktivitäten, die gegenwärtig sind nicht implementiert:

• Verwalten von Quellcode in einem GitHub-Repository (bit.ly/28YFFWg).
• Ausführen von builds mit dem Code in das Repository, einschließlich der folgenden Unterschritte:
  • Ersetzen von Token mit erforderlichen Schlüssel je nach Umgebung (Entwicklungs-, Test, Produktion).
  • Wiederherstellen von erforderlichen NuGet-Pakete und Xamarin-Komponenten.
  • Aktualisieren Sie diese Version und Zahlen.
  • Führen Sie den Build (mit den MacinCloud-Dienst für iOS).
  • (Nur app) Erstellen Sie und signieren Sie das app-Paket gemäß der mobile-Plattform.
  • (Nicht implementiert) Alle verfügbaren Einheit Testprojekt zu erstellen.
  • (Nicht implementiert) Führen Sie Tests im Test-Projekt, den Build fehlschlagen, wenn alle Tests fehlschlagen.
• Für den Code:
  • Kopieren Sie die Ausgabe des Builds erfolgreich getestet, auf einem Stagingserver.
  • Aus dem staging-Server auf einem Testserver bereitstellen und Ausführen von Tests.
  • Wenn dies erfolgreich ist, auf dem Produktionsserver bereitstellen Sie, und wiederholen Sie den Test ausführen.
  • Überwachen Sie des Diensts, und rufen Sie Diagnoseberichte mithilfe von Application Insights.
• Für die mobile Anwendung auf allen Plattformen:
  • Bereitstellen der Anwendung in Xamarin-Test-Cloud und Ausführen von UI-Tests, die den Build fehlschlagen, wenn alle UI-Tests fehlschlagen.
  • Wenn der Build und UI-Tests erfolgreich sind, kopieren Sie das app-Paket auf einem Stagingserver.
  • Bereitstellen Sie die app aus dem staging-Server alpha Testern über HockeyApp.
  • (Nicht implementiert) Bereitstellen Sie bei genehmigende Person einholen die app für Betatester über HockeyApp.
  • (Nicht implementiert) Drücken Sie nach zusätzlichen Genehmiger einholen die app an den entsprechenden app Store.
  • Überwachen Sie die app mit Telemetriedaten und Absturzberichte über HockeyApp.

Wie Sie sehen können, ist dies eine einfache Liste von was für jede Version ausgeführt muss. Doch insbesondere beschreibt, was geschehen muss, und werden einige der Dienste beteiligt sind, aber nicht angeben, die die Schritte führt. Dies ist sehr wichtig, da Mensch immer mit der Liste Hinsetzen und jeden Schritt manuell ausführen können. Tatsächlich, das ist genau das, was in den frühen Tagen des MyDriving geschehen ist: Wir haben manuelle Builds usw., damit wir Test apps sofort in den Händen abrufen konnte. Aber, gleichzeitig mit dem Entwicklungsteam Arbeit, andere konzentriert sich inkrementell verschiedene Schritte automatisieren, bis die gesamte releasepipeline automatisiert wurde eingerichtet.

Eine ähnliche Story wird mitgeteilt, in einem anderen Artikel in dieser Ausgabe "Auf ein Softwareentwicklungsprojekt DevOps anwenden". Beachten Sie insbesondere, wie im Abschnitt "Erstellen und Veröffentlichen einer Erweiterung" funktioniert genau wie ich hier gesprochen haben: Es wird eine Übersicht über die genauen Schritte im Freigabeprozess schreibt. Der Rest dieses Artikels erläutert dann, in Worten des Autors "Unsere Wandlung gegen einen automatisierten Build- und releasepipeline."

Die zentralen Rolle von Visual Studio Team Services-Team Foundation Server

Im Projekt MyDriving Visual Studio Team Services (Team Services kurz) dient als Hub für die Verwaltung und Automatisierung der freigabepipelines und die Interaktionen mit verschiedenen Diensten (siehe Abbildung 3). Da MyDriving als open-Source-Projekt von Anfang erstellt wurde, nicht mit Cloud-gehosteten Dienst wie Team Services ein Problem. Für andere Szenarien Organisationen möglicherweise nicht vertraut oder zulässig, um die Cloud zu verwenden, in der Fall Team Foundation Server (TFS) die gleiche Funktionalität mit Ihren eigenen lokalen Servern bereitstellt. In meiner Reihe werde ich in erster Linie im Kontext von Team Services funktionieren, aber beachten Sie, dass alles auch für TFS gilt.

Abbildung 3 Visual Studio-Team Services-Dashboard für MyDriving

Die wichtigsten Funktionen sind hier aufgeführt (finden Sie unter Abbildung 4 für die Platzierung in der Benutzeroberfläche des Team Services):

• Datenquellen-Steuerelement: Unbegrenzte, private und öffentliche Quell-Repositories, die mithilfe von Git oder Team Foundation Version Control (TFVC) hosten oder einfach arbeiten mit Repositorys auf GitHub.
• Agile-Planung: Nachverfolgen von Arbeitsaufgaben, User Storys und usw. Zusammenarbeit auf Kanban-Boards, Berichte und so weiter. (Beachten Sie erneut, dass die Planung in dieser Serie abgedeckt sind.)
• Build: Erstellen Sie Builddefinitionen für Dienstcode und mobile apps (iOS, Android und Windows), mithilfe einer Vielzahl von verfügbaren Aufgaben erstellen, die Testprojekte (für die kontinuierliche Integration) ausgeführt und auf Xamarin testen Cloud (XTC) bereitstellen.
• Release Management: Definieren Sie beliebige Sequenzen mit optionalen manuelle Genehmigungen für alle Aufgaben, die zwischen stattfinden erstellen und "Umgebung", freigeben z. B. HockeyApp, Azure oder einem app Store bereitstellen. Release Management basiert auf den Umgebungen Sie definieren möchten, z. B. Staging, Alpha, Beta und Produktion.

Abbildung 4-Speicherort der Features in Visual Studio Team-Dienste

Das Ende einer Pipeline, Teamdienste betrifft, ist der Punkt, an dem eine app an seine letzte zugewiesenen Umgebung gesendet wird (siehe Abbildung 5). Danach DevOps hauptsächlich aktive Überwachung der app in diesen Umgebungen. Dies ist HockeyApp und Application Insights kommen ins Spiel spielen, zusammen mit anderen Mechanismus Sie einrichten für zusätzliche Benutzerfeedback erhalten (siehe Abbildung 5).

Abbildung 5 DevOps-Datenfluss für das MyDriving-Projekt, in dem das Coderepository auf GitHub ist abgeschlossen

Blick in die Zukunft

Am Anfang dieses Artikels wurde erwähnt, dass die verschiedenen Aktivitäten und Vorgehensweisen, bezeichnet als DevOps Was sind die Lücke überbrücken zwischen dem Schreiben von Code und Kunden bei minimalen Kosten für Ihr Unternehmen liefern. Sie können sehen, dass der Microsoft-Stapel für mobile DevOps alles enthält, müssen Sie die Qualität verwalten, geringere Kosten durch Automatisierung, erhalten die app und die Dienste in die Hände von Kunden, die kontinuierliche Überwachung von Status und die Vorgänge und Sammeln von Feedback der Benutzer, alle die Feeds wieder in den Rückstand nachfolgende Versionen. Das ist der DevOps-Zyklus – Code Commit zu Rückständen –, die ich werde in den nächsten Monaten noch ausführlicher untersuchen werden.

---

Kraig Brockschmidt arbeitet als leitender Entwickler von Inhalten für Microsoft und konzentriert sich auf DevOps für mobile apps.  Er ist der Verfasser von "Programming Windows Store Apps with HTML, CSS and JavaScript" (zwei Ausgaben) bei Microsoft Press, und er veröffentlicht in seinem Blog unter kraigbrockschmidt.com.

Dank der folgenden technischen Experten für die Überprüfung dieses Artikels: Donovan Brown, Meier Jonathan, Glenn Gailey und Karl Krukow