---

Oktober 2016

Band 31, Nummer 10

Dieser Artikel wurde maschinell übersetzt.

Mobile DevOps: Transformieren von Quellcode in bereitstellbare Artefakten mit TFBuild

Durch Kraig Brockschmidt | Oktober 2016

In meinem letzten Artikel "die Informationsquelle: Die Rolle des Repositorys in DevOps "(bit.ly/2bKeC2T), erörtert wichtige Rolle, die Datenquellen-Steuerelement in der gesamten Version Pipeline dargestellt spielt Abbildung 1. Ich habe die releasepipeline beschrieben, wie die Auflistung der Prozesse, die Code im Quell-Repository in Vorlagen-apps und Dienste zu transformieren und übermittelt diese an Kundengeräte und Kunden zugänglichen Server. Die versionspipeline ist ebenfalls einfach eine Liste der Schritte, die erforderlich sind, um eine Version ausgeführt, unabhängig von der Automatisierung zu machen. Die Praxis DevOps beginnt daher mit zu wissen, welche Schritte und Prozesse in einer Version beteiligt sind, nach denen Sie dann inkrementell automatisieren können diese Prozesse zur Kostensenkung und Verbesserung der Qualität.

Abbildung 1 Build Quellcode in den Rest der Releasepipeline erforderlichen Elemente transformiert

Dieser Artikel konzentriert sich auf den Build/Continuous Integration (CI)-Phase der Pipeline für mobile apps (beschrieben Abbildung 1). Befindet, wo es mich Build auf diese Weise: Build ist, welche Transformationen in getestet werden und für die Bereitstellung Artefakte Quellcode nach Bedarf durch den Rest der releasepipeline. Die Ausgaben des Builds sind, also die Eingaben für die übrigen Phasen der Pipeline, die arbeiten oder Buildartefakte bearbeiten. Alle Arten von Tests ausgeführt z. B. ausführbare app und Dienst-Code nicht auf die unformatierte Quellcode. Und natürlich benötigen Sie die entsprechenden Binärdateien für app-Stores und Webserver bereitstellen. Sogar in Fällen, in denen Quelldateien wechseln Sie über die Pipeline mehr oder weniger unverändert (wie viele JavaScript, HTML und CSS-Dateien mit in einer Apache Cordova-app, z. B.), Build weiterhin erfüllt die Rolle die entsprechenden Pakete erstellt Zusammenfassen von Dateien, Anwenden von Präprozessoren und Minifiers, und so weiter.

Stellen Sie sich Build wie zur physischen Erstellung. Ein großer Stapel zum Erstellen von Materialien wie Holz, konkrete und Rebar, Nägel, Schrauben, Windows, Pipe, über das Netzwerk, Vorarbeiter, Isolierung, Fixtures usw., enthält das Potenzial für ein Haus, aber der Stapel wird nicht automatisch aktiviert selbst in eine solche Struktur. In diesem Fall nur durch eine Person wenden das wissen, all diese Teile zusammen gesagt, Schritt für Schritt zu erhalten. Das ist was "einen Build ausführen" geht. Im Bereich der mobilen apps möglicherweise vor allem es sogar betont werden, dass es mehrere Stapeln von Quelle Materialien, von die einige für die Zielplattformen freigegeben werden, und andere für eindeutig sind.

Natürlich ist ein großer Vorteil mit Software, einen Build Ausführen der Quelle Materialien im Prozess verwendet. Sie können einen Build beliebig oft beliebig, so oft wie gewünscht, und wenn der Prozess, sehr wenig Kosten automatisiert wird durchführen. Fortlaufende Integration basiert auf dieser Merkmale. Sie erstellen mehrere unabhängige Elemente aus dem Quellcode, von denen jeder eine eigene versionspipeline besitzt. Dies ist häufig der Fall bei mobilen apps. Im Projekt MyDriving (aka.ms/iotsampleapp), im Beispiel ich habe wurde verweisen auf in dieser Serie, es gibt separate Builds für iOS, Android und Windows, und der Code, der in Azure App Service bereitgestellt wird, wie in dargestellt Abbildung 2. (Beachten Sie, dass Sie Build-Konfigurationselemente für fortlaufende Tests für Ihr Entwicklungsteam ohne unbedingt in einer versionspipeline gespeist verwenden können.)

Abbildung 2 das MyDriving-Projekt verfügt über vier Builds und vier Freigabepipelines

Wissen Sie auch, dass Visual Studio Team Services zeichnen können aus Repositorys außerhalb eines Teamprojekts können Sie bestimmte Bibliotheken für Ihre app in öffentlichen, open-Source-Repositorys verwalten, während die proprietären Teile vertraulich behandelt werden. Alle angegebenen Builddefinition aus nur einem einzigen Repository zeichnen kann, aber ein Teamprojekt können eine beliebige Anzahl von Builddefinitionen verwenden.

Die Rolle des Builds in DevOps

In professionellen Konstruktion Besatzung, die Häuser und andere Gebäude arbeiten, ist eine Person immer überprüfen, ob alle erforderlichen Materialien für mindestens der nächsten Tage Arbeit verfügbar sind. Diese fortlaufende Überprüfung verbessert die Effizienz und Produktivität der Besatzung zu sagen, deren Leistung und ist sehr wichtig für die Übermittlung von Ergebnissen, Zeit und Budget. Build wird dasselbe Software erreicht. Wie bereits erwähnt in "aus Code, um Kunden: Untersuchen die Mobile DevOps"(bit.ly/2ayD9Zw), alle DevOps-Aktivitäten und Methoden sind bedeutet, dass die Leistung Ihrer apps und Dienste ständig zu überprüfen. (In diesem Fall bedeutet "Leistung" den größten Wert für Ihre Kunden bei minimalen Kosten für Ihr Unternehmen liefern.) Daher ist Build grundsätzlich eine Möglichkeit, den Inhalt von einem Quellcoderepository überprüfen, da Sie erwarten, dass alles vorhanden ist.

Ein Build (ausgenommen zusätzliche Tests, die ausgeführt werden können) wird im Allgemeinen nur eine der beiden Ergebnisse: Erfolg oder Fehler. Erfolg bedeutet, dass das Quell-Repository die Dateien gegebenenfalls erstellbare getestet und für die Bereitstellung Artefakte zu erzeugen enthält. Hat dies zur Folge, dass eine oder mehrere Dateien werden (sie haben ein Syntaxfehler), oder, dass etwas aus dem Repository nach der Art den Build fehlt konfiguriert ist. (Diese Konfiguration kann selbst fehlerhaft natürlich handeln.)

Idealerweise sollten Sie so schnell wie möglich bekannt sein, wenn ein Fehler, der den Build "unterbrochen" in das Repository eingeleitet wird. Dies ist, wo Buildautomatisierung einen enormen Vorteil, da Sie einen Build ausführen können, und erhalten sofortige Validierung, wenn eine Änderung in das Repository wird. Dies wird als fortlaufende Integration bezeichnet.

Continuous Integration

In der Vergangenheit waren Builds häufig komplexe, mühsam Prozesse, die für große Projekte in der Regel einen oder mehrere rund Mitarbeiter erforderlich. Aus diesem Grund wurden Ausführung nur selten, nach welcher Zeit Hunderte oder sogar Tausende von Änderungen wurden in das Repository übernommen. Da eine beliebige Anzahl von diese Änderungen in beliebiger Kombination zum Fehlschlagen des Buildvorgangs führen kann, könnte echten Albtraum zum Abrufen der Änderungen eines funktionierenden Builds integriert sein. Ich erinnere mich noch ein paar anspruchsvoll Projekte von Microsoft, die einfach abgebrochen wurden, da sie tatsächlich konnte nicht erstellt werden.

Vermeiden von solchen heraus erhält Aufstieg CI. Hier ist, wie es mir:

1. Da Ihr Repository Build überprüft hat, möchten Sie natürlich Builds frühzeitig und häufig ausführen.
2. Wenn Sie Builds automatisieren können, stellen Sie den Prozess wiederholbare sehr wenig Kosten.
3. Wenn Sie eine Änderung im Quellrepository automatisch einen Build auslösen können, haben Sie CI erzielt.

CI, kurz gesagt, jede Änderung an der Quell-Repository so nah wie möglich an die Änderung überprüft und an den entsprechenden Entwickler sofort benachrichtigt, wenn der Buildvorgang fehlschlägt. Funktionen wie Abgegrenzter Eincheckvorgang (mit Team Foundation Version Control) oder pullanforderung (PR)-Generator mit Git auch auslösen kann einen Build mit den neuen Code vor dem Einchecken oder zusammengeführt, hat, damit das Repository geändert wird, nur, wenn der Build erfolgreich erstellt wurde. In beiden Fällen erkennt CI schnell fehlerhaften Code in das Repository (einschließlich Code, die automatisch ausgelöste Tests fehlschlägt, jedoch ist dies der Gegenstand einer zukünftigen Artikel).

All dies ist mit CI-Buildautomatisierung eine der am häufigsten verwendeten DevOps-Methoden. In der Tat, selbst wenn Sie alles in der versionspipeline manuell durchführen, finden Sie früh im Datenquellen-Steuerelement mit automatisierten Builds und CI Investition lohnt, ist besonders dann, wenn ein Projekt komplexer wird.

Der Aufbau von Builds

Build benötigt mindestens drei Komponenten: der Quellcode, einen Build-Agent und eine Builddefinition, d. h.: der Code zu erstellen; ein Computer, auf dem die erforderlichen Tools und SDKs, um Elemente aus dem Code zu erzeugen; und einen Satz von Anweisungen, die dem Computer anweisen, wie Sie dabei. Die grundlegenden Beziehungen werden im dargestellt Abbildung 3. (In diesem Fall es ist natürlich möglich, mehrere Repositorys, Builddefinitionen und build-Agents, wie in den Abbildung 2.)

Abbildung 3 die grundlegenden Beziehungen zwischen Quell-Repository, eine Builddefinition, einen Build-Agent und die resultierende Build-Elemente

Auch wenn die Begriffe "Build-Agent" und "Builddefinition" neue erscheinen, schon Sie tatsächlich seit Ihrer ersten Tag der Codierung mit einem ultimative Programm "Hello, World!" verwenden sie:

1. Einige Programmiertools auf Ihrem Computer installieren, müssen aktiviert Sie es in einem Build-Agent.
2. Ein kurzes Programm, und es in einer Datei speichern, haben Sie das erste Datenelement des Quellcodes erstellt.
3. Wenn Sie in einem Befehl zu kompilieren und verknüpfen diesen Code eingeben, eine Builddefinition erstellt und ausgeführt wurde einen Build in eine ausführbare EXE-Datei. (Moderne JIT-Tools wie Microsoft .NET Core in der Regel Programm kompilieren und Ausführen der zusammen.)

Natürlich, sobald Sie wissen, dass ein Gespür für gestartet mit Programmieren Sie viel mehr Code schreiben, Umgestalten von Code in mehreren Dateien und viel komplexere Projekte erstellen. An diesem Punkt ist seit Befehle immer wieder eingeben mühsam, damit die Builddefinitionen, die wahrscheinlich Form von Batch-Dateien oder andere Skripts gedauert hat. Schließlich haben Sie auch nicht mehr warten, bis alles neu kompilieren, jedes Mal, wenn Sie einen Build ausgeführt, folglich ermittelt die Vorzüge von Systemen wie z. B. NMAKE und MSBuild mit Makefiles und Projekt Dateien bzw. als Builddefinitionen dient. Diese Systeme können Sie die Wechselbeziehungen zwischen Dateien definieren, so, dass Sie neu kompilieren erheblich verkürzen der Bearbeiten-Build-Test-Dev-Schleife nur was erforderlich ist.

All dies ist zu sagen, dass da Softwareentwicklung ständig weiterentwickelt, ist auch die Komplexität der Build-Tools, die Ihnen zur Verfügung. Bis vor kurzem machen diese tools als skalierbare Cloud-Dienste zur Verfügung – was wir Team Foundation Build oder TFBuild Aufrufen – die Grundlage für die nächste Generation festgelegt.

Server, Warteschlangen, Agents und Pools

Wenn Sie alleine arbeiten, installieren allmählich weitere Tools und SDKs auf dem Entwicklungscomputer Sie somit einen umfangreicheren und leistungsfähigere-Agent. Lange jedoch ist es sinnvoll, einen zu erstellen oder mehrere dedizierte Server, auf denen Sie problemlos verwalten können, die Umgebung erstellen. Dies ist besonders wichtig, mit Teams, da wird vermieden, dass jedem Entwicklercomputer die erforderlichen Tools synchron zu halten. Verwalten von solchen Buildserver, durch einen anderen gemeinsamen Verwaltungsaufgaben wie Steuerelement, Nachverfolgen von Arbeit und testen, die Erstellung der Microsoft Team Foundation Server (TFS) und TFBuild vor mehr als einem Jahrzehnt.

Ein wichtiges Feature von TFBuild, insbesondere bei CI haben, ist die Fähigkeit zum Verwalten und Koordinieren mehrerer Build-Anforderungen über eine Warteschlange. Wenn Sie viele Entwickler Code im Laufe des Tages übergeben haben, werden viele Commits zweifellos auftreten, wenn bereits ein anderer Build ausgeführt wird. Möchten jedoch nicht abbrechen, Build, da mit CI jedes erfolgreich/Fehler Buildbericht einen bestimmten Commit zugeordnet werden soll. Zur gleichen Zeit, die weitere Anforderungen, die in der Warteschlange übereinander abrufen müssen die Entwickler länger Buildergebnisse warten.

An diesem Punkt müssen Sie das System skalieren bedeutet, dass ein Build-Agent von einem Computer wird. Technisch gesehen ist ein Build-Agent ein Dienst: Mehrere Agents können auf dem gleichen physischen Server ausführen ermöglicht vollständige Nutzung der Multi-Core-Computer durch Ausführen von parallelen Builds. Und wenn es sich bei dem Server Maximum erreicht ist, können Sie problemlos einen oder mehrere Computer mit zusätzlicher Agents hinzufügen.

Dadurch genannte einen Agent-Pool eine Abstraktion, die bezieht sich auf die kombinierten Leistung aller Agents, unabhängig davon, wie sie physische Computer verteilt sind. TFBuild, funktioniert in der Tat Agent Pools anstelle von Computern. Wird ein Build am Anfang der Warteschlange, von TFBuild auf die nächste verfügbare Agents im Pool delegiert. Agent-Pools können auch in anderen Teamprojekten, freigegeben werden, wie auf der Seite "Verwalten der Build und Bereitstellungssystem" unter bit.ly/2b0UwAg.

Mit mobilen app-Projekte besonders, benötigen Sie in der Regel mehr als eine Art von Agent, da jedes Zielsystem einen eindeutigen Satz von plattformspezifischen Tools und SDKs hat. Glücklicherweise Microsoft bietet Free-Agents für Windows, OS X und Linux, wie in dargestellt Abbildung 4. In diesem Artikel zeige ich Ihnen, das Einrichten einer Mac-Agent für iOS erstellt.

Abbildung 4 Windows, Mac und Linux-Agents und der Projekttypen können sie erstellen.

Erstellen von Servern in der Cloud

Jede Konversation zum Skalieren wird natürlich das Potenzial für die Migration dieser leistungsstarken in die Cloud, Richtlinien und Vorschriften zu ermöglichen. Mit Cloud-basierten Servern müssen die physischen Computer verwalten oder sogar der Umgebung. Cloud-computing auf nutzungsbasierte Preise, wodurch einfach und kostengünstig die Kapazität variiert je nach Bedarf auch zentriert ist. Dies ist, was über Visual Studio Team Services angeboten wird.

Services Team build-Agents "gehostete" enthält. Dies sind Windows-Computern, die mit einer Vielzahl von Tools und SDKs, vorkonfiguriert sind, wie in bit.ly/2aNFKis. Zum Zeitpunkt dieses Artikels kann ein gehosteter build-Agent praktisch, wenn Sie mit Visual Studio und der Java-Toolchain, einschließlich Windows und Android-apps, die mit Xamarin, Apache Cordova oder systemeigenen Tools erstellen können. Sie können eine beliebige Anzahl von Pools gehosteten Agent einrichten und in verschiedenen Preisstufen wie gewünscht organisieren.

Da die gehosteten Agents unter Windows ausgeführt werden, können nicht jedoch sie iOS-apps oder .NET Core/ASP.NET Core apps für Mac oder Linux erstellen. Hierfür müssen Sie die OS X oder Linux-Agents auf den geeigneten Computer installieren und verbinden die Agents mit Team Services, in denen Sie dann diese in Pools organisieren können. Auf ähnliche Weise können Sie Windows-Agent auf Ihren eigenen angepassten Computer installieren, die Software, die nicht auf den gehosteten Agents enthalten enthält. Und enthält virtuelle Computer, sowie von Diensten wie hier "Machine" MacinCloud.com. Alles in allem Teamdienste wirklich ermöglicht Ihnen das Arbeiten mit einer beliebigen Kombination der Cloud gehostete und lokale Agents.

Automatisieren von Builds mit Visual Studio Team Services

Lassen Sie uns nun eine automatisierte TFBuild mit kontinuierlicher Integration für eine Xamarin-app eingerichtet (etwa "Erstellen der Xamarin-App" am folgenden bit.ly/2aiy48y). Zunächst erstellen Sie ein neues Xamarin.Forms-Projekt in Visual Studio Xamarin Build Oktober 2016 aufgerufen. Als Nächstes erstellen Sie ein neues Teamprojekt dafür in Ihrem Team Services-Konto namens MSDN Magazine Oktober 2016 mit Git für die Datenquellen-Steuerelement. Veröffentlichen Sie anschließend den Code in das Teamprojekt in Visual Studio Team Explorer aus. Dies führt dazu, dass der Code wird im Team Services-Portal auf die Registerkarte mit Teamprojekt Code verfügbar.

Richten Sie jetzt eine Builddefinition für Android auf der Registerkarte "Build" im Teamprojekt, und klicken Sie dann auf + neu. Dadurch wird ein Dialogfeld mit einer langen Liste von builddefinitionsvorlagen für eine Vielzahl von selbsterklärend Projekttypen systemeigene und plattformübergreifende mobile apps. (Apache Cordova-Projekte erforderlich, eine Erweiterung aus dem Marketplace-Teamdienste; finden Sie unter bit.ly/2atxNgp Weitere Informationen.) Sie können auch mit der Definition eines leeren beginnen und erstellen sie schrittweise.

Wählen Sie für diese exemplarische Vorgehensweise die Vorlage Xamarin.Android, klicken Sie auf Weiter, um ein Dialogfeld zu öffnen, und geben Sie dann die ursprüngliche Einstellungen für das Quell-Repository, CI und der Agentwarteschlange (diese kann später geändert werden). Klicken Sie auf erstellen und Team Services öffnet des Definition Editors Siehe Abbildung 5. Rot gibt an, dass zusätzliche Informationen erforderlich ist, wie Sie mit der Registerkarte "Build" sehen können.

Vor dem Buildschritte durchlaufen Abbildung 5, lassen Sie mich zusammengefasst, was auf den anderen Registerkarten ist (Sie finden die vollständige Dokumentation zur bit.ly/2ayghJh):

• Repository ist, in denen Repositorys außerhalb das Teamprojekt, z. B. GitHub, Subversion oder jedem anderen Git-Server herstellen.
• Trigger festgelegt, wenn Builds mit den Optionen für Konfigurationselemente, erfolgen mit abgegrenztem Eincheckvorgang und geplante Builds (Nacht häufig verwendet). Beachten Sie, dass Sie immer einen Build manuell aus Team Services oder in die Warteschlange können Visual Studio Team Explorer.
• Optionen | Erstellen Sie Arbeitsaufgabe bei einem Fehler wird, wie Sie Arbeitsaufgaben zuweisen, jemand einen Build angefordert, der fehlschlägt. Bei Verwendung mit CI werden der Requestor immer der Entwickler, der ein den Code, der der Build ausgelöst Commit, wodurch einer engen Schleife zwischen Code-Commits, Builds und sofortige Benachrichtigungen der Fehler. (Es gibt auch Erweiterungen auf dem Markt Team Services für das Senden anderer Arten von Benachrichtigungen.)
• Variablen können Sie Token optional verschlüsselte Werte zuordnen, die Sie an anderer Stelle in der Builddefinition, z. B. Anmeldeinformationen verwenden können. Verschlüsselte Werte können aus der Builddefinition kopiert werden.
• Verlauf können Sie das Änderungsprotokoll für die Builddefinition. Dies ist wichtig, da die Builddefinition ist nicht Teil des quellrepositorys und noch Änderungen an der Definition im Build verursachen können.

Abbildung 5: die ursprüngliche Ansicht einer neuen Xamarin.Android-Builddefinition

Rückkehr zu Abbildung 5, beachten Sie, dass der Build ist alles über das Aktivieren von Quellcode in die Elemente, die im weiteren Verlauf der releasepipeline, d. h. anwenden bestimmte Tools auf den Quellcode über verschiedene Schritte erforderlich. Wie Sie sehen können, ist der erste Schritt in der Xamarin.Android-Vorlage NuGet-Wiederherstellung, da Sie nicht in der Regel solche Pakete zur Versionskontrolle hinzufügen. Wenn der Build-Agent für einen Build Code abgerufen werden, dann müssen sie diese Pakete wiederherstellen.

Als Nächstes wird die Vorlage (zum Zeitpunkt dieses Artikels) enthält Schritte zum Aktivieren und deaktivieren eine Xamarin-Lizenz, die jedoch nicht mehr erforderlich, weil Xamarin jetzt kostenlos ist. Es ist sicher, diese Schritte zu löschen, da sie so schnell trotzdem aus der Vorlage entfernt werden müssen.

Der Xamarin.Android-Projekt erstellen-Schritt ist was MSBuild auf der Android-Projekt in der Projektmappe ausgeführt wird. Durch Klicken auf diesen Schritt werden die Optionen wie in Abbildung 5, der Link "Weitere Informationen" am unteren Sie ausführliche Dokumentation zu dem Schritt findet. Beachten Sie die $ () Verweise auf Variablen, z. B. $(BuildConfiguration), die auf der Registerkarte "Variablen" auf "Release" festgelegt ist. Ausgabeverzeichnis ist auch die Position der Builddefinition auf deren Elemente für die Verwendung durch andere Buildschritte und sogar andere Teile der releasepipeline.

Die nächsten beiden Schritten erstellen Sie jedes Projekt in der Projektmappe, die enthält den Namen "Test" und dann die integrierte app mit Xamarin testen Cloud bereitgestellt und entsprechende Tests ausgeführt. Dies zusammen mit anderen Testschritten hinzugefügt, durch die + Add Build Schritt... Befehl, ist, wie Sie Ihre CI Testläufe einschließt. Da vorhanden zu diesem Zeitpunkt keine Testprojekte in meiner Lösung sind, kann ich einfach deaktivieren folgendermaßen durch Deaktivieren des enthaltenen Steuerelementoptionen | Aktiviert das Kontrollkästchen. Auf diese Weise die Schritte in der Definition bleiben, aber er werden nicht ausgeführt werden.

Die letzten beiden Schritte, wie Sie sehen können, Signieren Sie das Android-app-Paket, und veröffentlichen die Elemente an einem anderen Speicherort, bei Bedarf. Im letzteren Fall MSBuild bereits im vorherigen Schritt bereits seine Ergebnisse in einem Team Services-Ordner gespeichert, aber das ist nur für Personen mit Teamprojekt Berechtigungen verfügbar. Ein Schritt für veröffentlichen oder Datei kopieren (es gibt eine Reihe von Optionen im neuen Schritt von hinzufügen...) ist, wie Sie Speicherorte außerhalb des Teamprojekts Elemente kopieren.

Ausführen des Builds

Sobald Sie abgeschlossen und die Builddefinition gespeichert haben, klicken Sie auf Warteschlange erstellen..., um den Prozess zu starten. Wird ein Dialogfeld, in dem Sie wählen Sie die Warteschlange des Agents und der Git-Verzweigung (falls zutreffend) und zusätzliche Variablen und Anforderungen nur Build selbst festlegen können. Können diese Parameter ändern können Sie problemlos einen Build über den Pool für einen anderen-Agent ausführen, ohne die Builddefinition bearbeiten. Z. B. Wenn Sie bei der Migration von lokalen Agents gehosteten Agents sind, sollten um manuell Sie Warteschlange in die Warteschlange gehosteten Builds während der CI-ausgelöste Builds werden weiterhin auf Ihrem lokalen Agents ausgeführt. Wenn jetzt wechseln, Sie anschließend die Builddefinition bearbeiten und umleiten das CI baut auf die gehosteten Agents stattdessen.

In diesem Fall müssen ich nichts ändern, damit ich gerade den Build zu starten. Dadurch wird an eine Benutzeroberfläche, wo ich finden können, welche Schritte durchgeführt haben, welche Schritte ausgeführt wird und die Konsolenausgabe direkt aus dem Build-Agent. Zugegeben, es ist immer interessant, einen Build zu überwachen, wechselt – ich bin sicher, Sie genauso oft schon! Und sobald der Build abgeschlossen ist können Sie die Ausgabe zur weiteren Analyse herunterladen, wenn erforderlich.

Schließlich wird der Build erfolgreich abgeschlossen wurde oder ein Fehler auftreten. In beiden Fällen sehen Sie einen endgültigen Bericht, der in der Liste der abgeschlossene Builds für die Definition der angezeigt wird, wie in der linken Seite des gezeigt Abbildung 6. Dies ist, können Sie zurückgehen und überprüfen Sie jedoch viele Builds in Ihrem Teamprojekt beibehalten wird werden und natürlich neue Warteschlange erstellt. Diese gleiche Liste klicken Sie im Visual Studio Team Explorer wird angezeigt, wie dargestellt in der rechten Seite des Abbildung 6. Von hier aus können Sie auch neue Builds zur Warteschlange hinzufügen und neue Builddefinitionen erstellen.

Abbildung 6: TFBuild Ergebnisse Teamdienste (links) und Visual Studio (rechts)

Überzeugen Sie diese mit einem neuen aus einer Vorlage in Visual Studio erstellten Projekt selbst experimentieren. Insbesondere überprüfen Sie fortlaufende Integration in die Definition der Registerkarte Trigger, dann stellen Sie eine kleine Änderung in einer Datei Quellcode und Commit/Push es in das Repository. Sie können sehen, dass des neuen Builds automatisch in der Warteschlange die in der Definition in der Warteschlange Liste in Team Services und Visual Studio Team Explorer angezeigt wird.

Zusätzliche TFBuild Schritte

Eine Definition Buildvorlage ist natürlich nur ein Ausgangspunkt, und Sie können nur mit einer leeren Definition auf einfache Weise starten und jeden Schritt einzeln hinzufügen. In beiden Fällen möchten Sie vollständig mit alle verfügbaren Schritte öffnen vertraut, die jede Builddefinition, und klicken auf den Buildschritt hinzufügen... Befehl aus. Im Dialogfeld der hinzufügen-Aufgaben, die angezeigt wird, können Sie eine Vielzahl von benutzerdefinierten Builddefinitionen erstellen. Hier wird ein Überblick über die verfügbaren (die aktuelle Liste befindet sich immer am bit.ly/2biafxz):

• Erstellen Sie Aufgaben: Android (einschließlich Signieren) Ant, CMake, Gradle, Grunt, Gulp, in die Warteschlange eines Auftrags auf einem Server Jenkis Maven, MSBuild, SonarQube-Analyse für MSBuild, Visual Studio erstellen, Xamarin.Android, Xamarin.iOS, Xcode ("Build" und "Paket").
• Testaufgaben: Cloudbasierte Auslastungstests mit Apache JMeter oder Visual Studio Team Services; Cloud-basierten Leistungstests; veröffentlicht die Testergebnisse Abdeckung und Code. Führen Sie Funktionstests (CodedUI oder Selen); Visual Studio-Test (einschließlich der Bereitstellung von Agents) Xamarin-Test-Cloud.
• Paket ausführen: NuGet- und Npm-Tasks ausführen, Xamarin-Komponenten wiederherstellen, das Installieren von CocoaPods.
• Bereitstellen von Aufgaben: Bereitstellen von Azure-Clouddienst blob-VM WebApp; SQL-Datenbank Führen Sie Azure PowerShell-Skripts; Ausführen von PowerShell oder SSH-Skripts auf Zielcomputern; Verwalten von Azure-Ressourcengruppen; Bereitstellen von Azure Service Fabric-Anwendung. Kopieren Sie Dateien auf einem Remotecomputer.
• Hilfsprogramm Aufgaben: Verwalten von Zip-Dateien, Dateien entschlüsseln/kopieren/löschen. Ausführen von Batchdateien oder Befehlszeilen-Tools (einschließlich Bash und PowerShell); Hochladen von Dateien mit cURL; und Kopieren von Dateien.

Es gibt auch eine fehlerfreie Marketplace zusätzliche Aufgaben zur Auswahl bit.ly/2aiRnPh, Erweiterungen für Azure DevTest Labs finden Sie in Google Play, Bower, Docker, HockeyApp, CodePush, FTP, ReactNative, Apache Cordova und vieles mehr veröffentlichen. In diesem Fall Zeit etwas Kennenlernen, was möglich ist. Es ist besonders interessant, um Vorgänge für den Marketplace Google Play Docker, HockeyApp und CodePush, u. a. anzuzeigen. Zusammen mit der integrierten Bereitstellungsaufgaben führen sie vor, eine Aufgabe einfach am Ende der Builddefinition die Ergebnisse in anderen Umgebungen, einschließlich der Tests, staging und Produktion selbst bereitstellen platziert werden können.

Das Projekt MyDriving Beispiele einige zusätzliche realen Build Definition. Für Xamarin.Android es verwendet die gleichen Schritte wie im vorherigen Beispiel beschrieben und fügt ein paar weiteren Token Update Versionsnamen und Zahlen, ersetzen cURL verwenden, um einen Keystore herunterladen und in Xamarin-Test-Cloud bereitstellen. Die universelle Windows-Plattform und iOS-Builddefinitionen sind ähnlich, nur mit etwas andere Schritte zur Verwaltung von Details wie Signaturzertifikate. Und für die Back-End-ASP.NET-Code MyDriving verfügt über eine einfache Definition NuGet-Wiederherstellung ausführen, rufen Sie MSBuild und die Elemente auf einem Server veröffentlichen. Sie finden eine detaillierte Aufschlüsselung der alle diese Builddefinitionen in Kapitel 10 "MyDriving Reference Guide" unter aka.ms/mydrivingdocs.

Bereitstellen eines Agents

Charakteristische jede Definition gehört die Liste der Allgemein Registerkarte die Suche nach "Anforderungen". Das Konzept der Anforderungen ist, wenn Sie versuchen, einen Build für einen Agent Warteschlange, die diese Anforderungen nicht erfüllt, Teamdienste Sie sofort ein Fehler statt versucht, einen Build hopeless und machen Sie über Fehler in der Buildausgabe aus zuweisen können. Folglich werden die Definition eines Xamarin.Android Anforderungen wie Xamarin.Android und Android-SDK aufgelistet. Eine Builddefinition für iOS, werden im Gegensatz dazu erfordert z. B. Xcode oder Xamarin.iOS aufgelistet.

Wie bereits erwähnt, sind gehosteten Agents in Team Services Windows-Computern, aber nur auf ein Mac kann die Anforderungen für iOS erfüllen. Wie, dann Sie einen Build-Agent auf einem solchen Computer ausgeführt? Eine Möglichkeit ist die Verwendung der Dienst wie MacinCloud, also im MyDriving verwendet wird. Es gibt ein hervorragender Beitrag im Blog des Visual Studio-ALM (bit.ly/2ajHtIz), die alle Details über die Einrichtung bereitstellt.

Die andere Option ist zur Installation eines Agents auf Ihren eigenen Mac Detaillierte Informationen befinden sich unter "Bereitstellen eines Agents auf OS X" (bit.ly/2azm136), aber ich möchte Ihnen einige dieser Erfahrung hier das humble 5 Jahre MacBook, die auf meinem Schreibtisch befinden. Auf diesem Computer ich die OS X-Agent heruntergeladen und die Konfiguration gestartet. Dies veranlasste mich, die mein Team Services-Konto, gefolgt von einem Zugriffstoken personal aus meinem Profil im Team-Portal-URL eingeben. Das Token ist wie der Agent auf dem Mac selbst identifiziert, ein Mac andernfalls mein Microsoft-Konto nicht bekannt ist.

Sobald mit Team Services verbunden sind, wurde ich für den Pool, dem den Agent hinzugefügt aufgefordert. Als Beispiel habe ich dem Agent Pool-Abschnitt im Team Services erstellten "lokale Mac" Siehe Abbildung 7. Kurz nach habe ich diesen Namen mit dem Agent auf dem Mac, wurde der Agent Team-Dienste angezeigt, wie in den Versatz dargestellt.

Abbildung 7 erstellen einen neuen Agent Pool und wie ein neuer Agent nach dem anschließen (abgesenkt) angezeigt wird

Mit dem Agent verbunden habe ich auf dem Mac, die ich kann interaktiv oder als Dienst ausführen. Seite "Bereitstellen eines Agents unter OS X" oben genannten beschreibt diese. Anschließend eine Xamarin.iOS-Builddefinition in Team Services erstellt und aktiviert Sie meinen Mac-basierten Agent-Warteschlange für den Build (ich auch ausgewählt haben dies im Allgemeinen die Builddefinition | Agent-Warteschlange Standardeinstellung). Schließlich kann ich in der Warteschlange eines Builds mit Team Services und – schon – ich finden Sie unter Meine MacBook ausführen sowie die Buildausgabe direkt im Team-Diensten, wie bei der gehosteten Agent.

Einige Tipps und Hinweise

• Denken Sie daran, dass die meisten Projekte einen Wiederherstellung Paketschritt früh in der Builddefinition, z. B. das NuGet-Installationsprogramm für Xamarin und .NET-Projekte und den Npm Schritt für Apache Cordova-Projekten benötigen. Buildfehler erinnert Sie diesen Umstand!
• Standardmäßig müssen jeden Schritt, die Sie, eine Builddefinition hinzufügen die Steueroptionen | Bei Fehler fortsetzen Sie, und führen Sie immer die Kontrollkästchen deaktiviert. Überprüfen die erste Möglichkeit, dass der Schritt nicht wirklich wichtig für die nachfolgenden Schritte, und sollte nicht den Build fehlschlagen. Die zweite bedeutet, dass der Schritt immer ausgeführt wird, unabhängig davon, was mit anderen Schritten geschieht. Beispielsweise müssen Sie möglicherweise einen Schritt am Ende der Definition kopieren beliebige Elemente erstellt wurden, auch wenn einige erstellt haben, oder müssen Sie möglicherweise eine spezielle Bereinigungsaufgabe, die immer ausgeführt werden soll.
• Wenn Sie Ihre eigenen Build-Agents verwalten, ist es Ihre Aufgabe, die Software auf dem neuesten Stand zu halten. Buildfehler erfahren Sie in der Regel, liegt ein Versionskonflikt an einer beliebigen Stelle.
• Denken Sie daran, überprüfen Sie die Optionen | Erstellen Sie Arbeitsaufgabe, in der Builddefinition zuweisen ein Fehlers Personen Code übergeben, die ein CI-Build ausgelöst, die nicht auf Fehler. Sie finden weitere Benachrichtigung - und e-Mail-bezogene Aufgaben auch auf dem Markt Teamdienste, mit dem den Prozess anzupassen, wenn Sie nicht ausschließlich auf Arbeitsaufgaben verwenden möchten.
• Haben Sie eine Idee für eine Erweiterung erstellen Ihre eigenen? Sehen Sie sich die Dokumentation unter bit.ly/2avgl97.

Blick in die Zukunft

Wie weiter oben in diesem Artikel erwähnt, ist Build, welche Transformationen Quellcode in die Elemente, die von den Rest der releasepipeline (auch wenn nur für Testzwecke) benötigt. Im nächste Artikel dieser Reihe werde die Release Management-Funktionen von Visual Studio Team Services ist zum Definieren und automatisieren möglicherweise zusätzliche Schritte, die zwischen eines Builds und Ihrer app und Dienstleistungen an Kunden stattfinden müssen. Praktischerweise Großteil zu Builddefinitionen erlernten auch Release-Definitionen, letztere auch mit diskreten Schritte konfiguriert werden. All dies führt Sie jemals eine vollständig automatisierte releasepipeline an.

---

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.

Unser Dank gilt der folgenden technischen Expertin für die Durchsicht dieses Artikels: Andy Lewis
Andy Lewis schreibt als leitender Entwickler bei Microsoft und Inhalt für Bereiche, die Visual Studio Team Services, TFS und Build enthalten. Er ist zum Erstellen von leistungsstarken befriedigend Benutzerfunktionalität in Web-apps durch den Entwurf von Inhalten integriert.