Kontinuierliche Integration - Kurzanleitung

Die kontinuierliche Integration wurde erstmals im Jahr 2000 mit der Software bekannt Cruise Control. Im Laufe der Jahre hat sich die kontinuierliche Integration zu einer Schlüsselpraxis in jeder Softwareorganisation entwickelt. Hierbei handelt es sich um eine Entwicklungspraxis, bei der Entwicklungsteams aufgefordert werden, sicherzustellen, dass für jede an einem Softwareprogramm vorgenommene Codeänderung ein Build und anschließende Tests durchgeführt werden. Dieses Konzept sollte das Problem beseitigen, spät auftretende Probleme im Build-Lebenszyklus zu finden. Anstatt dass die Entwickler isoliert arbeiten und nicht genug integrieren, wurde die kontinuierliche Integration eingeführt, um sicherzustellen, dass die Codeänderungen und -erstellungen niemals isoliert durchgeführt wurden.

Warum kontinuierliche Integration?

Die kontinuierliche Integration ist zu einem integralen Bestandteil jedes Softwareentwicklungsprozesses geworden. Der kontinuierliche Integrationsprozess hilft bei der Beantwortung der folgenden Fragen an das Softwareentwicklungsteam.

• Arbeiten alle Softwarekomponenten so zusammen, wie sie sollten? - Manchmal können Systeme so komplex werden, dass für jede Komponente mehrere Schnittstellen vorhanden sind. In solchen Fällen ist es immer wichtig sicherzustellen, dass alle Softwarekomponenten nahtlos miteinander arbeiten.

• Ist der Code für Integrationszwecke zu komplex? - Wenn der kontinuierliche Integrationsprozess weiterhin fehlschlägt, besteht die Möglichkeit, dass der Code einfach zu komplex ist. Und dies könnte ein Signal sein, geeignete Entwurfsmuster anzuwenden, um den Code weniger komplex und wartbarer zu machen.

• Entspricht der Code den festgelegten Codierungsstandards? - In den meisten Testfällen wird immer überprüft, ob der Code den richtigen Codierungsstandards entspricht. Wenn Sie nach dem automatisierten Build einen automatisierten Test durchführen, ist dies ein guter Punkt, um zu überprüfen, ob der Code alle gewünschten Codierungsstandards erfüllt.

• Wie viel Code wird von automatisierten Tests abgedeckt? - Es macht keinen Sinn, Code zu testen, wenn die Testfälle nicht die erforderliche Funktionalität des Codes abdecken. Es ist daher immer eine gute Praxis, sicherzustellen, dass die geschriebenen Testfälle alle Schlüsselszenarien der Anwendung abdecken.

• Waren alle Tests nach der letzten Änderung erfolgreich? - Wenn ein Test fehlschlägt, macht es keinen Sinn, mit der Bereitstellung des Codes fortzufahren. Daher ist dies ein guter Punkt, um zu überprüfen, ob der Code bereit ist, in die Bereitstellungsphase zu wechseln oder nicht.

Arbeitsablauf

Das folgende Bild zeigt einen schnellen Workflow, wie der gesamte Continuous Integration-Workflow in einem Softwareentwicklungsprojekt funktioniert. Wir werden uns dies in den folgenden Kapiteln genauer ansehen.

Basierend auf dem obigen Workflow funktioniert der kontinuierliche Integrationsprozess im Allgemeinen so.

• Zunächst schreibt ein Entwickler den Code in das Versionskontroll-Repository. In der Zwischenzeit fragt der Continuous Integration-Server auf dem Integrations-Build-Computer das Quellcode-Repository nach Änderungen ab (z. B. alle paar Minuten).

• Kurz nach einem Commit erkennt der Continuous Integration-Server, dass Änderungen im Versionskontroll-Repository aufgetreten sind. Daher ruft der Continuous Integration-Server die neueste Kopie des Codes aus dem Repository ab und führt dann ein Build-Skript aus, das die Software integriert

• Der Continuous Integration-Server generiert Feedback, indem er Build-Ergebnisse per E-Mail an die angegebenen Projektmitglieder sendet.

• Unit-Tests werden dann durchgeführt, wenn der Build dieses Projekts erfolgreich ist. Wenn die Tests erfolgreich sind, kann der Code entweder auf dem Staging- oder dem Produktionsserver bereitgestellt werden.

• Der Continuous Integration-Server fragt weiterhin nach Änderungen im Versionskontroll-Repository und der gesamte Prozess wird wiederholt.

Der Softwareteil ist der wichtigste Aspekt eines kontinuierlichen Integrationsprozesses. Dieses Kapitel konzentriert sich auf die Software, die für den gesamten kontinuierlichen Integrationsprozess benötigt wird.

Quellcode-Repository

Das Quellcode-Repository wird verwendet, um den gesamten Quellcode und alle daran vorgenommenen Änderungen zu verwalten. Die beiden beliebtesten für die Verwaltung von Quellcode-Repositorys sind Subversion und Git, wobei Git das neueste beliebte System ist. Wir werden uns nun ansehen, wie Git auf dem System installiert wird.

System Anforderungen

Erinnerung	2 GB RAM (empfohlen)
Festplattenplatz	200 MB Festplatte für die Installation. Zum Speichern des Projektquellcodes ist zusätzlicher Speicher erforderlich. Dies hängt vom hinzugefügten Quellcode ab.
Betriebssystemversion	Kann unter Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS und Mac OS X installiert werden.

Git installieren

Step 1 - Die offizielle Website für Git ist https://git-scm.com/. Wenn Sie auf den Link klicken, gelangen Sie zur Startseite der offiziellen Git-Website (siehe folgenden Screenshot).

Step 2 - Um Git herunterzuladen, scrollen Sie einfach auf dem Bildschirm nach unten, gehen Sie zum Abschnitt Downloads und klicken Sie auf Downloads.

Step 3 - Klicken Sie auf den Windows-Link und der Download für Git beginnt automatisch.

Step 4- Klicken Sie auf die heruntergeladene EXE-Datei für Git. In unserem Fall verwenden wir die Datei Git-2.6.1-64-bit.exe. Klicken Sie auf Ausführen. Dies wird im nächsten Bildschirm angezeigt.

Step 5 - Klicken Sie auf die Schaltfläche Weiter, die auf dem folgenden Bildschirm angezeigt wird.

Step 6 - Klicken Sie im folgenden Bildschirm auf Weiter, um die allgemeine Lizenzvereinbarung zu akzeptieren.

Step 7 - Wählen Sie den Speicherort für Ihre Git-Installation.

Step 8 - Klicken Sie auf Weiter, um die Standardkomponenten zu akzeptieren, die installiert werden müssen.

Step 9 - Wählen Sie die Option "Git an der Windows-Eingabeaufforderung verwenden", da wir Git unter Windows verwenden werden.

Step 10 - Übernehmen Sie im folgenden Bildschirm die Standardeinstellung "Windows-Stil auschecken, Zeilenenden im Unix-Stil festschreiben" und klicken Sie auf "Weiter".

Step 11 - Wählen Sie im folgenden Bildschirm die Option "Windows-Standardkonsolenfenster verwenden", da wir Windows als System für die Installation von Git verwenden.

Die Installation wird nun gestartet und die folgenden Schritte können zur Konfiguration von Git ausgeführt werden, sobald die Installation abgeschlossen ist.

Git konfigurieren

Nach der Installation von Git müssen die Konfigurationsschritte für die Erstkonfiguration von Git ausgeführt werden.

Das erste, was getan werden muss, ist, die Identität in Git zu konfigurieren und dann einen Benutzernamen und eine E-Mail zu konfigurieren. Das ist wichtig, weil jederGit commitverwendet diese Informationen und ist unveränderlich in die Commits eingebettet, die Sie erstellen. Sie können dies tun, indem Sie die Eingabeaufforderung öffnen und dann die folgenden Befehle eingeben:

git config –global user.name “Username”
git config –global user.email “emailid”

Der folgende Screenshot ist ein Beispiel zum besseren Verständnis.

Diese Befehle ändern die Konfigurationsdatei von Git entsprechend. Um sicherzustellen, dass Ihre Einstellungen wirksam werden, können Sie die Einstellungen der Git-Konfigurationsdatei mit dem folgenden Befehl auflisten.

git config --list

Ein Beispiel für die Ausgabe ist im folgenden Screenshot dargestellt.

Continuous Integration Server

Die nächste wichtige Software, die für die gesamte Pipeline für die kontinuierliche Integration erforderlich ist, ist die Software für die kontinuierliche Integration. Im Folgenden sind die in der Branche am häufigsten verwendeten Continuous Integration-Softwareprogramme aufgeführt:

• Jenkins- Dies ist eine Open Source Continuous Integration-Software, die von vielen Entwicklungsgemeinschaften verwendet wird.

• Jet Brains TeamCity - Dies ist eine der beliebtesten kommerziellen Software für die kontinuierliche Integration, die verfügbar ist, und die meisten Unternehmen verwenden sie für ihre Anforderungen an die kontinuierliche Integration.

• Atlassian Bamboo- Dies ist eine weitere beliebte Continuous Integration-Software, die von einem Unternehmen namens Atlassian Pvt. Ltd. bereitgestellt wird. GmbH.

Alle oben genannten Softwareprogramme arbeiten mit demselben Modell für die kontinuierliche Integration. Für den Zweck dieses Tutorials werden wir uns ansehenJetbrains TeamCity für den Continuous Integration Server.

TeamCity installieren

Im Folgenden finden Sie die Schritte und Systemanforderungen für die Installation von Jet Brains TeamCity auf Ihrem Computer.

System Anforderungen

Erinnerung	4 GB RAM (empfohlen)
Festplattenplatz	1 GB Festplatte für die Installation. Zusätzlicher Speicher ist erforderlich, um den Build-Arbeitsbereich für jedes Projekt zu speichern.
Betriebssystemversion	Kann unter Windows, Linux, Mac OS X installiert werden.

Installation

Step 1 - Die offizielle Website für TeamCity isthttps://www.jetbrains.com/teamcity/. Wenn Sie auf den angegebenen Link klicken, gelangen Sie zur Startseite der offiziellen TeamCity-Website (siehe folgenden Screenshot). Sie können die Seite durchsuchen, um die erforderliche Software für TeamCity herunterzuladen.

Step 2 - Die heruntergeladene EXE-Datei wird zum Ausführen verwendet TeamCity-9.1.6.exe. Doppelklicken Sie auf die ausführbare Datei und klicken Sie dann im nächsten Bildschirm, der angezeigt wird, auf Ausführen.

Step 3 - Klicken Sie auf Weiter, um das Setup zu starten.

Step 4 - Klicken Sie auf die Schaltfläche "Ich stimme zu", um die Lizenzvereinbarung zu akzeptieren und mit der Installation fortzufahren.

Step 5 - Wählen Sie den Speicherort für die Installation und klicken Sie auf Weiter.

Step 6 - Wählen Sie die Standardkomponenten für die Installation aus und klicken Sie auf Weiter

Dadurch wird der Installationsvorgang gestartet. Nach Abschluss des Vorgangs folgt der Konfigurationsprozess.

Step 7- Wählen Sie eine Portnummer für den Server. Am besten verwenden Sie einen anderen Port wie z8080.

Step 8- Als nächstes wird gefragt, unter welchem ​​Konto TeamCity ausgeführt werden soll. Wählen Sie das SYSTEM-Konto und klicken Sie auf Weiter.

Step 9- Als nächstes werden Sie nach den Diensten gefragt, die gestartet werden müssen. Akzeptieren Sie die Standardwerte und klicken Sie dann auf Weiter.

TeamCity konfigurieren

Nach Abschluss der Installation ist der nächste Schritt die Konfiguration von TeamCity. Diese Software kann durch Durchsuchen der folgenden URL im Browser geöffnet werden:

http://locahost:8080

Step 1- Der erste Schritt besteht darin, den Speicherort der Builds anzugeben, die von TeamCity ausgeführt werden. Wählen Sie den gewünschten Ort und klicken Sie auf die Schaltfläche Weiter.

Step 2- Im nächsten Schritt geben Sie die Datenbank zum Speichern aller TeamCity-Artefakte an. Für den Zweck des Tutorials kann man die auswählenInternal (HSQLDB)Dies ist eine interne Datenbank, die am besten für die Verwendung von Produkten zu Testzwecken geeignet ist.

TeamCity verarbeitet dann alle erforderlichen Schritte, um es zum Laufen zu bringen.

Step 3- Als nächstes werden Sie aufgefordert, die Lizenzvereinbarung zu akzeptieren. Akzeptieren Sie dasselbe und klicken Sie auf Weiter.

Step 4- Sie müssen ein Administratorkonto erstellen, mit dem Sie sich bei der TeamCity-Software anmelden. Geben Sie die erforderlichen Details ein und klicken Sie auf die Schaltfläche "Konto erstellen".

Sie werden jetzt bei TeamCity angemeldet.

Das Build-Tool

Das Build-Tool ist ein Tool, das sicherstellt, dass das Programm auf eine bestimmte Weise erstellt wird. Das Tool führt normalerweise eine Liste von Aufgaben aus, die erforderlich sind, damit das Programm ordnungsgemäß erstellt werden kann. Da wir in unserem Beispiel einen betrachten werden.Net program werden wir uns ansehen MSBuildals Build-Tool. Das MSBuild-Tool betrachtet eine Build-Datei, die eine Liste von Aufgaben enthält, die zum Erstellen des Projekts verwendet werden. Schauen wir uns eine typische Build-Datei für ein Webkonfigurationsprojekt an.

Im Folgenden sind die wichtigsten Abschnitte der Build-Datei aufgeführt, die berücksichtigt werden müssen.

IIS-Einstellungen

Die folgenden Einstellungen werden verwendet, um zu bestimmen, welche Portnummer, welcher Pfad auf dem Webserver und welche Art von Authentifizierung beim Ausführen der Anwendung erforderlich ist. Dies sind wichtige Einstellungen, die über den Befehl MSBuild geändert werden, wenn wir später im Lernprogramm erfahren, wie die Bereitstellung ausgeführt wird.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPor>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>

ItemGroup

Dies wird verwendet, um dem Build-Server mitzuteilen, welche abhängigen Binärdateien zum Ausführen dieses Projekts erforderlich sind.

<ItemGroup>
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />

<ItemGroup>
   <Compile Include = "App_Start\BundleConfig.cs" />
   <Compile Include = "App_Start\FilterConfig.cs" />

.Net Framework-Version

Das TargetFrameworkVersionGibt an, welche Version von .Net vorhanden sein muss, damit das Projekt funktioniert. Dies ist unbedingt erforderlich, da der Build fehlschlägt, wenn der Build-Server dies nicht eingerichtet hat.

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

Bereitstellungsumgebung - Amazon

In diesem Lernprogramm stellen wir sicher, dass unser Continuous Integration-Server unsere Anwendung bei Amazon bereitstellen kann. Dazu müssen wir sicherstellen, dass die folgenden Artefakte vorhanden sind.

Datenbankserver

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass der Datenbankserver für die Bereitstellung in Amazon vorhanden ist.

Step 1 - Gehen Sie zur Amazon-Konsole - https://aws.amazon.com/console/.

Melden Sie sich mit Ihren Anmeldeinformationen an. Beachten Sie, dass Sie auf der Amazon-Website eine kostenlose ID beantragen können, mit der Sie eine kostenlose Stufe erhalten, mit der Sie einige der Ressourcen bei Amazon kostenlos nutzen können.

Step 2 - Gehen Sie zum RDS-Bereich, um Ihre Datenbank zu erstellen.

Step 3 - Klicken Sie im nächsten Bildschirm auf Instanzen.

Step 4 - Klicken Sie auf Launch DB Option im nächsten Bildschirm, der angezeigt wird.

Step 5 - Wählen Sie die Registerkarte SQL Server und anschließend die Option Auswählen für SQL Server Express.

Step 6 - Stellen Sie sicher, dass die folgenden Details eingegeben werden, um zu bestätigen, dass Sie die kostenlose Datenbankebene von Amazon verwenden.

Step 7 - Klicken Sie auf die Schaltfläche Nächster Schritt, sobald alle Felder ausgefüllt sind.

Step 8 - Akzeptieren Sie im nächsten Bildschirm alle Standardeinstellungen und klicken Sie auf Launch DB Instance.

Step 9- Daraufhin wird ein Bildschirm angezeigt, auf dem angegeben wird, dass die Datenbank erfolgreich gestartet wurde. Auf derselben Seite befindet sich eine Schaltfläche zum Anzeigen der DB-Instanz. Klicken Sie auf den Link, um Ihre zu sehenDB Instance eingerichtet werden.

Nach einiger Zeit ändert sich der Status des obigen Bildschirms, um zu benachrichtigen, dass die DB-Instanz erfolgreich erstellt wurde.

Webserver

Der nächste Schritt besteht darin, Ihren Webserver bei Amazon zu erstellen, auf dem die Webanwendung gehostet wird. Führen Sie dazu die folgenden Schritte aus, um dies zu erreichen.

Step 1 - Zur Amazon-Konsole gehen - https://aws.amazon.com/console/.

Melden Sie sich mit Ihren Anmeldeinformationen an. Beachten Sie, dass Sie eine beantragen könnenfree id on the Amazon siteDamit haben Sie eine kostenlose Stufe, mit der Sie einige der Ressourcen bei Amazon kostenlos nutzen können.

Step 2 - Geh zum EC2 section um Ihren Webserver zu erstellen.

Step 3 - Klicken Sie im nächsten Bildschirm auf Instanz starten.

Step 4 - Klicken Sie auf Windows - Microsoft Windows Server 2010 R2 Base.

Step 5 - Wählen Sie die t2.microOption, die Teil der kostenlosen Stufe ist. KlickenNext: Configure Instance Details.

Step 6 - Übernehmen Sie die Standardeinstellungen auf dem nächsten Bildschirm und wählen Sie dann die Option Next: Add Storage.

Step 7 - Übernehmen Sie die Standardeinstellungen im nächsten Bildschirm und wählen Sie die Option Next: Tag Instance.

Step 8 - Übernehmen Sie die Standardeinstellungen auf dem nächsten Bildschirm und wählen Sie die Option Next: Configure Security Group.

Step 9 - Übernehmen Sie die Standardeinstellungen auf dem nächsten Bildschirm und wählen Sie die Option Review and Launch.

Step 10 - Klicken Sie im nächsten Bildschirm auf Starten.

Step 11- Im nächsten Bildschirm werden Sie aufgefordert, ein Schlüsselpaar zu erstellen. Dies wird verwendet, um sich zu einem späteren Zeitpunkt beim Server anzumelden. Erstellen Sie einfach das Schlüsselpaar und klicken Sie aufLaunch Instance.

Die Instanz wird jetzt in Amazon eingerichtet.

Es besteht die Möglichkeit, dass bei einem Projekt etwas schief geht. Indem Sie CI effektiv üben, erfahren Sie, was bei jedem Schritt auf dem Weg passiert, und nicht später, wenn sich das Projekt im Entwicklungszyklus befindet. CI hilft Ihnen dabei, Risiken zu identifizieren und zu mindern, wenn sie auftreten, und erleichtert die Bewertung und Berichterstattung über den Zustand des Projekts anhand konkreter Beweise.

Dieser Abschnitt konzentriert sich auf die Risiken, die durch die Verwendung der kontinuierlichen Integration vermieden werden können.

Bei jedem Projekt gibt es viele Risiken, die gemanagt werden müssen. Durch die Beseitigung der Risiken zu einem früheren Zeitpunkt im Entwicklungslebenszyklus besteht eine geringere Wahrscheinlichkeit, dass sich diese Risiken später zu Problemen entwickeln, wenn das System tatsächlich in Betrieb genommen wird.

Risiko 1 - Mangel an bereitstellbarer Software

“It works on my machine but does not work on another”- Dies ist wahrscheinlich eine der häufigsten Ausdrücke in einer Softwareorganisation. Aufgrund der Anzahl der Änderungen, die täglich an Software-Builds vorgenommen werden, besteht manchmal wenig Vertrauen darüber, ob der Build der Software tatsächlich funktioniert oder nicht. Dieses Problem hat die folgenden drei Nebenwirkungen.

• Wenig oder gar kein Vertrauen, ob wir die Software überhaupt erstellen könnten.

• Lange Integrationsphasen, bevor die Software intern (dh Testteam) oder extern (dh Kunde) bereitgestellt wird. Während dieser Zeit wird nichts anderes getan.

• Unfähigkeit, testbare Builds zu produzieren und zu reproduzieren.

Lösung

Eliminierung einer engen Kopplung zwischen der IDE und den Erstellungsprozessen. Verwenden Sie eine separate Maschine ausschließlich zur Integration der Software. Stellen Sie sicher, dass alles, was Sie zum Erstellen der Software benötigen, im Versionskontroll-Repository enthalten ist. Erstellen Sie abschließend ein Continuous Integration-System.

Der Continuous Integration-Server kann nach Änderungen im Versionskontroll-Repository suchen und das Projekterstellungsskript ausführen, wenn eine Änderung am Repository festgestellt wird. Die Leistungsfähigkeit des Continuous Integration-Systems kann erweitert werden, indem der Build Tests durchläuft, Inspektionen durchführt und die Software in Entwicklungs- und Testumgebungen bereitstellt. Auf diese Weise haben Sie immer eine funktionierende Software.

“Inability to synchronize with the database”- Manchmal können Entwickler die Datenbank während der Entwicklung nicht schnell neu erstellen und haben daher Schwierigkeiten, Änderungen vorzunehmen. Dies ist häufig auf eine Trennung zwischen dem Datenbankteam und dem Entwicklungsteam zurückzuführen. Jedes Team wird sich auf seine eigenen Aufgaben konzentrieren und wenig zusammenarbeiten. Dieses Problem hat die folgenden drei Nebenwirkungen:

• Angst, Änderungen vorzunehmen oder die Datenbank oder den Quellcode umzugestalten.

• Schwierigkeiten beim Auffüllen der Datenbank mit verschiedenen Testdatensätzen.

• Schwierigkeiten bei der Wartung von Entwicklungs- und Testumgebungen (z. B. Entwicklung, Integration, Qualitätssicherung und Test).

Lösung

Die Lösung für das oben genannte Problem besteht darin, sicherzustellen, dass alle Datenbankartefakte im Versionskontroll-Repository platziert werden. Dies bedeutet, dass alles erforderlich ist, um das Datenbankschema und die Daten neu zu erstellen: Datenbankerstellungsskripts, Datenmanipulationsskripts, gespeicherte Prozeduren, Trigger und andere Datenbankressourcen.

Erstellen Sie die Datenbank und die Daten aus Ihrem Build-Skript neu, indem Sie Ihre Datenbank und Tabellen löschen und neu erstellen. Wenden Sie als Nächstes die gespeicherten Prozeduren und Trigger an und fügen Sie schließlich die Testdaten ein.

Testen (und überprüfen) Sie Ihre Datenbank. In der Regel verwenden Sie die Komponententests, um die Datenbank und die Daten zu testen. In einigen Fällen müssen Sie datenbankspezifische Tests schreiben.

Risiko 2 - Entdecken von Fehlern spät im Lebenszyklus

Da es so viele Änderungen gibt, die häufig von mehreren Entwicklern am Quellcode vorgenommen werden, besteht immer die Möglichkeit, dass ein Fehler im Code eingeführt wird, der erst zu einem späteren Zeitpunkt erkannt werden kann. In solchen Fällen kann dies große Auswirkungen haben, da die Beseitigung des Fehlers umso teurer wird, je später der Fehler in der Software erkannt wird.

Lösung

Regression Testing- Dies ist der wichtigste Aspekt eines jeden Softwareentwicklungszyklus, Test und erneuter Test. Bei größeren Änderungen am Softwarecode muss unbedingt sichergestellt werden, dass alle Tests ausgeführt werden. Und dies kann mit Hilfe des Continuous Integration Servers automatisiert werden.

Test Coverage- Es macht keinen Sinn zu testen, ob die Testfälle nicht die gesamte Funktionalität des Codes abdecken. Es ist wichtig sicherzustellen, dass die zum Testen der Anwendung erstellten Testfälle vollständig sind und alle Codepfade getestet werden.

Wenn Sie beispielsweise einen Anmeldebildschirm haben, der getestet werden muss, können Sie keinen Testfall haben, der das Szenario einer erfolgreichen Anmeldung aufweist. Sie benötigen einen negativen Testfall, bei dem ein Benutzer eine andere Kombination aus Benutzernamen und Kennwörtern eingibt und dann sehen muss, was in solchen Szenarien passiert.

Risiko 3 - Mangelnde Projektsichtbarkeit

Manuelle Kommunikationsmechanismen erfordern viel Koordination, um sicherzustellen, dass die Projektinformationen rechtzeitig an die richtigen Personen weitergegeben werden. Sich an den Entwickler neben Ihnen zu beugen und ihn wissen zu lassen, dass sich der neueste Build auf dem freigegebenen Laufwerk befindet, ist ziemlich effektiv, lässt sich jedoch nicht sehr gut skalieren.

Was ist, wenn andere Entwickler diese Informationen benötigen und sich in einer Pause befinden oder anderweitig nicht verfügbar sind? Wie werden Sie benachrichtigt, wenn ein Server ausfällt? Einige glauben, dass sie dieses Risiko durch manuelles Senden einer E-Mail mindern können. Dies kann jedoch nicht sicherstellen, dass die Informationen zur richtigen Zeit an die richtigen Personen übermittelt werden, da Sie möglicherweise versehentlich Interessenten auslassen und einige möglicherweise zu diesem Zeitpunkt keinen Zugriff auf ihre E-Mail haben.

Lösung

Die Lösung für dieses Problem ist wieder der Continuous Integration Server. Alle CI-Server können automatisierte E-Mails auslösen, wenn die Builds fehlschlagen. Durch diese automatische Benachrichtigung aller wichtigen Stakeholder wird auch sichergestellt, dass alle an Bord sind, um den aktuellen Status der Software zu ermitteln.

Risiko 4 - Software von geringer Qualität

Es gibt Mängel und dann gibt es mögliche Mängel. Sie können potenzielle Fehler haben, wenn Ihre Software nicht gut entwickelt ist oder wenn sie nicht den Projektstandards entspricht oder komplex zu warten ist. Manchmal wird dies als Code- oder Designgeruch bezeichnet - „ein Symptom dafür, dass etwas nicht stimmt“.

Einige glauben, dass Software von geringerer Qualität nur aufgeschobene Projektkosten (nach Lieferung) sind. Dies kann zu einer Verschiebung der Projektkosten führen, führt jedoch auch zu vielen anderen Problemen, bevor Sie die Software an die Benutzer liefern. Übermäßig komplexer Code, Code, der nicht der Architektur folgt, und duplizierter Code führen normalerweise zu Fehlern in der Software. Das Auffinden dieser Code- und Designgerüche, bevor sie sich in Fehlern manifestieren, kann sowohl Zeit als auch Geld sparen und zu qualitativ hochwertigerer Software führen.

Lösung

Es gibt Softwarekomponenten zur Durchführung einer Codequalitätsprüfung, die in die CI-Software integriert werden können. Dies kann ausgeführt werden, nachdem der Code erstellt wurde, um sicherzustellen, dass der Code tatsächlich den richtigen Codierungsrichtlinien entspricht.

Versionskontrollsysteme, auch als Quellcodeverwaltungssysteme, Quellcodeverwaltungssysteme oder Revisionskontrollsysteme bezeichnet, sind ein Mechanismus zum Speichern mehrerer Versionen Ihrer Dateien, sodass Sie beim Ändern einer Datei weiterhin auf die vorherigen Revisionen zugreifen können.

Das erste beliebte Versionskontrollsystem war ein proprietäres UNIX-Tool namens SCCS(Source Code Control System) aus den 1970er Jahren. Dies wurde ersetzt durchRCS, das Revisionskontrollsystem und später CVS, System für gleichzeitige Versionen.

Jetzt werden die beliebtesten Versionskontrollsysteme verwendet Subversion und Git. Schauen wir uns zunächst an, warum wir ein Versionskontrollsystem verwenden müssen, und schauen wir uns dann an, wie wir unseren Quellcode einfügenGit source code repository system.

Zweck des Versionskontrollsystems

Ein Grund, warum wir den Begriff Versionskontrolle der Quellcodeverwaltung vorziehen, ist, dass die Versionskontrolle nicht nur für den Quellcode gilt. Jedes einzelne Artefakt im Zusammenhang mit der Erstellung Ihrer Software sollte unter Versionskontrolle stehen.

Developers should use it for source code - Standardmäßig muss der gesamte Quellcode im Versionskontrollsystem gespeichert werden

Related artefacts- Jedes System verfügt über zu dem Quellcode verwandte Artefakte wie Datenbankskripte, Erstellungs- und Bereitstellungsskripte, Dokumentation, Bibliotheken und Konfigurationsdateien für Ihre Anwendung, Ihren Compiler und die Sammlung von Tools usw. All dies ergänzt den gesamten Entwicklungs- und Bereitstellungsprozess und muss auch im Versionskontrollsystem gespeichert werden.

Durch Speichern aller Informationen für die Anwendung in der Quellcodeverwaltung wird es einfacher, die Test- und Produktionsumgebungen, in denen Ihre Anwendung ausgeführt wird, neu zu erstellen. Dies sollte Konfigurationsinformationen für den Software-Stack Ihrer Anwendung und die Betriebssysteme enthalten, aus denen die Umgebung, DNS-Zonendateien, die Firewall-Konfiguration usw. bestehen.

Sie benötigen mindestens alles, um die Binärdateien Ihrer Anwendung und die Umgebungen, in denen sie ausgeführt werden, neu zu erstellen. Ziel ist es, alles, was sich zu jedem Zeitpunkt im Projektverlauf möglicherweise ändern kann, kontrolliert zu speichern. Auf diese Weise können Sie zu jedem Zeitpunkt in der Projekthistorie eine genaue Momentaufnahme des Status des gesamten Systems von der Entwicklungsumgebung zur Produktionsumgebung wiederherstellen.

Es ist sogar hilfreich, die Konfigurationsdateien für die Entwicklungsumgebungen des Entwicklungsteams in der Versionskontrolle zu belassen, da es für alle im Team einfach ist, dieselben Einstellungen zu verwenden. Analysten sollten Anforderungsdokumente speichern. Tester sollten ihre Testskripte und -verfahren in der Versionskontrolle behalten. Projektmanager sollten hier ihre Release-Pläne, Fortschrittsdiagramme und Risikoprotokolle speichern.

Kurz gesagt, jedes Mitglied des Teams sollte alle Dokumente oder Dateien, die sich auf das Projekt beziehen, in der Versionskontrolle speichern.

Arbeiten mit Git für das Quellcode-Versionskontrollsystem

Dieser Abschnitt konzentriert sich nun darauf, wie Git als Versionskontrollsystem verwendet werden kann. Es wird sich darauf konzentrieren, wie Sie Ihren Code in das Versionskontrollsystem hochladen und Änderungen daran verwalten können.

Unsere Demo-Anwendung

Für den Zweck dieses gesamten Tutorials werden wir uns ein einfaches ansehen Web ASP.NetAnwendung, die für den gesamten kontinuierlichen Integrationsprozess verwendet wird. Wir müssen uns für diese Übung nicht auf die gesamten Codedetails konzentrieren. Nur ein Überblick über die Funktionsweise des Projekts reicht aus, um den gesamten kontinuierlichen Integrationsprozess zu verstehen. Diese .NET-Anwendung wurde mit dem erstelltVisual Studio Integrated Development Environment.

Der folgende Screenshot zeigt die Struktur der Lösung in der Visual Studio-Umgebung. Es ist eine sehr einfache Webanwendung, die den Hauptcode in der enthältDemo.aspx Datei.

Der Code in der Datei Demo.aspx wird im folgenden Programm angezeigt:

<html xmlns = "http://www.w3.org/1999/xhtml">
   <head runat = "server">
      <title>TutorialsPoint</title>
   </head>
   
   <body>
      <form id = "form1" runat="server">
         <div><%Response.Write("Continuous Integration"); %></div>
      </form>
   </body>
   
</html>

Der Code ist sehr einfach und gibt nur die Zeichenfolge "Continuous Integration" an den Browser aus.

Wenn Sie das Projekt in Google Chrome ausführen, erfolgt die Ausgabe wie im folgenden Screenshot gezeigt.

Verschieben des Quellcodes nach Git

Wir werden zeigen, wie der Quellcode von der Befehlszeilenschnittstelle nach Git verschoben wird, damit der Endbenutzer besser weiß, wie Git verwendet werden kann.

Step 1 - Initialisieren Sie die Git Repository. Gehen Sie zur Eingabeaufforderung, gehen Sie zu Ihrem Projektordner und geben Sie den Befehl eingit init. Dieser Befehl fügt die erforderlichen Git-Dateien zum Projektordner hinzu, damit Git sie erkennen kann, wenn sie in das Repository hochgeladen werden müssen.

Step 2- Hinzufügen Ihrer Dateien, die zum Git-Repository hinzugefügt werden müssen. Dies kann durch Ausgabe desgit add command. Die Option dot teilt Git mit, dass alle Dateien im Projektordner zum Git-Repository hinzugefügt werden müssen.

Step 3- Der letzte Schritt besteht darin, die Projektdateien in das Git-Repository zu übertragen. Dieser Schritt ist erforderlich, um sicherzustellen, dass alle Dateien jetzt Teil von Git sind. Der auszuführende Befehl ist im folgenden Screenshot dargestellt. Das–m option ist ein Kommentar zum Hochladen von Dateien.

Ihre Lösung ist jetzt in Git verfügbar.

Im Folgenden finden Sie einige der wichtigsten Funktionen oder Vorgehensweisen für die kontinuierliche Integration.

• Maintain a single source repository- Der gesamte Quellcode wird in einem einzigen Repository verwaltet. Dadurch wird vermieden, dass der Quellcode über mehrere Standorte verteilt wird. Werkzeuge wieSubversion and Git sind die beliebtesten Tools zur Pflege des Quellcodes.

• Automate the build- Die Erstellung der Software sollte so erfolgen, dass sie automatisiert werden kann. Wenn mehrere Schritte ausgeführt werden müssen, muss das Build-Tool dazu in der Lage sein. Für .Net ist MSBuild das Standard-Build-Tool, und für Java-basierte Anwendungen verfügen Sie über Tools wieMaven and Grunt.

• Make your build self-testing- Der Build sollte testbar sein. Direkt nach dem Build sollten Testfälle ausgeführt werden, um sicherzustellen, dass Tests für die verschiedenen Funktionen der Software durchgeführt werden können.

• Every commit should build on an integration machine- Der Integrationscomputer ist der Buildserver und es sollte sichergestellt werden, dass der Build auf diesem Computer ausgeführt wird. Dies bedeutet, dass alle abhängigen Komponenten auf dem Continuous Integration-Server vorhanden sein sollten.

• Keep the build fast- Der Build sollte in wenigen Minuten erfolgen. Der Build sollte nicht stundenlang dauern, da dies bedeuten würde, dass die Build-Schritte nicht richtig konfiguriert sind.

• Test in a clone of the production environment- Die Build-Umgebung sollte der Produktionsumgebung nahe kommen. Wenn zwischen diesen Umgebungen große Unterschiede bestehen, kann es vorkommen, dass der Build in der Produktion fehlschlägt, obwohl er auf dem Buildserver weitergegeben wird.

• Everyone can see what is happening - Der gesamte Prozess des Erstellens, Testens und Bereitstellens sollte für alle sichtbar sein.

• Automate deployment- Kontinuierliche Integration führt zu kontinuierlicher Bereitstellung. Es muss unbedingt sichergestellt werden, dass der Build einfach in einer Staging- oder Produktionsumgebung bereitgestellt werden kann.

Im Folgenden finden Sie eine Liste der wichtigsten Anforderungen für die kontinuierliche Integration.

• Check-In Regularly- Die wichtigste Methode für eine ordnungsgemäße kontinuierliche Integration ist das häufige Einchecken in den Trunk oder die Hauptleitung des Quellcode-Repositorys. Das Einchecken des Codes sollte mindestens ein paar Mal am Tag erfolgen. Das regelmäßige Einchecken bringt viele weitere Vorteile. Dadurch werden Änderungen kleiner und es ist weniger wahrscheinlich, dass der Build beschädigt wird. Dies bedeutet, dass die aktuellste Version der Software, auf die zurückgesetzt werden soll, bekannt ist, wenn bei einem nachfolgenden Build ein Fehler gemacht wird.

  Es hilft auch, disziplinierter beim Refactoring von Code zu sein und sich an kleine Änderungen zu halten, die das Verhalten bewahren. Es hilft sicherzustellen, dass Änderungen, die viele Dateien ändern, weniger wahrscheinlich mit der Arbeit anderer Personen in Konflikt stehen. Dadurch können die Entwickler explorativer vorgehen, Ideen ausprobieren und verwerfen, indem sie zur letzten festgeschriebenen Version zurückkehren.

• Create a Comprehensive Automated Test Suite- Wenn Sie nicht über eine umfassende Suite automatisierter Tests verfügen, bedeutet ein bestehender Build nur, dass die Anwendung kompiliert und zusammengestellt werden kann. Während dies für einige Teams ein großer Schritt ist, ist es wichtig, ein gewisses Maß an automatisierten Tests durchzuführen, um das Vertrauen zu gewinnen, dass Ihre Anwendung tatsächlich funktioniert.

  Normalerweise gibt es 3 Arten von Tests, die in Continuous Integration durchgeführt werden, nämlich unit tests, component tests, und acceptance tests.

  Unit-Tests werden geschrieben, um das Verhalten kleiner Teile Ihrer Anwendung isoliert zu testen. Sie können normalerweise ausgeführt werden, ohne die gesamte Anwendung zu starten. Sie treffen nicht auf die Datenbank (falls Ihre Anwendung eine hat), das Dateisystem oder das Netzwerk. Sie erfordern nicht, dass Ihre Anwendung in einer produktionsähnlichen Umgebung ausgeführt wird. Unit-Tests sollten sehr schnell ausgeführt werden - Ihre gesamte Suite sollte selbst für große Anwendungen in weniger als zehn Minuten ausgeführt werden können.

  Komponententests testen das Verhalten mehrerer Komponenten Ihrer Anwendung. Wie bei Unit-Tests muss nicht immer die gesamte Anwendung gestartet werden. Sie können jedoch die Datenbank, das Dateisystem oder andere Systeme (die möglicherweise ausgeblendet werden) treffen. Die Ausführung von Komponententests dauert normalerweise länger.

• Keep the Build and Test Process Short - Wenn das Erstellen des Codes und das Ausführen der Komponententests zu lange dauert, treten die folgenden Probleme auf.

  • Die Benutzer hören auf, einen vollständigen Build durchzuführen, und führen die Tests vor dem Einchecken aus. Sie werden mehr fehlerhafte Builds erhalten.

  • Der Prozess der kontinuierlichen Integration dauert so lange, dass mehrere Commits stattgefunden haben, bis Sie den Build erneut ausführen können, sodass Sie nicht wissen, welcher Check-in den Build beschädigt hat.

  • Die Leute checken seltener ein, weil sie ewig darauf warten müssen, dass die Software erstellt und die Tests ausgeführt werden.

• Don’t Check-In on a Broken Build- Der größte Fehler bei der kontinuierlichen Integration ist das Einchecken in einen defekten Build. Wenn der Build unterbrochen wird, warten die verantwortlichen Entwickler darauf, ihn zu beheben. Sie identifizieren die Ursache des Bruchs so schnell wie möglich und beheben sie. Wenn wir diese Strategie anwenden, sind wir immer in der besten Position, um herauszufinden, was den Bruch verursacht hat, und um ihn sofort zu beheben.

  Wenn einer unserer Kollegen eingecheckt hat und infolgedessen den Build beschädigt hat, benötigen sie einen klaren Überblick über das Problem, um die beste Chance zu haben, das Problem zu beheben. Wenn diese Regel verletzt wird, dauert es unweigerlich viel länger, bis der Build repariert ist. Die Leute gewöhnen sich daran, dass der Build kaputt ist, und sehr schnell geraten Sie in eine Situation, in der der Build die ganze Zeit kaputt bleibt.

• Always Run All Commit Tests Locally Before Committing- Stellen Sie immer sicher, dass die für die Anwendung entwickelten Tests zuerst auf einem lokalen Computer ausgeführt werden, bevor Sie sie auf dem CI-Server ausführen. Dies soll sicherstellen, dass die richtigen Testfälle geschrieben werden. Wenn der CI-Prozess fehlerhaft ist, liegt dies an den fehlgeschlagenen Testergebnissen.

• Take Responsibility for All Breakages that Result from Your Changes- Wenn Sie eine Änderung vornehmen und alle von Ihnen geschriebenen Tests erfolgreich sind, andere jedoch nicht funktionieren, ist der Build weiterhin fehlerhaft. Normalerweise bedeutet dies, dass Sie einen Regressionsfehler in die Anwendung eingeführt haben. Es liegt in Ihrer Verantwortung - weil Sie die Änderung vorgenommen haben -, alle Tests zu korrigieren, die aufgrund Ihrer Änderungen nicht bestanden wurden. Im Kontext von CI scheint dies offensichtlich, aber tatsächlich ist es in vielen Projekten keine übliche Praxis.

Für eine Vielzahl von Programmiersprachen stehen verschiedene Build-Tools zur Verfügung. Einige der beliebtesten Build-Tools sind:Ant for Java und MSBuild for .NET. Die Verwendung eines speziell für die Erstellung von Software entwickelten Skript-Tools anstelle eines benutzerdefinierten Satzes von Shell- oder Batch-Skripten ist die effektivste Methode zur Entwicklung einer konsistenten, wiederholbaren Build-Lösung.

Warum brauchen wir also zuerst einen Build-Prozess? Für den Anfang, für einen Continuous Integration-Server, sollte der Erstellungsprozess einfach zu handhaben und nahtlos zu implementieren sein.

Nehmen wir ein einfaches Beispiel dafür, wie eine Build-Datei für .Net aussehen kann -

<?xml version = "1.0" encoding = "utf-8"?>
<project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
   <Target Name = "Build">
      <Message Text = "Building Project" />
      <MSBuild Projects = "project.csproj" Targets = "Build/>"
   </Target>
</project>

Die folgenden Aspekte müssen bezüglich des obigen Codes beachtet werden:

• Ein Ziel wird mit dem Namen Build erstellt. Dabei ist ein Ziel eine Sammlung logischer Schritte, die in einem Erstellungsprozess ausgeführt werden müssen. Sie können mehrere Ziele haben und Abhängigkeiten zwischen Zielen haben.

• In unserem Ziel behalten wir eine Optionsnachricht, die angezeigt wird, wenn der Erstellungsprozess beginnt.

• Das MSBuild task wird verwendet, um anzugeben, welches .NET-Projekt erstellt werden muss.

Das obige Beispiel zeigt eine sehr einfache Build-Datei. Bei der kontinuierlichen Integration wird sichergestellt, dass diese Datei auf dem neuesten Stand gehalten wird, um sicherzustellen, dass der gesamte Erstellungsprozess nahtlos verläuft.

Erstellen einer Lösung in .Net

Das Standard-Build-Tool für .Net ist MSBuild und wird mit dem .Net-Framework geliefert. Abhängig vom Framework auf Ihrem System steht Ihnen die entsprechende MSbuild-Version zur Verfügung. Wenn Sie beispielsweise das .NET-Framework am Standardspeicherort installiert haben, finden Sie dasMSBuild.exe Datei am folgenden Speicherort -

C:\Windows\Microsoft.NET\Framework\v4.0.30319

Mal sehen, wie wir unser Beispielprojekt erstellen können. Nehmen wir an, unser Beispielprojekt befindet sich in einem Ordner namensC:\Demo\Simple.

Um MSBuild zum Erstellen der obigen Lösung zu verwenden, müssen Sie die Eingabeaufforderung öffnen und die Option MSBuild verwenden, wie im folgenden Programm gezeigt.

msbuild C:\Demo\Simple\Simple.csproj

Im obigen Beispiel ist csprojist die Projektdatei, die für .Net spezifisch ist. Die csproj-Datei enthält alle relevanten Informationen, um sicherzustellen, dass die erforderlichen Informationen vorhanden sind, damit die Software ordnungsgemäß erstellt werden kann. Es folgt der Screenshot der Ausgabe des MSBuild-Befehls.

Sie müssen sich keine Gedanken über die Ausgabewarnungen machen, solange der Build erfolgreich war und keine Fehler aufgetreten sind.

Schauen wir uns nun bestimmte Aspekte der MSBuild-Datei an, um zu sehen, was sie bedeuten. Diese Aspekte sind wichtig, um sie aus einem kontinuierlichen Integrationszyklus zu kennen.

Build-Skripte werden verwendet, um die Lösung zu erstellen, die Teil des gesamten kontinuierlichen Integrationszyklus ist. Schauen wir uns das allgemeine Build-Skript an, das als Teil von Visual Studio in erstellt wird.Netfür unsere Musterlösung. Das Build-Skript ist selbst für eine einfache Lösung ziemlich umfangreich, daher werden wir die wichtigsten Teile davon durchgehen. Standardmäßig wird das Build-Skript in einer Datei mit demselben Namen wie die Hauptlösung in Visual Studio gespeichert. Also in unserem Fall, wenn Sie die Datei öffnenSimple.csprojsehen Sie alle Einstellungen, die zum Erstellen der Lösung verwendet werden.

• Abhängigkeit von der verwendeten MSBuild-Version - In den folgenden Einstellungen werden die auf dem CI-Server installierten MSBuild-Dateien verwendet.

<VisualStudioVersion Condition = "'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> <VSToolsPath Condition = "'$(VSToolsPath)' == ''"> 
   $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)
</VSToolsPath>

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

<Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" /> <Import Project = "$(VSToolsPath)\WebApplications\
   Microsoft.WebApplication.targets" Condition = "'$(VSToolsPath)' ! = ''" /> <Import Project = "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\
   WebApplications\Microsoft.WebApplication.targets" Condition = "false" />

• Welche Dateien sind erforderlich, um die Lösung ordnungsgemäß zu erstellen? ItemGroupDas Tag enthält alle erforderlichen .NET-Dateien, die für die erfolgreiche Erstellung des Projekts erforderlich sind. Diese Dateien müssen sich entsprechend auf dem Build-Server befinden.

<ItemGroup>
   <Reference Include = "Microsoft.CSharp" />
   <Reference Include = "System.Web.DynamicData" />
   <Reference Include = "System.Web.Entity" />
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />
   <Reference Include = "System" />
   <Reference Include = "System.Data" />
   <Reference Include = "System.Core" />
   <Reference Include = "System.Data.DataSetExtensions" />
   <Reference Include = "System.Web.Extensions" />
   <Reference Include = "System.Xml.Linq" />
   <Reference Include = "System.Drawing" />
   <Reference Include = "System.Web" />
   <Reference Include = "System.Xml" />
   <Reference Include = "System.Configuration" />
   <Reference Include = "System.Web.Services" />
   <Reference Include = "System.EnterpriseServices"/>
</ItemGroup>

• Welche Webservereinstellungen müssen verwendet werden? Wenn wir unser Thema "Kontinuierliche Bereitstellung" besuchen, werden Sie sehen, wie MSBuild verwendet wird, um diese Einstellungen zu überschreiben und auf dem Server Ihrer Wahl bereitzustellen.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>

Der nächste wichtige Schritt besteht darin, sicherzustellen, dass die Lösung auf dem Build-Server aufbaut. Der erste Teil ist ein manueller Schritt, da wir vor der Verwendung des Tools für die kontinuierliche Integration zunächst sicherstellen müssen, dass der Build auf dem Build-Server auf dieselbe Weise ausgeführt wird wie auf dem Client-Computer. Dazu müssen wir die folgenden Schritte ausführen:

Step 1- Kopieren Sie die gesamte Lösungsdatei auf den Server. Wir hatten einen Amazon-Instanzserver erstellt, der als Build-Server verwendet werden sollte. Machen Sie also eine manuelle Kopie auf den Server des gesamten.Net Lösung auf den Server.

Step 2- Stellen Sie sicher, dass das Framework auf dem Server vorhanden ist. Wenn Sie Ihre Anwendung in .Net Framework 4.0 auf Ihrem Clientcomputer kompiliert haben, müssen Sie sicherstellen, dass sie auch auf dem Servercomputer installiert ist. Also geh zum OrtC:\Windows\Microsoft.NET\Framework auf Ihrem Server und stellen Sie sicher, dass das gewünschte Framework vorhanden ist.

Step 3 - Lassen Sie uns jetzt einfach MSBuild auf dem Server ausführen und sehen, was passiert.

Ok, es sieht so aus, als hätten wir einen Fehler gefunden. Es gibt eine wichtige Lektion in der kontinuierlichen Integration: Sie müssen sicherstellen, dass der Build auf dem Build-Server funktioniert. Dazu müssen Sie sicherstellen, dass die gesamte erforderliche Software auf dem Build-Server installiert ist.

Für .Net müssen wir eine Komponente namens installieren Visual Studio Redistributable package. Dieses Paket enthält alle erforderlichen Dateien, die für a erforderlich sind.NetAnwendung zum Aufbau auf einem Server. Führen Sie also die folgenden Installationsschritte auf dem Build-Server aus.

Step 4 - Doppelklicken Sie auf die ausführbare Datei, um die Installation zu starten.

Step 5 - Stimmen Sie im nächsten Schritt den Lizenzbedingungen zu und klicken Sie auf Installieren.

Step 6 - Wenn wir jetzt MSBuild ausführen, müssen wir sicherstellen, dass wir beim Aufrufen von MSBuild einen zusätzlichen Parameter einschließen, der - p:VisualStudioversion = 12.0. Dadurch wird sichergestellt, dass MSBuild auf die Dateien verweist, die im vorherigen Schritt heruntergeladen wurden.

Jetzt können wir sehen, dass die Lösung ordnungsgemäß erstellt wurde, und wir wissen auch, dass unser Basisprojekt ordnungsgemäß auf dem Server erstellt wurde.

Der nächste wichtige Aspekt besteht darin, sicherzustellen, dass unser Basiscode in unseren Quellcode-Repository-Verwaltungsserver Git eingecheckt wird. Dazu müssen wir diese Schritte ausführen.

Step 1- Initialisieren Sie das Repository, damit es auf Git hochgeladen werden kann. Dies geschieht mit demgitBefehl init. Sie müssen also in Ihren Projektordner gehen und das ausgebengit init Befehl.

Step 2- Der nächste Schritt heißt Staging-Dateien in Git. Dadurch werden alle Dateien im Projektordner vorbereitet, die zu Git hinzugefügt werden müssen. Du machst das mit demgit addBefehl wie im folgenden Screenshot gezeigt. Das '.' Mit der Notation wird angegeben, dass alle Dateien im Verzeichnis und im Unterverzeichnis im Commit enthalten sein sollen.

Step 3 - Der letzte Schritt besteht darin, die Dateien in das Git-Repository zu übertragen, sodass es jetzt ein vollwertiges Git-Repository ist.

Nachdem wir unseren Quellcode im Git-Repository haben und der gesamte ursprüngliche Code auf dem Build-Server funktioniert, ist es an der Zeit, ein Projekt auf unserem Continuous Integration-Server zu erstellen. Dies kann über die folgenden Schritte erfolgen:

Step 1- Melden Sie sich bei der TeamCity-Software an. Gehen Sie zur URL auf Ihrem Continuous Integration Server -http://localhost:8080/login.html.

Geben Sie die Administratoranmeldeinformationen ein und melden Sie sich beim Server an.

Step 2- Sobald Sie angemeldet sind, wird der Startbildschirm angezeigt. KlickenCreate Project um ein neues Projekt zu starten.

Step 3- Geben Sie einen Namen für das Projekt ein und klicken Sie auf Erstellen, um das Projekt zu starten. In unserem Fall geben wir unserem Projekt den Namen 'Demo', wie im folgenden Screenshot gezeigt.

Step 4- Der nächste Schritt besteht darin, das Git-Repository zu erwähnen, das in unserem Projekt verwendet wird. Denken Sie daran, dass in einer Continuous Integration-Umgebung der CI-Server den Code aus dem Git-fähigen Repository abrufen muss. Wir haben unseren Projektordner bereits im vorherigen Schritt als Git-fähiges Repository aktiviert. In TeamCity müssen Sie einen VCS-Stamm erstellen. Klicken Sie dazu aufVCS Roots im Hauptbildschirm des Projekts.

Step 5 - Klicken Sie im nächsten Bildschirm auf Create VCS root wie im folgenden Screenshot gezeigt.

Step 6 - Führen Sie im nächsten Bildschirm die folgenden Schritte aus:

• Erwähnen Sie den VCS-Typ als Git.

• Geben Sie einen Namen für das VCS-Stammverzeichnis ein. Dies kann ein beliebiger Anzeigename sein. Wir haben den Namen als angegebenApp.

• Geben Sie die Abruf-URL als C:\Demo\Simple - Das ist out git aktiviertes Repository.

• Wenn Sie den Bildschirm nach unten scrollen, erhalten Sie eine Schaltfläche zum Testen der Verbindung. Klicken Sie darauf, um sicherzustellen, dass Sie erfolgreich eine Verbindung zum Git-fähigen Repository herstellen können.

Step 7 - Klicken Sie auf Erstellen. Ihr Repository wird nun wie im folgenden Bild gezeigt registriert.

Step 8- Der nächste Schritt besteht darin, eine Build-Konfiguration zu erstellen, die zum Erstellen des Projekts verwendet wird. Gehen Sie zu Ihrem Projektbildschirm inTeamCity → General Settings. Klicken Sie auf Build-Konfiguration erstellen.

Step 9- Geben Sie im folgenden Bildschirm einen Namen für die Build-Konfiguration ein. In unserem Fall haben wir es so genanntDemoBuild Klicken Sie dann auf Erstellen.

Step 10 - Im nächsten Bildschirm werden Sie aufgefordert, die auszuwählen VCS repositorywelches in den früheren Schritten erstellt wurde. Also wähle den Namen‘App’ und klicken Sie auf Anhängen.

Step 11- Jetzt müssen wir im nächsten Bildschirm die Erstellungsschritte konfigurieren. Klicken Sie also auf 'configure build steps manually'Hyperlink.

Step 12 - Im nächsten Build-Bildschirm müssen wir die folgenden Details eingeben:

• Wählen Sie den Runner-Typ als MSBuild.

• Geben Sie einen optionalen Namen für den Schrittnamen an.

• Geben Sie den Namen der Datei an, die erstellt werden soll. Wenn wir in den früheren Abschnitten MSbuild angeben, sehen wir normalerweise, dass wir die Option gebenSimple.csproj. Das Gleiche muss hier angegeben werden.

• Wählen Sie die MSBuild-Version als "Microsoft Build Tools 2013".

• Wählen Sie das MSBuild ToolsVersion als 12.0.

• Scrollen Sie auf der Seite nach unten, um die Einstellungen zu speichern.

Step 13 - Klicken Sie im nächsten Bildschirm auf Ausführen.

Sie werden sehen, wie Ihre Anwendung gerade erstellt wird.

Sie sollten einen erfolgreichen Bildschirm erhalten, was ein gutes Zeichen dafür ist, dass Ihre Lösung ordnungsgemäß erstellt wird.

Sie können auch in Ihr Build-Protokoll gehen, um alle Schritte anzuzeigen, die vom Continuous Integration-Server ausgeführt wurden (siehe folgenden Screenshot).

Nachdem wir unseren Basiscode in Git und einen Link zum Continuous Integration-Server haben, ist es endlich Zeit, den ersten Schritt der Continuous Integration in Aktion zu sehen. Dazu werden auf dem Continuous Integration-Server Aufgaben wie Trigger definiert, wodurch der gesamte Continuous Integration-Prozess so nahtlos wie möglich wird. Nehmen wir eine Änderung an unserem Code in Visual Studio vor.

Step 1 - Geh zum Demo.aspx Seite in Visual Studio und ändern Sie den Titel der Seite.

Step 2 - Wenn wir unser Git-Repository über das abfragen git status Befehl, werden Sie in der Tat sehen, dass die Demo.aspx Datei wurde geändert.

Jetzt müssen wir sicherstellen, dass jede Änderung in unserem Code einen Build in unserem Continuous Integration Server auslöst. Dazu müssen wir folgende Änderungen vornehmen.

Step 3 - Gehen Sie zu Ihrem Projekt-Dashboard und klicken Sie auf den Abschnitt Trigger und dann auf Add new trigger.

Step 4 - Wählen Sie im nächsten Bildschirm die Option VCS trigger, mit dem ein Trigger erstellt wird, sodass beim Einchecken in das Repository ein Build ausgelöst wird.

Step 5 - Klicken Sie auf Show Advanced Options und stellen Sie sicher, dass die im folgenden Screenshot gezeigten Optionen ausgewählt sind.

Step 6- Klicken Sie auf Speichern. Sie sehen nun den erfolgreich registrierten Trigger, wie im folgenden Screenshot gezeigt.

Step 7- Jetzt ist es Zeit, unseren Code in das Git-Repository einzuchecken und zu sehen, was passiert. Gehen wir also zu unserer Eingabeaufforderung und geben die ausgit add Befehl zum Bereitstellen unserer geänderten Dateien.

Step 8 - Jetzt die git commit Befehl, und es wird die Änderungen in das Git-Repository übertragen.

Step 9 - Wenn Sie jetzt zum Bildschirm "Projektübersicht" wechseln, wird jetzt ein neuer Build ausgelöst und ausgeführt.

Wenn Sie das sehen Change log Tab, du wirst das sehen git comment was den Build ausgelöst hat.

Versuchen wir es noch einmal. Nehmen wir eine weitere Änderung am vorDemo.aspxDatei. Lassen Sie uns agit add Befehl und a git commit Befehl mit der folgenden Festschreibungsnachricht.

Im Projekt-Dashboard von TeamCity wird nun automatisch ein Build ausgelöst.

Der Build zeigt eine Erfolgsmeldung an.

Sie sehen nun die Meldung 'Zweites Festschreiben', die verwendet wurde, als die Änderung an das festgeschrieben wurde git repository.

Wir haben jetzt den ersten Teil des kontinuierlichen Integrationsprozesses erfolgreich abgeschlossen.

Eine Build-Fehlerbenachrichtigung ist ein Ereignis, das ausgelöst wird, wenn ein Build fehlschlägt. Die Benachrichtigung wird an alle Schlüsselpersonen gesendet, wenn ein Build fehlschlägt. In einem solchen Fall ist es zunächst wichtig sicherzustellen, dass Zeit für den fehlgeschlagenen Build aufgewendet wird, um sicherzustellen, dass der Build bestanden wurde. Mit den folgenden Schritten wird sichergestellt, dass die Build-Benachrichtigungen in TeamCity eingerichtet werden.

Im Folgenden finden Sie die Schritte zum Einrichten von E-Mail-Benachrichtigungen in TeamCity.

Step 1- Gehen Sie in TeamCity zu Ihrem Projekt-Dashboard und klicken Sie oben rechts auf Administration. Sie sehen dann dieEmail NotifierLink auf der linken Seite. Klicken Sie auf diesen Link, um die allgemeinen Einstellungen für E-Mail aufzurufen.

Step 2 - Im nächsten Schritt geben Sie die Details eines gültigen ein SMTP Server. Google Mail bietet eine kostenlose SMTP-Funktion, die von jedem verwendet werden kann. So können wir diese Details im nächsten Bildschirm eingeben, der wie im folgenden Screenshot gezeigt angezeigt wird.

• SMTP-Host - smtp.gmail.com
• SMTP-Port Nr. - 465
• E-Mail-Nachrichten senden von und SMTP-Login - Dies sollte eine gültige Google Mail-ID sein
• SMTP-Passwort - Gültiges Passwort für diese Google Mail-ID
• Sichere Verbindung - Geben Sie dies als SSL ein

Step 3 - Klicken Sie auf Test ConnectionNur um sicherzustellen, dass die Einstellungen ordnungsgemäß funktionieren. Dann klickSave um die Einstellungen zu speichern.

Step 4- Der nächste Schritt besteht darin, Build-Benachrichtigungen für einen Benutzer zu aktivieren. Die erste Aufgabe besteht darin, einen Benutzer zu erstellen, der diese Build-Benachrichtigungen erhält. Gehen Sie zu Ihrem Projekt-Dashboard und wählen Sie dieUsers Option.

Step 5- Erstellen Sie einen neuen Benutzer. Geben Sie den gewünschten Benutzernamen und das Passwort ein. Klicken Sie dann auf die Schaltfläche Benutzer erstellen, die sich am unteren Bildschirmrand befindet.

Step 6 - Melden Sie sich jetzt mit dieser neuen Benutzer-ID und diesem neuen Kennwort beim TeamCity-System an.

Step 7- Nachdem Sie sich angemeldet haben, werden Ihnen die allgemeinen Einstellungen des Benutzers angezeigt. Klicken Sie im Abschnitt E-Mail-Benachrichtigung auf Bearbeiten.

Step 8 - Klicken Sie im nächsten Bildschirm auf Add new rule.

Step 9 - Wählen Sie unter Neue Regel hinzufügen die folgenden beiden Optionen aus und klicken Sie dann auf Speichern.

• Builds aus ausgewählten Projekten - Wählen Sie das Demo-Projekt.

• Aktivieren Sie das Kontrollkästchen für "Build schlägt fehl".

Wenn Sie diese beiden Optionen aktivieren, wird jetzt, wenn ein Build für das Demo-Projekt fehlschlägt, eine E-Mail-Benachrichtigung an den Benutzer gesendet. demouser.

Step 10- Lassen Sie uns nun einen falschen Build auslösen, um dies in Aktion zu sehen. Wechseln Sie in Visual Studio zudemo.aspx.cs Datei und fügen Sie eine falsche Codezeile hinzu.

Step 11 - Checken Sie nun den Code von Git ein, indem Sie a git add und git commit.

Jetzt im Projekt-Dashboard wird der Build automatisch ausgelöst und Sie werden sehen, dass der Build fehlgeschlagen wäre, wie im folgenden Screenshot gezeigt.

Wenn Sie sich bei der Google Mail-ID des anmelden demouser, wird tatsächlich eine Benachrichtigung über einen Build-Fehler angezeigt, wie im folgenden Screenshot gezeigt.

Einer der Schlüsselaspekte der kontinuierlichen Integration besteht immer darin, die Leistung der Builds zu überprüfen, wichtige Metriken zu erfassen, diese Ergebnisse zu dokumentieren und durch kontinuierliche Builds kontinuierliches Feedback zu generieren.

Was sind die Vorteile dieser Metriken?

• Not Committing Code Enough- Wenn Entwickler nicht häufig Code in ein Versionskontroll-Repository übertragen, kann dies an einer langsamen Integration liegen. Führen Sie eine allgemeine Analyse der Integrations-Build-Umgebung durch, um die Engpässe zu ermitteln, um die Build-Dauer zu verkürzen.

  Analysieren Sie anschließend die Ergebnisse und ermitteln Sie die am besten geeignete Verbesserung. Versuchen Sie dann, Änderungen am Erstellungsprozess vorzunehmen, um die Erstellungsdauer zu verkürzen. Zuletzt bewerten Sie die Erstellungsdauer neu, um festzustellen, ob weitere Verbesserungen erforderlich sind.

• Improve Test Performance- Selbst in einem gut funktionierenden CI-System wird ein Großteil der Integrationserstellungszeit durch die Durchführung automatisierter Tests in Anspruch genommen. Durch die Bewertung und Verbesserung der Leistung dieser Tests kann die Erstellungsdauer erheblich verkürzt werden.

• Infrastructure Issues- Möglicherweise stellen Sie fest, dass Integrations-Builds aufgrund der Systeminfrastruktur langsam sind. Möglicherweise ist die Netzwerkleistung langsam oder es besteht eine langsame virtuelle private Netzwerkverbindung.

  Geografisch verteilte Systeme und unzuverlässige Hardware oder Software können ebenfalls zu Leistungsproblemen führen. Untersuchen und verbessern Sie alle Infrastrukturressourcen, um die Erstellungsdauer zu verkürzen.

Metriken

Im Folgenden sind einige der Metriken aufgeführt, die auf einem Continuous Integration-Server verfügbar sind.

Schauen wir uns an, was TeamCity zu bieten hat -

Eine der einfachsten Formen von Metriken ist die im Projekt-Dashboard verfügbare. Das Schlüsselelement hierbei ist, die Dauer jedes Builds zu notieren. Wenn die Dauer jedes Builds überproportional zum zu erstellenden Code zunimmt, kann dies ein Problem sein. Dies ist also eine Rückmeldung, die entgegengenommen werden kann. Die Ursache hierfür könnte sein, dass der CI-Server nur noch wenige Ressourcen enthält und möglicherweise die Kapazität des Servers erhöht werden muss.

TeamCity kann feststellen, ob der CI-Server tatsächlich Probleme mit der Infrastruktur hat. In demadmin dashboard In TeamCity kann man auf klicken Disk Usage um zu sehen, wie viel Speicherplatz von jedem Build belegt wird.

Wenn weitere Details erforderlich sind, hat TeamCity die diagnostics button, die mehr Informationen über die geben kann CPU and Memory wird vom CI-Server verwendet.

Detailansicht der Build-Metriken

Wenn Sie eine detaillierte Ansicht der Builds eines bestimmten Projekts im Laufe der Zeit sehen möchten, ist diese als Teil der Projektbuilds verfügbar. Wechseln Sie im Projekt-Build-Bildschirm zum Statistik-Bildschirm. Daraufhin werden verschiedene Statistiken und Diagramme zur Leistung des Builds angezeigt.

Eines der Hauptmerkmale der kontinuierlichen Integration ist es, sicherzustellen, dass die on-going testingEnthält den gesamten Code, der vom CI-Server erstellt wird. Nachdem ein Build vom CI-Server ausgeführt wurde, muss sichergestellt werden, dass die Testfälle vorhanden sind, damit der erforderliche Code getestet werden kann. Jeder CI-Server kann Unit-Testfälle als Teil des ausführenCI suite. Im.Netist der Unit-Test eine Funktion, die in die integriert ist .Net framework Das Gleiche kann auch in den CI-Server integriert werden.

In diesem Kapitel erfahren Sie, wie Sie einen Testfall in definieren können .NetLassen Sie dann unseren TeamCity-Server diesen Testfall ausführen, nachdem der Build abgeschlossen ist. Dazu müssen wir zunächst sicherstellen, dass für unser Beispielprojekt ein Komponententest definiert ist.

Dazu müssen wir die folgenden Schritte mit äußerster Sorgfalt befolgen.

Step 1- Fügen wir unserer Lösung eine neue Klasse hinzu, die in unserem Unit Test verwendet wird. Diese Klasse hat eine Namensvariable, die die Zeichenfolge "Continuous Integration" enthält. Diese Zeichenfolge wird auf der Webseite angezeigt. Klicken Sie mit der rechten Maustaste auf das einfache Projekt und wählen Sie die MenüoptionAdd → Class.

Step 2 - Geben Sie der Klasse einen Namen als Tutorial.cs und klicken Sie unten auf dem Bildschirm auf die Schaltfläche Hinzufügen.

Step 3- Öffnen Sie die Datei Tutorial.cs und fügen Sie den folgenden Code hinzu. Dieser Code erstellt nur eine Zeichenfolge mit dem NamenName, und weisen Sie im Konstruktor den Namen einem Zeichenfolgenwert als zu Continuous Integration.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      public Tutorial() {
         Name = "Continuous Integration";
      }
   }
}

Step 4 - Lassen Sie uns die Änderung an unserem vornehmen Demo.aspx.csDatei, um diese neue Klasse zu verwenden. Aktualisieren Sie den Code in dieser Datei mit dem folgenden Code. Dieser Code erstellt nun eine neue Instanz der oben erstellten Klasse.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      protected void Page_Load(object sender, EventArgs e) {
         tp.Name = "Continuous Integration";
      }
   }
}

Step 5 - In unserer demo.aspx Datei, lassen Sie uns jetzt auf die verweisen tp.Name Variable, die in der erstellt wurde aspx.cs Datei.

<%@ Page Language = "C#" AutoEventWireup = "true" 
   CodeBehind = "Demo.aspx.cs" Inherits = "Simple.Demo" %>
<!DOCTYPE html>
<html xmlns = "http://www.w3.org/1999/xhtml">
   
   <head runat = "server">
      <title>TutorialsPoint1</title>
   </head>
   
   <body>
      <form id = "form1" runat = "server">
         <div>
            <% = tp.Name%>)
         </div>
      </form>
   </body>
   
</html>

Um sicherzustellen, dass unser Code mit diesen Änderungen einwandfrei funktioniert, können Sie den Code in Visual Studio ausführen. Sie sollten die folgende Ausgabe erhalten, sobald die Kompilierung abgeschlossen ist.

Step 6- Jetzt ist es Zeit, unsere Unit-Tests zum Projekt hinzuzufügen. Klicken Sie mit der rechten Maustaste aufSolution und wählen Sie die Menüoption Add → New Project.

Step 7 - Navigieren Sie zu Test und auf der rechten Seite wählen Unit Test Project. Geben Sie einen Namen alsDemoTest Klicken Sie dann auf OK.

Step 8 - In deinem Demo Test projectmüssen Sie einen Verweis auf das Simple-Projekt und auf das Notwendige hinzufügen testing assemblies. Klicken Sie mit der rechten Maustaste auf das Projekt und wählen Sie die MenüoptionAdd Reference.

Step 9 - Gehen Sie im nächsten Bildschirm zu Projekte und wählen Sie Simple Reference und klicken Sie auf OK.

Step 10 - Klicken Sie auf Add Reference Gehen Sie erneut zu Baugruppen und geben Sie ein Webim Suchfeld. Fügen Sie dann eine Referenz von hinzuSystem.Web.

Step 11 - In der Unit Test fileFügen Sie den folgenden Code hinzu. Dieser Code stellt sicher, dass die Tutorial-Klasse eine Zeichenfolgennamensvariable hat. Es wird auch die Tatsache bestätigt, dass der Name einem Wert von "Continuous Integration" entsprechen sollte. Dies wird unser einfacher Testfall sein.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;

namespace DemoTest {
   [TestClass]
   public class UnitTest1 {
      [TestMethod]
      public void TestMethod1() {
         Tutorial tp = new Tutorial();
         Assert.AreEqual(tp.Name, "Continuous Integration");
      }
   }
}

Step 12- Lassen Sie uns nun unseren Test in Visual Studio ausführen, um sicherzustellen, dass er funktioniert. Wählen Sie in Visual Studio die MenüoptionTest → Run → All Tests.

Nach dem Ausführen des Tests wird der Test auf der linken Seite von Visual Studio erfolgreich ausgeführt.

Kontinuierliches Testen in TeamCity aktivieren - Nachdem alle Testfälle vorhanden sind, ist es an der Zeit, diese in unseren Team City-Server zu integrieren.

Step 13- Dazu müssen wir in unserer Projektkonfiguration einen Build-Schritt erstellen. Gehen Sie zu Ihrem Projekthaus und klicken Sie auf Konfigurationseinstellungen bearbeiten.

step 14 - Gehen Sie dann zu Build-Schritt → MS Build und klicken Sie auf Build-Schritt hinzufügen, wie im folgenden Screenshot dargestellt.

Fügen Sie im nächsten Bildschirm die folgenden Werte hinzu:

• Wählen Sie den Runner-Typ als Visual Studio-Tests.

• Geben Sie einen optionalen Testschrittnamen ein.

• Wählen Sie den Test Engine-Typ als VSTest.

• Wählen Sie die Test Engine-Version als VSTest2013.

• Geben Sie im Namen der Testdateien den Speicherort als an DemoTest\bin\Debug\DemoTest.dll - Erinnere dich daran DemoTestist der Name unseres Projekts, das unsere Unit Tests enthält. DasDemoTest.dll wird durch unseren ersten Build-Schritt generiert.

• Klicken Sie auf Speichern. Dies wird am Ende des Bildschirms angezeigt.

Jetzt haben Sie 2 Erstellungsschritte für Ihr Projekt. Der erste ist der Build-Schritt, mit dem Sie Ihren Anwendungscode und Ihr Testprojekt erstellen. Und der nächste wird verwendet, um Ihre Testfälle auszuführen.

Step 15- Jetzt ist es Zeit, Ihren gesamten Code in Git einzuchecken, damit der gesamte Erstellungsprozess ausgelöst werden kann. Der einzige Unterschied ist, dass Sie diesmal das ausführen müssengit add und git commit Befehl von der Demo parent folder wie im folgenden Screenshot gezeigt.

Wenn der Build ausgelöst wird, wird eine erste Ausgabe angezeigt, die besagt, dass der Test bestanden wurde.

Step 16 - Wenn Sie auf das Ergebnis Test bestanden klicken und zur Registerkarte Test wechseln, sehen Sie nun, dass UnitTest1 ausgeführt wurde und bestanden wurde.

Kontinuierliche Inspektion ist der Prozess einer automatisierten Codeüberprüfung der Inspektion Ihres Codes, bevor die eigentlichen Tests ausgeführt werden. Es gibt subtile Unterschiede zwischen Inspektions- und Testsoftware. Das Testen ist dynamisch und führt die Software aus, um die Funktionalität zu testen. Die Inspektion analysiert den Code anhand einer Reihe vordefinierter Regeln.

Inspektoren (oder statische und dynamische Analysewerkzeuge) richten sich nach festgelegten Standards, die die Teams einhalten sollten (normalerweise Codierungs- oder Entwurfsmetriken). Beispiele für Inspektionsziele sind das Codieren von „Grammatik“ -Standards, das Einhalten von Architekturschichten, das Duplizieren von Code und viele andere.

Kontinuierliche Inspektion verkürzt die Zeit zwischen einer Ermittlung und einer Korrektur. Es stehen eine Reihe von Tools für die kontinuierliche Inspektion zur Verfügung. Für dieses Beispiel werden wir verwendenNCover 3.xDas hat eine Integration mit TeamCity. Mal sehen, wie wir eine kontinuierliche Inspektion durchführen können und was sie für uns tun kann.

Laden Sie NCover herunter und installieren Sie es

NCover ist ein separates Produkt, das heruntergeladen und installiert werden muss. Um NCover herunterzuladen, klicken Sie bitte auf den folgenden Link und laden Sie das 32-Bit-Installationsprogramm herunter -http://www.ncover.com/info/download.

Führen Sie das heruntergeladene Installationsprogramm aus und klicken Sie nach dem Start des Installationsprogramms auf Weiter.

Akzeptieren Sie die Lizenzvereinbarung und klicken Sie dann auf Weiter.

Akzeptieren Sie die Standardkomponenten und klicken Sie auf Weiter.

Klicken Sie auf die Schaltfläche Installieren, um die Installation zu starten.

Klicken Sie auf die Schaltfläche Fertig stellen, um die Installation abzuschließen.

Starten Sie die NCover-Installation zum ersten Mal, indem Sie auf gehen C:\Program Files (x86)\NCover\ NCover.Explorer.exe. Sie müssen lediglich zum ersten Mal einen Testschlüssel installieren, was ein unkomplizierter Vorgang ist.

Konfigurieren Sie das Projekt in TeamCity für die Verwendung von NCover

Step 1 - Gehen Sie zum Startbildschirm Ihres Projekts und klicken Sie auf Konfigurationseinstellungen bearbeiten.

Step 2 - Gehen Sie zu Build Steps und klicken Sie auf Bearbeiten TestStep. Die kontinuierliche Inspektion muss zusammen mit den definierten Unit-Tests durchgeführt werden.

Step 3 - Klicken Sie im Abschnitt .Net Coverage auf .Net Coverage Tool. Und dann wählen Sie die folgenden Einstellungen.

• Wählen Sie das .Net Coverage-Tool als NCover (3.x).
• Plattform als x86
• Version als v4.0
• Pfad zu NCover als C: \ Programme (x86) \ NCover
• Lassen Sie die anderen Einstellungen unverändert

Step 4 - Klicken Sie auf Speichern.

Step 5 - Gehen Sie nun zum Hauptbildschirm Ihres Projekts und klicken Sie auf Ausführen.

Step 6- Klicken Sie nach dem Ausführen des Builds auf den Test bestanden. Sie sehen nun einen Code Coverage-Bildschirm und viele Metrikindikatoren.

Step 7 - Sie können jetzt auf die Registerkarte Code Coverage klicken, um weitere Informationen zur Code-Analyse zu erhalten.

Step 8 - Klicken Sie auf fullcoveragereport.html. Sie erhalten nun einen umfassenden Bericht über die für das.Net code.

Bei der kontinuierlichen Datenbankintegration werden Ihre Datenbank und Testdaten jedes Mal neu erstellt, wenn eine Änderung am Versionskontroll-Repository eines Projekts vorgenommen wird.

In der Datenbankintegration werden im Allgemeinen alle Artefakte im Zusammenhang mit der Datenbankintegration -

• Sollte sich in einem Versionskontrollsystem befinden.
• Kann auf Genauigkeit getestet und auf Einhaltung der Richtlinien überprüft werden.
• Kann mit Ihren Build-Skripten generiert werden.

Aktivitäten, die an der kontinuierlichen Datenbankintegration beteiligt sein können, können eine der folgenden sein:

Drop a Database - Löschen Sie die Datenbank und entfernen Sie die zugehörigen Daten, damit Sie eine neue Datenbank mit demselben Namen erstellen können

Create a new Database - Erstellen Sie eine neue Datenbank mit Data Definition Language (DDL).

Insert the Initial Data - Fügen Sie alle Anfangsdaten (z. B. Nachschlagetabellen) ein, die Ihr System bei Lieferung voraussichtlich enthalten wird.

Migrate Database and Data - Migrieren Sie das Datenbankschema und die Daten regelmäßig (wenn Sie ein System basierend auf einer vorhandenen Datenbank erstellen).

Modify Column Attributes - Ändern Sie Tabellenspaltenattribute und -einschränkungen basierend auf Anforderungen und Refactoring.

Modify Test Data - Ändern Sie die Testdaten nach Bedarf für mehrere Umgebungen.

In unserem Beispiel für eine kontinuierliche Datenbank führen wir die folgenden Schritte aus:

• Wir werden eine MS SQL Server-Datenbank und eine entsprechende Tabelle erstellen.

• Wir werden ein Skript aus SQL Server Management Studio erstellen. Dieses Datenbankskript wird verwendet, um unsere Tabelle in der Datenbank einzurichten.

• Wir werden einen Code in unser ASP.Net-Projekt schreiben, um auf diese Datenbank zuzugreifen.

• Wir werden in unserem Projekt in TeamCity einen Schritt erstellen, um dieses Skript auszuführen.

• Wir werden unser Skript in Git einchecken.

Schritte dazu in der AWS-Datenbank, die in einem früheren Abschnitt erstellt wurde.

Step 1- Erstellen Sie eine MS SQL Server-Datenbank und eine entsprechende Tabelle. Öffnen Sie SQL Server Management Studio und erstellen Sie eine einfache Datenbank und Tabelle. Klicken Sie mit der rechten Maustaste auf Datenbanken und klicken Sie aufNew Database.

Step 2 - Nennen Sie es als Demodb und klicken Sie auf OK

Step 3 - Klicken Sie in der neuen Datenbank mit der rechten Maustaste und erstellen Sie eine neue Tabelle.

Step 4 - Sie können der Tabelle die gewünschten Spalten hinzufügen.

Step 5 - Speichern Sie die Tabelle und benennen Sie sie als Demotb.

Step 6 - Klicken Sie nun mit der rechten Maustaste auf die Tabelle und wählen Sie die Menüoption Script Table as → Drop and Create to → File.

Step 7 - Speichern Sie die Datei im Demo-Projektordner als Sample.sql.

So würde das Datenbankskript aussehen. Es würde zuerst eine vorhandene Tabelle löschen, falls vorhanden, und dann die Tabelle neu erstellen.

USE [Demodb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******

DROP TABLE [dbo].[Demotb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Demotb](
   [TutorialName] [nvarchar](max) NULL,
   [TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

Step 8 - Jetzt lasst uns schnell unsere ändern ASP.Net code auf die neue Datenbank verweisen.

Step 9 - In der Tutorial.cs Datei in Ihrem Demo projectFügen Sie die folgenden Codezeilen hinzu. Diese Codezeilen stellen eine Verbindung zu Ihrer Datenbank her, nehmen die Serverversion und speichern den Versionsnamen in der Variablen Name. Wir können diese Namensvariable in unserem anzeigenDemo.aspx.cs Datei durch eine Response.write Befehl.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      
      public Tutorial() {
         string connectionString = "Data Source = WIN-50GP30FGO75;
         Initial Catalog = Demodb;
         Integrated Security = true;";
         
         using (SqlConnection connection = new SqlConnection()) {
            connection.ConnectionString = connectionString;
            connection.Open();
            Name = connection.ServerVersion;
            connection.Close();
         }
      }
   }
}

Step 10 - Fügen Sie dem folgenden Code hinzu Demo.aspx.cs Datei, um sicherzustellen, dass die SQL Server-Version angezeigt wird.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      
      protected void Page_Load(object sender, EventArgs e){
         Response.Write(tp.Name);
      }
   }
}

Wenn wir nun den Code ausführen, erhalten Sie die folgende Ausgabe im Browser.

Step 11- Fügen wir nun unseren Schritt in TeamCity hinzu, der das Datenbankskript aufruft. Gehen Sie zu Ihrem Projekt-Dashboard und klicken Sie aufEdit Configuration Settings.

Step 12 - Gehen Sie zu Build Steps und klicken Sie auf Add build step.

Wählen Sie die folgenden Optionen (Beachten Sie, dass der MS SQL Server-Client auf dem CI-Server installiert sein sollte).

• Der Läufertyp sollte die Befehlszeile sein.

• Geben Sie einen optionalen Schrittnamen an.

• Run sollte mit Parametern ausführbar sein.

• Befehl ausführbare Datei sollte sein C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe

• Befehlsparameter sollten sein -S WIN-50GP30FGO75 -i Sample.sql. Wobei –S den Namen der SQL Server-Instanz angibt.

Step 13 - Klicken Sie auf Speichern.

Was nun sichergestellt werden muss, ist die Baureihenfolge. Sie müssen sicherstellen, dass die Erstellungsreihenfolge wie folgt lautet.

Step 14 - Sie können die Erstellungsreihenfolge ändern, indem Sie die Option zum Neuordnen der Erstellungsschritte auswählen.

• Das Datenbank-Setup sollte an erster Stelle stehen. Dies wird also verwendet, um Ihre Datenbank aus dem frischen Zustand neu zu erstellen.

• Als nächstes wird Ihre Anwendung erstellt.

• Endlich dein Testaufbau.

Step 15 - Führen Sie jetzt die git add und git commit Befehl, damit die Sample.sqlDatei wird in Git eingecheckt. Dies löst automatisch einen Build aus. Und dieser Build sollte bestehen bleiben.

Sie haben jetzt einen vollwertigen Erstellungszyklus mit einem kontinuierlichen Aspekt der Datenbankintegration in Ihrem Zyklus. Lassen Sie uns im nächsten Abschnitt weiter gehen und uns die kontinuierliche Bereitstellung ansehen.

Nachdem Sie dies mit einem lokalen SQL Server getan haben, können wir die gleichen Schritte für a wiederholen AWS MS SQLServer, der in einem der vorherigen Abschnitte erstellt wurde. Um eine Verbindung zu einem Microsoft SQL Server herzustellen, müssen Sie eine Verbindung über die folgende Konvention herstellen.

Step 16- Sehen Sie zuerst, wie Ihre Datenbankinstanz in AWS benannt ist. Wenn Sie sich bei AWS anmelden, wechseln Sie zum Abschnitt RDS unter dem Abschnitt Datenbank.

Step 17 - Klicken Sie im nächsten Bildschirm auf DB-Instanzen.

step 18- Klicken Sie auf Ihre Datenbank und notieren Sie sich den Endpunkt. Im folgenden Screenshot ist esdemodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433

Step 19 - Jetzt verbinden mit der Datenbank von SQL Server Management Studiomüssen Sie die Verbindung als angeben demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com,1433 (Beachten Sie das Komma zwischen Instanzname und Portnummer).

Der folgende Screenshot zeigt eine erfolgreiche Verbindung zur Datenbank.

Dann können Sie dieselben Schritte wiederholen. DasSqlcmd command wird wie folgt sein -

Dieser Befehl kann im Schritt zum Erstellen der Datenbank in TeamCity ersetzt werden. Wenn Sie das ausführensqlcmd commandwird die Tabelle automatisch in Ihrer SQL Server-Datenbank in AWS erstellt.

Automatisierte Builds und wiederholbare Builds. Automatisierte Tests und wiederholbare Tests. Testkategorien und Testfrequenzen. Kontinuierliche Inspektionen. Kontinuierliche Datenbankintegration. Diese Reihe von Aufgaben bei der Erstellung einer effektiven CI-Umgebung ermöglicht in erster Linie einen entscheidenden Vorteil: die Freigabe funktionierender Software zu jedem Zeitpunkt und in jeder Umgebung.

In unseren vorherigen Kapiteln haben wir alle folgenden Segmente ausgeführt:

• Erstellt unseren Code.
• Sicherstellung eines ordnungsgemäßen Builds in TeamCity.
• Erstellt einen Datenbankintegrationsprozess.
• Erfolgreiche Tests durchgeführt.

Jetzt müssen Sie nur noch eine automatisierte Bereitstellung durchführen, damit unser gesamter Prozess abgeschlossen ist.

Für eine automatisierte Bereitstellung in unserem Fall müssen wir die folgenden Schritte ausführen:

• Stellen Sie auf unserem Bereitstellungsserver sicher, dass IIS installiert ist.

• Stellen Sie sicher, dass der IIS-Benutzer Zugriff auf unsere Datenbank erhält.

• Erstellen Sie ein Veröffentlichungsprofil, mit dem die Site beim Erstellen veröffentlicht wird.

• Stellen Sie sicher, dass wir unseren MSBuild-Befehl ändern, um eine automatische Bereitstellung durchzuführen.

• Automatisieren Sie TeamCity, um eine automatische Veröffentlichung durchzuführen.

• Mach a git commit um sicherzustellen, dass alle Ihre Dateien in Git sind.

Step 1- Konfigurieren Sie einen lokalen IIS-Server. Wenn Sie über einen lokalen oder Remote-IIS-Server verfügen, kann die folgende Konfiguration ausgeführt werden, um unsere Anwendung bereitzustellen. Es ist immer eine gute Praxis zu prüfen, ob eine Bereitstellung manuell durchgeführt werden kann, bevor sie automatisiert durchgeführt wird.

Step 2 - Wechseln Sie auf einem Windows 2012-Server zu Ihrem Server-Manager und klicken Sie auf Rollen und Funktionen hinzufügen.

Step 3 - Klicken Sie im folgenden Bildschirm auf Weiter.

Step 4 - Wählen Sie im nächsten Bildschirm eine rollenbasierte oder funktionsbasierte Installation und klicken Sie auf Weiter.

Step 5 - Wählen Sie den Standardserver aus und klicken Sie auf Weiter.

Step 6 - Wählen Sie die Webserverrolle und klicken Sie auf Weiter.

Step 7 - Klicken Sie im nächsten Bildschirm auf Weiter.

Step 8 - Klicken Sie im folgenden Bildschirm erneut auf Weiter.

Step 9 - Klicken Sie im nächsten Bildschirm auf Weiter.

Step 10 - Im letzten Bildschirm können Sie auf die Schaltfläche Installieren klicken, um den IIS zu installieren.

Sobald Sie IIS installiert haben, können Sie es öffnen, indem Sie die Internetinformationsdienste öffnen.

Step 11 - Klicken Sie auf Anwendungspools. Sie sehen einen Pool mit dem Namen DefaultAppPool. Dies muss im nächsten Schritt Zugriff auf SQL Server haben.

Step 12 - Wenn wir eine ASP.Net-Anwendung mit einer MS SQL Server-Anwendung verbinden müssen, müssen wir der SQL Server-Instanz Zugriff auf den Standardanwendungspool gewähren, damit sie eine Verbindung zu unserer herstellen kann Demodb Datenbank.

Step 13- Öffnen Sie SQL Server Management Studio. Gehen Sie zu Anmeldungen, klicken Sie mit der rechten Maustaste und wählen Sie die MenüoptionNew Login.

Aktualisieren Sie im nächsten Bildschirm die folgenden Parameter und klicken Sie auf OK.

• Anmeldename als IIS APPPOOL \ DefaultAppPool.
• Standarddatenbank - Dies sollte unsere Datenbank sein, die demodb ist.

Step 14 - Erstellen eines Publish Profile. Das Veröffentlichungsprofil wird in Visual Studio verwendet, um ein Bereitstellungspaket zu erstellen, das dann mit MS Build und in jedem CI-Server entsprechend verwendet werden kann. Klicken Sie dazu in Visual Studio mit der rechten Maustaste auf das Projekt und klicken Sie auf die Menüoption Veröffentlichen

Step 15 - Wählen Sie im nächsten Bildschirm ein neues Veröffentlichungsprofil aus und geben Sie ihm einen Namen. - DemoDeployment. Klicken Sie dann auf die Schaltfläche Weiter.

Fügen Sie im folgenden Bildschirm die folgenden Werte hinzu:

• Wählen Sie die Veröffentlichungsmethode als Webbereitstellung.
• Geben Sie den Server als localhost ein.
• Geben Sie den Site-Namen als Standard-Website / Demo ein.
• Geben Sie die Ziel-URL als ein http://localhost/Demo

Klicken Sie dann auf die Schaltfläche Weiter.

Step 16 - Klicken Sie im nächsten Bildschirm auf Weiter.

Step 17 - Klicken Sie im letzten Bildschirm auf die Schaltfläche Veröffentlichen.

Nun, wenn Sie zum gehen C:\Demo\Simple\Properties\PublishProfiles Ort Ihres Projekts, sehen Sie eine neue publish profile xml fileerstellt. Diese Veröffentlichungsprofildatei enthält alle Details, die zum Veröffentlichen Ihrer Anwendung auf dem lokalen IIS-Server erforderlich sind.

Step 18- Jetzt passen wir unseren MSBuild-Befehl an und verwenden das obige Veröffentlichungsprofil, um zu sehen, was passiert. In unserem MSBuild-Befehl geben wir die folgenden Parameter an:

• Deploy on Build ist wahr - dies löst eine automatische Bereitstellung aus, sobald ein erfolgreicher Build abgeschlossen ist.

• Wir erwähnen dann die Verwendung des Veröffentlichungsprofils, das im obigen Schritt verwendet wurde.

• Die Visual Studio-Version ist nur gegenüber der MSBuild-Bereitstellungsfunktion für die verwendete Version von Visual Studio zu erwähnen.

Wenn Sie den obigen Befehl ausführen, löst MSBuild einen Erstellungs- und Bereitstellungsprozess aus. Was Sie feststellen werden, ist die Bereitstellung für unsereDefault Website in unserem IIS-Server.

Nun, wenn wir zur Website navigieren - http://localhost/Demo/Demo.aspx Die folgende Ausgabe wird angezeigt. Dies bedeutet, dass MSBuild eine erfolgreiche Bereitstellung auf unserer Website durchgeführt hat.

Step 19 - Automatisierung über TeamCity - Jetzt ist es an der Zeit, unserem TeamCity-Server eine Aufgabe hinzuzufügen, um MSBuild automatisch zum Bereitstellen unserer Anwendung zu verwenden, basierend auf den oben genannten Schritten.

Step 20 - Gehen Sie zu Ihrem Projekt-Dashboard und klicken Sie auf Edit Configuration Settings.

Step 21 - Gehen Sie zu Build-Schritte und klicken Sie auf Build-Schritt hinzufügen.

Wählen Sie die folgenden Optionen -

• Der Läufertyp sollte MSBuild sein

• Geben Sie einen optionalen Schrittnamen an

• Geben Sie den Erstellungspfad als Simple / Simple.csproj ein

• Behalten Sie die MSBuild-Version als Microsoft Build Tools 2013 bei

• Behalten Sie die MSBuild Toolsversion als 12.0 bei

• Geben Sie die Befehlszeile als / p: DeployOnBuild = true / p: PublishProfile = DemoDeployement / p: VisualStudioVersion = 12.0 ein

Step 22 - Klicken Sie auf Speichern.

Stellen Sie sicher, dass in den Erstellungsschritten der Schritt Bereitstellen der letzte Schritt in der Kette ist.

Step 23 - Jetzt machen wir ein Finale git commit, um sicherzustellen, dass alle Dateien in Git sind und von TeamCity verwendet werden können.

Herzlichen Glückwunsch, Sie haben erfolgreich einen vollständigen kontinuierlichen Integrationszyklus für Ihre Anwendung eingerichtet, der jederzeit ausgeführt werden kann.

Lassen Sie uns einen abschließenden Überblick über die Best Practices der kontinuierlichen Integration geben, basierend auf all den Lektionen, die wir bisher gelernt haben -

• Maintain a code repository- Dies ist der grundlegendste Schritt. In all unseren Beispielen wird alles in einem Git-Repository verwaltet, von der Codebasis über die Veröffentlichungsprofile bis hin zu den Datenbankskripten. Es muss immer sichergestellt sein, dass alles im Code-Repository gespeichert ist.

• Automate the build- Wir haben gesehen, wie MSBuild verwendet wird, um einen Build zusammen mit einem Veröffentlichungsprofil zu automatisieren. Dies ist erneut ein wichtiger Schritt im kontinuierlichen Integrationsprozess.

• Make the build self-testing - Stellen Sie sicher, dass Sie den Build testen können, indem Sie Unit-Testfälle an Ort und Stelle halten. Diese Testfälle sollten so sein, dass sie vom Continuous Integration-Server ausgeführt werden können.

• Everyone commits to the baseline every day- Dies ist ein Schlüsselprinzip der kontinuierlichen Integration. Es macht keinen Sinn, bis zum Ende des gesamten Prozesses zu bleiben, um zu sehen, wer den Build bricht.

• Every commit (to baseline) should be built- Jedes Commit für die Anwendung muss erfolgreich erstellt werden. Wenn der Build aus irgendeinem Grund fehlschlägt, muss der Code geändert werden, um sicherzustellen, dass der Build erfolgreich ist.

• Keep the build fast- Wenn der Build langsam ist, weist dies auf ein Problem im gesamten Prozess der kontinuierlichen Integration hin. Stellen Sie sicher, dass die Builds immer auf eine Dauer begrenzt sind, vorzugsweise nie länger als 10 Minuten.

• Everyone can see the results of the latest build- Das TeamCity-Dashboard bietet jedem einen Überblick über alle Builds, die entweder bestanden oder fehlgeschlagen sind. Dies gibt allen Personen, die am kontinuierlichen Integrationsprozess beteiligt sind, einen guten Einblick.