Kontinuierliche Builderstellung und Bereitstellung

Wenn viele Entwickler an komplexen Softwareprojekten zusammenarbeiten, kann das Integrieren unterschiedlicher Teile von Code ein langer und schwer einschätzbarer Prozess sein. Sie können jedoch die Effizienz und Zuverlässigkeit dieses Prozesses erhöhen, wenn Sie das Projekt fortlaufend erstellen und bereitstellen.

Fortlaufende Integration (CI) ist das Verfahren, den Code so häufig wie möglich in ein freigegebenes Repository zu integrieren. Während der Codeintegration kann Sie eine Buildunterbrechung oder ein Testfehler rechtzeitig über einen Fehler im Code informieren.

Martin Fowler verfügt über den folgenden Strukturplan von Methoden zur fortlaufenden Integration:

• Behalten Sie ein einzelnes Quellrepository bei.

• Automatisieren Sie den Build.

• Machen Sie den Build unabhängig.

• Checken Sie den Code mindestens einmal pro Tag ein.

• Jedes Einchecken sollte auf dem CI-Server basieren.

• Sorgen Sie für einen schnellen Build.

• Testen Sie in einem Klon der Produktionsumgebung.

• Vereinfachen Sie das Abrufen der neuesten EXE-Datei für alle Benutzer.

• Achten Sie immer darauf, was geschieht.

• Automatisieren Sie die Bereitstellung.

Weitere Informationen finden Sie auf der folgenden Seite von Martin Fowlers Website: Fortlaufende Integration.

Visual Studio Application Lifecycle Management (ALM) hilft Ihnen beim Verwalten des End-to-End-Prozesses der Softwareentwicklung und unterstützt die fortlaufende Integration. Durch Nutzung der Funktionen von Visual Studio ALM lassen sich unerwartete Verzögerungen, Kostenüberschreitungen und Ausführungsrisiken des Projekts vermeiden.

In diesem Thema

• Verwalten von Abhängigkeiten

• Fortlaufende Integration in Visual Studio 2010

• Erste Schritte

• Versionskontrolle

• Build

• Tests und Bereitstellung

• Projektintegration und Kommunikation

Verwalten von Abhängigkeiten

Aufgrund der Abhängigkeiten zwischen Code ist das Integrieren von Code ein komplexer Vorgang. Beispiel: Eine Bibliothek, die einen Kreis auf einem Bildschirm zeichnet, ist von der Sqrt()-Methode der mathematischen Bibliotheken des Systems abhängig. Wenn die Sqrt()-Methode geändert wird, müssen Sie die Bibliothek entsprechend aktualisieren. Hardware und Betriebssysteme werden viel seltener als das Teamprojekt geändert. Wenn jedoch Änderungen unter allen Umständen vermieden werden, kann dies zu katastrophalen Ergebnissen führen. Sie können den Code so früh wie möglich integrieren, um zu untersuchen, ob er auf gültigen Annahmen basiert und ob er wie geplant ausgeführt wird.

Änderungen in Code können sich auf Abhängigkeiten unterschiedlich auswirken. Die folgende Abbildung zeigt zwei Situationen. Im linken Beispiel wird eine relativ isolierte Änderung gezeigt. Im rechten Beispiel wird jedoch eine Änderung gezeigt, deren Auswirkungen potenziell größer sind, da die Änderung viele Abhängigkeiten aufweist.

Die folgende Abbildung zeigt, wie ständige Änderungen zusammengesetzte Auswirkungen haben können, wenn Sie den Code nicht fortlaufend integrieren und aktualisieren.

In Schritt 1 ändern Sie Codeblock h. Dies wirkt sich möglicherweise auf sämtliche abhängigen Codeblöcke a, b, d, e und f aus. In Schritt 2 ändern Sie die Codeblöcke a und b. Wenn das Team zwischen Schritt 1 und 2 keine Integration ausführt, sind Block a und b möglicherweise nicht mehr gültig. In Schritt 3 ändern Sie Codeblock f. Wenn das Team zwischen Schritt 2 und 3 keine Integration ausführt, wurde Codeblock b an diesem Punkt beeinflusst, geändert und erneut beeinflusst. Als Ergebnis kann es schwierig sein, Codeblock b zu korrigieren.

Fortlaufende Integration in Visual Studio 2010

Visual Studio ALM stellt integrierte Toolsets zur Unterstützung der fortlaufenden Integration bereit. Wie die folgende Abbildung zeigt, umfassen diese Tools Versionskontrolle, Erstellen, Testen, Bereitstellung in einer Lab-Umgebung, Arbeitsaufgabennachverfolgung und die Data Warehousing-Funktionalität.

Erstens können Sie mit Team Foundation-Versionskontrolle Verzweigungen, Changesets und die Integration zwischen ihnen verwalten. Jedes Teammitglied kann mithilfe von Arbeitsbereichen unabhängig arbeiten. Weitere Informationen finden Sie unter Verzweigen und Zusammenführen und Erstellen eines Arbeitsbereichs zum Arbeiten mit dem Teamprojekt.

Zweitens können Sie Team Foundation Build zum Kompilieren, Testen und Bereitstellen der Software in einem automatisierten und verteilten System verwenden. Wie die vorherige Abbildung zeigt, bietet Team Foundation Build zwei Arten von Builds. Bei der einen Art wird die Entwicklungsverzweigung mithilfe eines fortlaufenden Builds erstellt. Bei der anderen Art wird die Main-Verzweigung mithilfe des Buildtyps Abgegrenzter Eincheckvorgang erstellt. Visual Studio Team Foundation Server unterstützt fünf Typen von Builds: manuell, fortlaufend (durch Eincheckvorgänge ausgelöst), parallel (Eincheckvorgänge werden gesammelt, bis der vorherige Build abgeschlossen ist), abgegrenzter Eincheckvorgang und geplant. Weitere Informationen finden Sie unter Erstellen einer einfachen Builddefinition, Informationen zum Team Foundation-Buildsystem und Einchecken ausstehender Änderungen für einen abgegrenzten Eincheckbuild.

Drittens helfen die Lab-Management-Funktionen von Visual Studio ALM, Builds sowohl für physische als auch für virtuelle Lab-Umgebungen zu definieren und bereitzustellen. Um zur Laufzeit Integrationsfehler in einer bestimmten Umgebung abzufangen, können Sie einen Build in einer Lab-Umgebung bereitstellen und dann Testsammlungen für diesen Build ausführen. Weitere Informationen finden Sie unter Verwenden eines virtuellen Labs für den Anwendungslebenszyklus.

Außerdem sind auf den Computern der Teammitglieder, auf dem Buildcomputer und in der Lab-Umgebung Testfunktionen in Visual Studio ALM verfügbar. Erstens werden durch das Ausführen von Testsammlungen auf dem Computer des Entwicklers Probleme mit dem Code abgefangen, der vor kurzem geändert oder erstellt wurde. Zweitens werden durch das Ausführen von Tests auf dem Buildcomputer Probleme abgefangen, die mit der Integration in anderem Code zusammenhängen. Drittens werden durch das Ausführen von Tests im Lab Probleme abgefangen, die mit einer bestimmten Umgebung zusammenhängen, die das Team konfiguriert. Weitere Informationen finden Sie unter Gewusst wie: Konfigurieren und Ausführen von geplanten Tests nach dem Erstellen der Anwendung.

Viertens ist Visual Studio Team Foundation Server das Repository, in dem Arbeitsaufgaben gespeichert werden. Sie können Arbeitsaufgaben, z. B. Fehler oder Aufgaben, die den Teammitgliedern zugewiesen sind, erstellen, verwalten und nachverfolgen. Wenn ein Build während der Codeintegration unterbrochen wird, muss das Team so schnell wie möglich das Problem beheben. Sie können Team Foundation Server konfigurieren, um Arbeitsaufgaben für Buildunterbrechungen zu erstellen. Weitere Informationen finden Sie unter Nachverfolgen von Fehlern, Aufgaben und anderen Arbeitsaufgaben.

Schließlich werden in den Datenbanken des Warehouse für Team Foundation Server und SQL Server Analysis Services alle von Subsystemen in Team Foundation Server bereitgestellten Daten aggregiert und in Beziehung gesetzt. Diese Subsysteme umfassen Versionskontrolle, Build, Test, Bereitstellung und Arbeitsaufgabennachverfolgung. Daher kann das Team den End-to-End-Prozess der fortlaufenden Integration visuell darstellen. Weitere Informationen finden Sie unter Generieren von Berichten mit der relationalen Warehouse-Datenbank für Visual Studio ALM.

Erste Schritte

Das Team kann in der folgenden Reihenfolge mit der Verwendung von fortlaufender Integration und Team Foundation Server beginnen:

1. Verwenden Sie Team Foundation-Versionskontrolle, um Code in eine einzelne CodeBase zu integrieren.

2. Erstellen Sie in Team Foundation Build einen manuellen Buildtyp.

3. Führen Sie automatisierte Testfälle aus, um die Qualität des Builds zu überprüfen. Wenn Sie über keine entsprechende Testsammlung verfügen, erstellen Sie eine Platzhaltertestsammlung, und importieren Sie einige automatisierte Testfälle. Diese Sammlung kann als Platzhalter für zukünftige Tests dienen.

4. Stellen Sie sicher, dass Sie die entstandenen Binärdateien eines Builds an einen freigegebenen Speicherort übermitteln. Diese Strategie kann Sie bei der Diagnose von während der Tests auftretenden Problemen unterstützen

5. Verwenden Sie Microsoft Test Manager, um zur Laufzeit Integrationsfehler in einer bestimmten Umgebung abzufangen.

Versionskontrolle

Ein Versionskontrollsystem stellt ein freigegebenes Repository für den Code bereit. Ein kleines Team kann mit einer einzelnen Verzweigung arbeiten. Es ist jedoch zweckmäßiger, mit mehreren Verzweigungen zu arbeiten, da Sie in der Regel mehrere Versionen von Code entwickeln und das Projekt in verschiedenen Meilensteinen veröffentlichen müssen. Weitere Informationen zum Erstellen und Zusammenführen von Codeverzweigungen finden Sie auf der folgenden Seite der CodePlex-Website im Team Foundation Server-Verzweigungshandbuch 2.0.

Build

In der fortlaufenden Integration generiert ein Buildsystem die ausführbaren Komponenten, die getestet und bereitgestellt werden können. Ein Buildsystem stellt außerdem Feedback in Form von Kompilierungsfehlern und Warnungen bereit. Diese Fehler werden von Änderungen an der Projektquelle verursacht.

Team Foundation Build stellt die folgenden Buildtypen zur Verfügung:

• Manuell – Builds werden von Teammitgliedern in die Warteschlange gesetzt.

• Fortlaufend – Builds werden anhand eines Eincheckvorgangs in eine Versionskontrollenverzweigung in die Warteschlange gestellt.

• Rollen – Builds werden akkumuliert, bis der vorherige Build beendet ist.

• Abgegrenzter Eincheckvorgang – Eincheckvorgänge werden nur akzeptiert, wenn die gesendeten Änderungen erfolgreich zusammengeführt und erstellt werden.

• Geplant – Builds treten nach einem definierten Zeitplan auf.

Weitere Informationen finden Sie unter Erstellen einer einfachen Builddefinition.

Wie sind die Erwartungen von Teammitgliedern für eine erfolgreiche Implementierung einer fortlaufenden Integration?

Die Teammitglieder müssen ihre Quellen organisieren, damit die Erstellung nicht länger als 10 Minuten dauert. Für größere Projekte ist diese Frequenz eventuell nicht möglich. Mit Team Foundation Server kann das Team verschiedene Builddefinitionen konfigurieren, die unterschiedliche Teilmengen der CodeBase erstellen. Wenn Builds lange dauern, können Sie einen parallelen Buildtyp verwenden, um fortlaufend Binärdateien für den unveränderten Code zu generieren.

Bei Unterbrechungen eines Builds muss das Team den Build sofort korrigieren. Angenommen, die Hauptverzweigung ist von einer fehlerhaften Rückwärtsintegration nicht betroffen. Die meisten Buildunterbrechungen entstehen durch fehlerhaftes Einchecken bei der Arbeitsverzweigung oder durch eine Vorwärtsintegration von der Mainline-Verzweigung. Es empfiehlt sich, jeweils ein anderes Teammitglied abwechselnd mit dem Reparieren von Buildunterbrechungen für einen bestimmten Zeitraum zu beauftragen.

Wie viele Builds sollten pro Tag ausgeführt werden?

Wenn Sie den Code kontinuierlich integrieren, können Sie für jeden Eincheckvorgang in jeder Verzweigung einen fortlaufenden Build ausführen. Sie können auch einen parallelen Build ausführen, der von neuem eingechecktem Code unabhängig ist. Weitere Informationen finden Sie unter Erstellen einer einfachen Builddefinition und Überwachen des Status eines ausgeführten Builds.

Wie kann Code mit Team Foundation Server schneller erstellt werden?

Das Konfigurieren der Builddefinition zum Ausführen von inkrementellen Builds hilft bei der Steigerung der Geschwindigkeit des Builds. Sie können Buildprotokolle verwenden, um langsame Teile des Builds mit Verbesserungspotenzial zu erkennen. Weitere Informationen finden Sie unter Konfigurieren von Team Foundation Build für einen inkrementellen Build.

Wie kann Team Foundation-Build beim Skalieren der fortlaufenden Integration helfen?

Buildcontroller und Build-Agents können beim Skalieren des fortlaufenden Integrationszyklus helfen.

Weitere Informationen finden Sie unter Informationen zum Team Foundation-Buildsystem.

Tests und Bereitstellung

Wie passen Tests und Bereitstellung in die fortlaufende Integration?

Die folgende Abbildung zeigt, wie die Funktionen der Tests und Bereitstellung in Visual Studio ALM in die fortlaufende Integration integriert sind.

Erstens können Sie, wenn Sie den Code fortlaufend integrieren, Probleme mit dem Code anhand des Builds selbst ermitteln. Der Build war abhängig vom verwendeten Compiler entweder erfolgreich oder wurde nicht kompiliert. Sie können einen Buildbericht generieren, der Fehler- und Warnmeldungen vom Compiler enthält. In Visual Studio ALM enthält der Buildbericht auch beispielsweise Informationen zu den in diesem Build behobenen Fehlern, zu den in diesem Build enthaltenen Changesets und dazu, ob die Codeanalyse während des Builds ausgeführt wurde. Mit Visual Studio ALM können Sie überprüfen, ob der Entwurf des Codes den Regeln entspricht, die das Team definiert. Weitere Informationen finden Sie unter Gewusst wie: Überprüfen von .NET-Code anhand von Ebenendiagrammen.

Zweitens können Sie durch das Ausführen von Komponententests Probleme mit dem Code ermitteln. Mit diesen Tests werden Probleme auf andere Weise als mit Compilern diagnostiziert. Die Regeln für den Compiler überprüfen Probleme mit Codesyntax und Sprachkonstrukten. Im Gegensatz dazu können die Komponententests (die für einen Build ausgeführt werden, nachdem dieser abgeschlossen wurde) einen beliebigen Aspekt der Funktionen des Codes überprüfen. Diese Komponententests können auch Metrik für einen angegebenen Satz von Komponententests bereitstellen, z. B. Codeabdeckung in einem Build. Weitere Informationen finden Sie unter Gewusst wie: Konfigurieren von Codeabdeckung mithilfe von Testeinstellungen für automatisierte Tests.

Mit Microsoft Test Manager können Sie eine spezifische Umgebung konfigurieren, in der Sie Tests ausführen können. Isolierte Komponententests können eine funktionale Überprüfungsebene bereitstellen. Umgebungen weisen jedoch die folgenden wichtigen Aspekte auf:

• Das Variieren der Umgebungen kann die Funktionsweise des Codes beeinflussen. Beispiel: Netzwerkeinstellungen und -topologie können ohne Lab-Management-Umgebung nur schwierig getestet werden.

• Durch die Automatisierung der Codebereitstellung in einer bestimmten Umgebung kann das Team die Bereitstellungszeit verringern und die Anzahl der Bereitstellungsiterationen erhöhen.

Weitere Informationen finden Sie unter SO WIRD'S GEMACHT: Erstellen einer Umgebung von Virtual Machine-Vorlagen und Einrichten von Testcomputern zum Ausführen von Tests oder Sammeln von Daten.

Wie kann ich meine Testsammlungen organisieren, um die fortlaufende Integration zu ermöglichen?

Sie können die Testsammlungen ausführen, die für die fortlaufenden Builds am wichtigsten sind, da zu viele Tests den Abschluss des Builds verzögern können. Stellen Sie sicher, dass Sie diese Tests für die aktuelle Iteration ausführen.

Sie können auch in einem nächtlichen oder geplanten Buildzyklus Tests von vorherigen Builds und vollständige Testdurchläufe ausführen, die die Funktionalität in vorherigen Sprints überprüfen.

Wie wirkt sich fortlaufende Integration auf das Testteam aus?

Mithilfe der fortlaufenden Integration werden fehlerhafte Builds erkannt, sodass das Testteam keine Zeit mit der Arbeit an und Installation von fehlerhaften Builds verschwendet.

Projektintegration und Kommunikation

Der Aufwand für das Implementieren der fortlaufenden Integration kann je nach Größe des Projekts erheblich sein. Das Team muss im ersten Sprint des Projekts die Arbeit für die fortlaufende Integration definieren und planen.

Wenn Sie die fortlaufende Integration in Phasen anwenden möchten, können Sie zunächst den automatisierten Build implementieren. Dann können Sie ihn ändern, um das Ausführen von Komponententests einzuschließen. Schließlich können Sie einer Lab-Umgebung die Funktionen zum Bereitstellen des getesteten Builds hinzufügen und dann Tests in der Umgebung ausführen, um zu überprüfen, ob sich eine abweichende Umgebung auf den Code auswirkt.