---

September 2016

Band 31, Nummer 9

Dieser Artikel wurde maschinell übersetzt.

Mobile DevOps: Die Quelle der Wahrheit: Die Rolle von Repositorys in DevOps

Durch Kraig Brockschmidt | September 2016

Im ersten Artikel dieser Reihe "aus Code, um Kunden: Untersuchen Mobile DevOps"(msdn.com/magazine/mt767694), eingeführten des Microsoft-DevOps für mobile apps und Back-End-Dienste Stapeln. Es erläutert die Phasen der versionspipeline gesamte, siehe Abbildung 1. Eine versionspipeline, kurz, put ist wie Code, der ein Commit, um ein Quell-Repository ausgeführt wird umgewandelt können apps und Dienste abruft und an Kundengeräte und Kunden zugänglichen Server übermittelt. Eine versionspipeline im Kern ist eine Liste der Schritte, die erforderlich sind, zu einer Version auftreten. In der Tat beginnt die Praxis DevOps werden über die genauen Schritte und die Prozesse in einer Version. Von dort aus ist es relativ einfach, diese Prozesse mithilfe von Tools im Microsoft DevOps Stapel inkrementell zu automatisieren.

Abbildung 1 Quellcodeverwaltungsrepository ist die Eingabe für die Releasepipeline

Wie bereits im ersten Artikel erläutert wird, sollten Sie immer wie jeder Schritt in einer versionspipeline manuell verstehen. Viele app-Projekte erste Schritte mit der manuellen Prozesse, wie z. B. manuelle builds zum Feedback von Testern so früh wie möglich zu erhalten. Zu wissen, wie alles manuell bietet auch ein Fallback für den Fall, dass ein Teil einer automatisierten releasepipeline unterteilt.

Manuelle Prozesse sind jedoch teuer, skalieren, fehleranfällig, um menschliche Fehler häufig mühsam und gefährden jeder Schritt Wettbewerb um die Aufmerksamkeit der Mitarbeiter ihre anderen arbeiten. Automatisierung – ein Computer mit diesen Aufgaben – bietet wesentlich bessere Skalierung, Zuverlässigkeit, Vorhersagbarkeit und Überwachung, d. h. höheren Qualität zu geringeren Kosten. Automatisierung werden auch Ihre Mitarbeiter für Aufgaben, die Benutzereingriff wirklich benötigen.

In diesem Artikel werde ich einen äußerst wichtigen Aspekt der releasepipeline, die vermutlich bereits vergeben ist, für den gewährt: Datenquellen-Steuerelement. Quellcode des Projekts wird die Eingabe für die versionspipeline gemäß Abbildung 1, und akzeptieren Sie die meisten Entwickler heute Verwalten von Code in einem Quellcodeverwaltungssystem wie selbstverständlich. Aber sie hilft bei der die gesamte DevOps besser zu verstehen, wenn Sie sehen, dass in diesem Kontext das Quellsteuerelement wichtige Rolle spielt.

Die Gründe für die Datenquellen-Steuerelement

Der erste Schritt bei der Automatisierung einer versionspipeline ist zum Verwalten von Codes in einem Quellcodeverwaltungsrepository irgendeiner Art. Erneut der Quellcode ist die Eingabe für die releasepipeline, und die nächste Stufe, Build, ist was diesen Code in die Elemente konvertiert, die dann in den Rest der Pipeline integriert werden. Des Buildprozesses mit kontinuierlicher Integration besonders zu automatisieren, müssen Systeme wie Visual Studio Team Services (Team Services kurz) in der Lage zu erkennen, wenn das Repository geändert wird. Daher reicht es nicht aus Ihrem Quellcode lediglich in einigen beliebigen Ordner auf der Festplatte verwalten.

Hinweis: Wenn Sie bereits über ein kostenloses Team Services-Konto haben, erstellen Sie anhand der Instruktionen unter bit.ly/29xK3Oo. Noch besser, besuchen Sie das Visual Studio Developer-Essentials-Programm (bit.ly/29xKCYq), ermöglicht Sie ein Team Services-Konto zusammen mit einfachen Zugriff auf viele andere Dienste, einschließlich $25 in Azure-Gutschrift für 12 Monate.

Informationen zu Builds und fortlaufende Integration in den nächsten Artikel dieser Reihe werde ich. Hier möchte ich den Schwerpunkt insbesondere auf Datenquellen-Steuerelement selbst, beginnend mit einer kurzen Übersicht über Datenquellen-Steuerelement Warum überhaupt vorhanden ist und die allgemeine Rolle, die sie in der DevOps als Ganzes spielt. Mein Grund dafür ist auf etwas hin, die Sie niemals über vor gekommen wäre: Datenquellen-Steuerelement ist im Grunde eine Form der Automatisierung.

Diese Anweisung kann überraschend, da die meisten Entwickler heute Quellsteuerelement Betrachten einer bestimmten. Aber das war nicht immer der Fall. Wahrscheinlich sind Sie besonders, wenn Sie zuerst die ersten Schritte wurden Ihre berufliche Laufbahn für Projekte ohne Datenquellen-Steuerelement zu einem bestimmten Zeitpunkt gearbeitet haben. In diesen Projekten mussten Sie wahrscheinlich nur einen Ordner auf der lokalen Festplatte, die mit allen Codes, was ist das Ergebnis bei der Erstellung eines neuen lokalen app-Projekts in Visual Studio. Dort Sie haben einen lokalen Build zum Erzeugen von ausführbaren Dateien ausgeführt und z. B. für Verteilung, die Sie manuell auf einen öffentlichen Webserver hochgeladen oder vielleicht auf physischen Medien für andere Personen freigegeben.

Datenquellen-Steuerelement ist in keiner Weise zum Erzeugen einer Kunden-Apps und ihre Back-End-Dienste erforderlich sind. Jedoch müssen nur eine einzige lokale Kopie des Quellcodes verfügt über eine Reihe von Problemen und Risiken, die ich vorstellen, dass Sie direkt zu kämpfen haben:

• Wenn die Festplatte ausfällt, können Sie alles verloren gehen.
• Eine einzelne Kopie des Quellcodes verwalten nicht Änderungsprotokolls machen es sehr schwierig, die auf einen vorherigen Arbeitsstatus des Projekts zurücksetzen.
• Arbeiten mehrere Personen an der Code können problemlos Überschreiben des jeweils anderen Änderungen oder einführen, Änderungen, ohne alle Benutzer kennen.

Es ist sicherlich möglich, diese Risiken manuell zu einem gewissen Grad. Regelmäßige Backups können z. B. vor dem Verlust von Code zu schützen, und geben Sie einen bestimmten Grad an Verlauf. Allerdings erschwert die nongranular Art des gesamten Projekt Sicherungen nur Teile des Projekts zurückgesetzt werden, während andere Änderungen erhalten bleibt. Es ist auch möglich, für Personen in einem Team persönliche Kopien des Codes zur Vermeidung von Konflikten, aber dann ist es außergewöhnlich mühsam, um diese Kopien zusammen in einen funktionsfähigen Zustand zu integrieren. Teammitglieder können auch Änderungen an andere direkte E-mail oder andere messaging kommunizieren, aber dies wird auf annähern lästig.

Natürlich vermeiden Sie als Entwickler wir in der Regel eine solche Verantwortung so oft wie möglich. In diesem Fall finden wir kreative zum Automatisieren dieser Aufgaben, die genau auf welche Datenquellen-Steuerelement ist geht.

Auf einer hohen Ebene bedeutet Quellsteuerelement Folgendes:

• Warten ein freigegebenes Repository des gesamten Projekts Codes auf einem Server mit einer automatischen Sicherungsmechanismus.
• Protokollierung von Änderungen auf der Grundlage einer pro Datei den gesamten Verlauf für eine Datei zu sehen, sowie Änderungen an mehreren Dateien, die in das Repository als Gruppe übernommen wurden. Dies erleichtert die Buildfehler zu verknüpfen und Regressionen mit bestimmten Änderungen testen und einzelne Dateien oder Dateigruppen auf vorherige Zustände, nicht nur den Status der letzten Sicherung wiederherstellen.
• Speichern den Code an einem Ort, in dem ein Buildsystem Änderungen im Repository erkennen und automatisch auslösen ein Builds, d. h. einen unmittelbaren Integrationstest (continuous Integration) mit diesen Änderungen durchführen kann.
• Verwalten von überschreibt und Konflikte zwischen mehreren Benutzern Entwickler Dateien exklusiv sperren, während sie sie bearbeiten, oder über die Tools, mit die automatisch Änderungen zusammenführen und Konflikte erkennen können.
• Automatische Benachrichtigungen senden interessierten Entwicklern, wenn bestimmte Dateien ändern oder Wenn Zusammenführungskonflikte manuellen Lösung benötigen.

Kurz gesagt, automatisiert die Datenquellen-Steuerelement viele mühsam Prozesse in ein Repository verlässlich und überprüfbaren Code eines Projekts verwalten. Es ist wichtig für die Verwaltung von Projektcode für einzelne Entwickler und Teams gleichermaßen und bildet die Grundlage für eine automatisierte releasepipeline.

Quellcodeverwaltungsoptionen

Erhalten umfassende müssen Datenquellen-Steuerelement, ist es keine Überraschung, dass die vielen verschiedenen Systemen im Laufe der Jahre entwickelt haben. Hier werden jedoch die beiden erläutert, die Sie direkt im Team Services hosten können: Git und Team Foundation Version Control (TFVC). Mit einem Repository bedeutet, dass es direkt in Ihrem Team Services-Konto verwaltet und gespeichert. Das Buildsystem Teamdienste kann auch von externen Git, GitHub und Subversion-Repositorys, auch zeichnen, die ich im nächsten Artikel in der Reihe zu sprechen.

Der Quellcode-Verwaltungssystem, das Sie für ein Projekt auswählen ist wirklich eine Frage der Einstellung, die Erfahrung von Ihrem Team und die Kosten Aspekte der Entwicklung. GitHub, z. B. für Öffentliche Repositorys ist kostenlos, aber hat jedoch auch Nachteile für privaten (finden Sie unter github.com/pricing). Öffentliche GitHub-Repositorys werden offene standardmäßig also Warum öffnen Source-Projekte in der Regel auf GitHub gehostet werden. Viele der ich bei Microsoft, z. B. arbeite Dokumentationen gespeichert, einschließlich der gesamten Auflistung der Dokumentation zum Microsoft Azure (github.com/Azure/azure-content), und die Dokumentation für Visual Studio-Tools für Apache Cordova (github.com/Microsoft/cordova-docs). Ich verwende auch GitHub für eine Vielzahl von einzelnen Beispielprojekte, wie im Beispiel Altostratus (github.com/kraigb/Altostratus), die im MSDN Magazin letztes Jahr erschien (bit.ly/29mKHiC). Auf ähnliche Weise GitHub für das MyDriving-Projekt auswählen (github.com/Azure-Samples/MyDriving), da es beabsichtigt war von Anfang open-Source. (Weitere Informationen zu allgemeinen MyDriving, finden Sie unter aka.ms/iotsampleapp.)

Team Services auf der anderen Seite wird standardmäßig, was bedeutet, dass bei der Erstellung von einem Repository nur Sie Zugriff auf private Repositorys (Git oder TFVC) ausgerichtet. Um auf andere Benutzer zugreifen können, müssen Sie explizit hinzufügen als Team-Mitglieder (finden Sie unter bit.ly/29QDHql). Der Vorteil ist, dass Sie unbeschränkte private Repositorys in Ihrem Team Services-Konto kostenlos für beliebig viele MSDN-Abonnenten, und Kosten nur erfolgen, wenn mehr als fünf Benutzer ohne MSDN-Abonnements, hosten können. Aus diesen Gründen ich Team Services für persönliche Projekte verwenden, z. B. apps habe ich in app-Stores, und für Code, den ich an nur bestimmten Personen freigeben möchten.

Der Hauptunterschied zwischen Git- und TFVC funktionale liegt in ihren jeweiligen Source Control-Modellen. Ein vollständiger Vergleich finden Sie in der Dokumentation unter dem Thema "Auswahl der richtigen Versionskontrolle für das Projekt" (bit.ly/29oZKTZ), aber ich möchte die zusammenfassen.

TFVC, siehe Abbildung 2, an einem zentralen, was bedeutet, dass die Dateien in einem einzelnen, zentralen, schreibgeschützten Repository live für die der Administrator verantwortlich für die Sicherung ist. Um mit TFVC funktionieren, verwalten Sie in der Regel eine schreibgeschützte Kopie der neuesten Version von Dateien aus dem Repository (einen Arbeitsbereich bezeichnet), über dem Sie Builds ausführen und Testen der app. Stellen Sie checken eine, oder weitere Dateien, die exklusiven Zugriff zu erhalten, bis die Dateien überprüft werden zurück (die in das Repository integriert ist,). TFVC führt dann die Änderungen in das Repository. Wenn mehrere Entwickler dieselbe Datei gleichzeitig auschecken (Dies ist zulässig), TFVC erkennt Konflikte beim Zusammenführen beim Einchecken, und informiert den Entwickler ggf. manuell auflösen.

Abbildung 2: die grundlegende Team Foundation Version Control-Beziehungen

Git verteilt, was bedeutet, dass zwar das master-Repository auf dem Host befindet, Sie das gesamte Repository (Änderungsverlauf und alle) "Klonen", Ihre Arbeit lokal und abgeschlossene Änderungen anschließend in den Klon zu übernehmen, wie in dargestellt Abbildung 3 (Siehe auch Git-scm.com für Informationen zu Git Workflows). Wenn können Sie die Änderungen mit jeder anderen Arbeitsaufgaben zu integrieren, senden Sie "Pull-Anforderungen" aus der Klon in die Master. In diesem Modell ist jeder Klon effektiv eine Sicherung des Repositorys.

Abbildung 3: die grundlegende Git Beziehungen

Beachten Sie, dass einige ähnliche Wörter wie "Auschecken" völlig unterschiedliche Prozessen, beschreiben, was verwirrend sein Git- und TFVC. Es empfiehlt sich einfach mit jeweils selbst arbeiten und nicht erwarten, dass keine Kenntnisse der beiden zu übertragen.

Git Pull-Anforderung Mechanismus lässt sich erkennen, wenn Änderungen automatisch zusammengeführt werden können und manuelle Behebung erforderlich ist. Natürlich im öffentlichen wie GitHub-Repositorys möchten Sie nicht unbedingt und jedermann Pull-Anforderungen zusammenführen können. In der Regel müssen nur bestimmte Personen Berechtigung zum Zusammenführen von Pull-Anforderungen, die dann als der Gatekeeper für die Integrität des Repositorys als Ganzes fungieren.

Beispielsweise sehen Sie am oberen Rand der MyDriving Repository unter github.com/Azure-Samples/MyDriving sehen Sie Pull-Anforderungen (finden Sie unter Abbildung 4). Klicken auf, zeigt derzeit Anfragen öffnen, die von Entwicklern mit Merge-Berechtigungen für die Moderation warten. Sie können auch den gesamten Verlauf der Pull-Anforderungen anzeigen geschlossenen Registerkarte in der Liste auf.

Abbildung 4 Pull-Anforderungen Liste auf GitHub für das MyDriving-Projekt

TFVC und Git Unterstützung Verzweigen sogenannten, was im Grunde bedeutet eine andere Ebene zwischen der Master- oder zentrale Repository und anderen Klone oder Kopien erstellen. Dadurch Untergruppen der Entwickler (und Tester) wichtige Aufgaben in dieser Verzweigung ohne Auswirkung auf die master-Repository. Eine Verzweigung auch verwaltet einen eigenen Änderungsverlauf und, im Fall von Git verwaltet einen eigenen Pull-Anforderungen aus jedem Klon. Nur, wenn das Team die Arbeit in der Verzweigung mit dem Master integrieren kann sie eine Pull-Anforderung in die Master übermitteln. Weitere Informationen erhalten finden Sie unter "Verwendung Verzweigungen zum Isolieren von Risiken in TFVC" (bit.ly/29ndlQz) und "Erstellen von Arbeit in den Verzweigungen" (bit.ly/29VVmgY) in der Dokumentation.

Kommunikation und Überwachung

In Git- und TFVC – und in der Quelle in der Regel Systeme steuern – Eincheckvorgängen pull-Anforderungen usw. verfügen alle über einen zugeordneten Kommentare dar. Das ist wie die Änderungen kommunizieren Sie haben versucht, alle anderen arbeiten auf das Projekt, und wie diese Änderungen zu Teams erörtern können. Diese Systeme in der Regel auch bereitstellen, Benachrichtigungen und Diskussionen zu größeren Problemen (z. B. offenen Bugs), Arbeitsaufgaben und so weiter.

Auf GitHub z. B. Sie kommentieren jedes Commit Code an Ihren Klon und nehmen Sie dann zusätzliche Kommentare aus, wenn Sie eine Pull-Anforderung zu übermitteln. Verantwortlich für das Überprüfen und Zusammenführen von dieser Anforderung können Kommentare oder Fragen innerhalb der pullanforderung, dann lassen, insbesondere dann, wenn sie potenzielle Probleme mit dem neuen Code finden. Sie können zahlreiche Beispiele finden Sie in der Liste der geschlossenen Pull im zuvor erwähnten MyDriving Repository um klicken. Klicken Sie entsprechend auf der Registerkarte Probleme auf der Startseite weitere Diskussionen nicht angezeigt. Für Benachrichtigungen werden diese über Ihre persönlichen Einstellungen im Abschnitt zu den verwaltet.

Team-Services für ihren Bereich verfügt über ein gesamtes System zum Nachverfolgen von Arbeitsaufgaben, Fehler usw., die Sie im Abschnitt Agile-Tools-Team Services-Dokumentation zu lesen können (bit.ly/29tvKIE). In einem coderepository (ob Git oder TFVC), es ist weit verbreitete Kommentare, siehe Abbildung 5, mit der Teammitglieder Notizen für Changesets (Gruppen von Änderungen), einzelne Dateien usw. zu belassen.

Abbildung 5 die Benutzeroberfläche für ein Changeset im Visual Studio-Team-Dienste, die Kommentare-Schaltfläche

Diese Kommentare, zusammen mit Einzelheiten, welche Änderungen, auf welche Dateien vorgenommen wurden alle wechseln Sie in das Repository Verlauf oder Änderungsprotokoll. Eine umfangreiche, ausführliche Historie, wer zu welchem Zeitpunkt Änderungen vorgenommen, zusammen mit jeder Diskussion, die diese Änderungen aufgetreten sind, ist einer der wichtigsten Vorteile der Verwendung eines Quellcodeverwaltungssystems. Der Verlauf wird das gesamte Repository über einen Zeitraum überwacht. Wenn unerwartete Probleme später in der releasepipeline, z. B. Regressionen, die über Einheit, Integration oder UI-Tests einfallen, vor allem ist es einfach zurückgehen und die spezifischen Änderungen in einer bestimmten Datei, die diese Regression verursacht hat.

Dabei, dass der Prozess "einfach" tatsächlich sehr wichtig ist, in denen DevOps als Ganzes betroffen ist. Erinnern Sie sich an den ersten Artikel dieser Reihe, die ich als die kontinuierliche Überprüfung der Leistung für eine Anwendung und Dienste "Leistung" die Kundenzufriedenheit und die Produktionskosten umfassen DevOps gesprochen. Die Suche nach Fehlern so früh wie möglich in der Pipeline unterstützt Version, um Kosten zu minimieren. Ebenso wichtig ist die Zeit an, wo genau zu lokalisieren, tatsächlich ein Fehler vorhanden ist, desto schneller besser! Tatsächlich haben Sie wahrscheinlich schon passiert verbringen viele frustrierend Tage Versuch zum Auffinden eines Fehlers in einigen Projekt, und feststellen, dass das Update alle 10 Sekunden gedauert hat. Fast alle Kosten stammt, in diesem Fall lediglich ermittelt die Ursache.

Dies ist ein sehr wichtiger Aspekt, wenn Sie oder andere Personen in Ihrem Team Objekte mithilfe von Datenquellen-Steuerelement, sondern nur "improvisiert" durch Ihren Code auf einige einfache Netzwerkfreigabe behalten. Die wenig Investitionen, die Sie vornehmen, durch die Einführung von einem Quellcodeverwaltungssystem zahlt sich aus über die Lebensdauer des Projekts, insbesondere, wenn mit automatisierten Builds, kontinuierliche Integration zusammen und Tests automatisierte in zukünftigen Artikeln sehen. Fortlaufende Integration bedeutet, dass jede codeänderung einen automatischen Build löst und automatisierte Tests ausgeführt wird, wenn diese Änderung des Codes führt dazu, dass jede Art von Fehler (Build oder Test), Sie also darüber innerhalb von Minuten.

Teamprojekte und mehrere Repositorys

Um eine automatisierte releasepipeline für Ihre app und die Dienste in Team Services oder Team Foundation Server (TFS) zu erstellen, beginnen Sie mit ein Teamprojekts sogenannten. Ein Teamprojekt ist der Container für alles, was Sie im Team-Dienste, einschließlich Planung, Zusammenarbeit über Teamräume, Nachverfolgen von Arbeitsaufgaben erstellt, kontinuierliche Integration, Verwaltung von Tests, Release Management und quellcodeverwaltungsrepositorys. Hier gebe ich "Repositories", da ein Teamprojekt kann direkt mehrere Repositorys, und das Buildsystem Teamdienste kann auch von externen Git, GitHub und Subversion Repositories zeichnen. (Auf ähnliche Weise können TFS aus einem Repository in Team Services und umgekehrt gehosteten zeichnen.)

Beachten Sie, dass ein Teamprojekt nicht mit Visual Studio-Projekts oder einer Projektmappe verwechselt werden sollte. Sie können beliebig viele Visual Studio-Projektmappen haben – zusammen mit anderen Code von einem beliebigen anderen Development System – alle innerhalb des gleichen Teamprojekts. Aus diesem Grund ich ein Teamprojekt als Feld Schatz DevOps vorstellen möchte – dies hilft mir, Verwechslungen zwischen Begriffen zu vermeiden und erinnert mich an alle DevOps-Funktionen, die sie verwalten kann.

Um ein Teamprojekt zu erstellen, melden Sie sich das Team Services-Portal, und klicken Sie auf neu, klicken Sie unter zuletzt geöffnete Projekte und Teams. Der neue Befehl öffnet ein Dialogfeld, in dem Sie entweder Git oder TFVC als das quellcodeverwaltungmodell für Standard-Repository für das Projekt auswählen. Dies wird nur ergänzend bereitgestellt. Bei Auswahl von TFVC können Sie Git-Repositorys später erstellen, wie Sie gleich sehen werden. Wenn Sie Git auswählen, können Sie ein TFVC-Repository sowie weitere Git-Repositorys später hinzufügen. Und wenn Sie verwenden eines externen Hosts wie GitHub lieber, Sie nicht das Standard-Repository überhaupt verwendet und diese Option ist nicht relevant. Wenn ich Einrichten eines Teamprojekts für MyDriving, wählte ich Git für das Standard-Repository, ist es ist z. B. eine Standardinfodatei Datei, da das real-Projekt vollständig auf GitHub gehostet wird.

Um anzuzeigen, wie ein einzelnes Teamprojekt mehrere Repositorys verwalten kann, erstellt habe ich ein Beispielprojekt in meinen eigenen Team Services-Konto und den ausgewählten TFVC. Registerkarte "Code" des Projekts anfänglich angezeigt wird, siehe Abbildung 6. Durch Klicken auf das Steuerelement anzuwenden, zeigt die Liste der vorhandenen Repositorys im Teamprojekt, zusammen mit den neuen Repositorys und Repositorys-Befehle verwalten. Der neue Befehl öffnet ein Dialogfeld, in dem Sie erneut zwischen Git- und TFVC auswählen. Da ich zunächst dem Teamprojekt den Projektplan mit TFVC erstellt, keine anderes TFVC-Repository erstellen (nur eine zulässig ist), aber ich kann eine beliebige Anzahl zusätzlicher Git-Repositorys erstellen, siehe Abbildung 7.

Abbildung 6: Registerkarte "Code" für ein neues Projekt mithilfe von Team Foundation-Versionskontrolle

Abbildung 7: eine Team Project mit mehreren Git-Repositorys und Repository der Versionskontrolle von Team Foundation

Der Befehl "Repositories verwalten" gelangen Sie mit der Systemsteuerungsoption Team Services, in dem Sie sehen alle Repositories (und Git verzweigt) auf einmal Umbenennen oder löschen. und Verwalten von Berechtigungen. Alle Details zu Benutzern, Gruppen und Berechtigungen – zu viele zu sagen – finden Sie in der Dokumentation "Berechtigungen und Gruppen in Team Services" (bit.ly/29nxvpd) in die "Git-Repository" und "TFVC"-Abschnitte. Sie können genügt es, dass eine äußerst präzise Kontrolle über Berechtigungen für jedes Ihrer Teammitglieder ausführen. Wenn Sie eine externe Quellcodeverwaltungssystem wie GitHub verwenden, werden Sie Berechtigungen auf der Website natürlich stattdessen verwalten. Beachten Sie jedoch, dass Berechtigungen für das Team als Ganzes Projekt – und nicht den Repositories – über die Registerkarte "Sicherheit" in dieser Benutzeroberfläche dargestellt verwaltet werden. Sie finden diese Details aus, wie bereits weiter oben auf der gleichen Seite zu Dokumentation (bit.ly/29nxvpd).

Auffüllen von einem Team Services-Repository mit Code

Nachdem Sie ein Repository erstellt haben, ist die große Frage, wie Sie Ihren Code in diese erhalten. Team Services bietet Ihnen eine Vielzahl von bedeutet, wie Visual Studio, um dieses Artikels schließen mich kurz über diese Optionen ausführen kann.

Für eine TVFC-Repository, können Sie das Hochladen von Dateien in das Repository, oder erstellen Sie neue Dateien direkt über das Portal Team. Navigieren Sie zunächst auf die Registerkarte Code im Teamprojekt, und klicken Sie auf die neben dem Repository... und wählen Sie + Dateien, hinzufügen, wie in dargestellt Abbildung 8. Daraufhin wird ein Dialogfeld (nicht gezeigt) durch die Dateien erstellen und direkt im Portal zu bearbeiten oder erstellen eine Liste der hochzuladenden Dateien. In diesem Fall können Sie auch einen Kommentar einchecken.

Abbildung 8 Visual Studio-Team-Services-Befehl, um ein Team Foundation Version Control-Repository Dateien hinzuzufügen

Die andere Möglichkeit, Code zu einem TFVC-Repository hinzufügen, wird über den Projektmappen-Explorer von Visual Studio. Dies ist eine äußerst angenehme Methode für eine lokale Lösung und der gesamte Code in Datenquellen-Steuerelement. Nur mit der rechten Maustaste in der Projektmappe, und wählen Sie Projektmappe zur Versionskontrolle, hinzufügen, wie in dargestellt Abbildung 9. Hierdurch wird ein Dialogfeld angezeigt, in dem Sie das gewünschte Teamprojekt in Ihrem Team Services-Konto oder auf einem bestimmten TFS-Computer auswählen können. Um zu einem Server herzustellen, der Sie möglicherweise zunächst durchführen müssen, verwenden Sie Team Explorer in Visual Studio (die Registerkarte am unteren Rand beschriebenen Abbildung 9). Details finden Sie unter "Arbeiten in Team Explorer" in der Visual Studio-Dokumentation (bit.ly/29oGp5j).

Abbildung 9: Hinzufügen einer Projektmappe zur Versionskontrolle in Visual Studio

Für Git-Repositorys fordert Teamdienste automatisch Sie mit einer Vielzahl von Optionen beim Erstellen des Repositorys oder navigieren sie auf der Registerkarte Code eine Benutzeroberfläche, die ausreichend für sich selbst spricht. Alternativ können Sie ein lokales Git-Repository in Visual Studio erstellen und dann in ein Repository in Team Services zu veröffentlichen. Ich durch diesen Prozess im Detail, Gehe nicht, da es gut, unter dem Thema "Freigabe Ihren Code mit Git und Visual Studio dokumentiert ist" (bit.ly/29VDYJg). Das kurze, jedoch wird auf die Schaltfläche "Veröffentlichen" auf der unteren rechten Ecke der Statusleiste von Visual Studio klicken, wodurch die Registerkarte "Veröffentlichen" in Team Explorer angezeigt werden, siehe Abbildung 10. Hier können Sie das zu verwendende Team Services-Konto auswählen. Ein wichtiges Detail ist Klicken auf die kleine erweiterte Text wie gezeigt ein Teamprojekt auswählen. Wie Sie auch sehen, bietet die gleiche UI Ihnen einen einfache Pfad zum Veröffentlichen von Code auf GitHub und andere externe Repositorys, auch.

Abbildung 10 die Benutzeroberfläche in Visual Studio veröffentlichen

Blick in die Zukunft

Mit einem Quellcodeverwaltungsrepository vorhanden nun Sie können den nächsten Schritt in die Automatisierung der releasepipeline durch Einrichten von Builds und fortlaufende Integration. Das ist, was ich in meinem nächsten Artikel eingehen werde, in dem Sie sehen werden, wie alle angegebenen Builddefinition in Visual Studio Team Services aus der quellcodeverwaltungsrepositorys, die hier vorgestellten zeichnen kann. Ein Teamprojekt kann darüber hinaus eine beliebige Anzahl von solchen Builddefinitionen verwalten, dies bedeutet, dass das Teamprojekt koordinieren kann aus einer beliebigen Anzahl von Repositorys wie werden die erforderlichen Artefakte für den Rest der releasepipeline oder Pipelines erzeugt erstellt.

---

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 den folgenden technischen Experten für die Durchsicht dieses Artikels: Donovan Brown und Gordon Hogenson