Wie richtet man einen Integrationstestserver am besten ein?

Question

Beim Einrichten eines Integrationsservers bin ich mir nicht sicher, ob es der beste Ansatz ist, mehrere Aufgaben zum Abschließen des Builds zu verwenden.Ist es der beste Weg, alles in nur einer großen Aufgabe zu erledigen oder kleine davon abhängig zu machen?

Answer 1

Sie möchten die Aufgaben auf jeden Fall aufteilen.Hier ist ein schönes Beispiel einer CruiseControl.NET-Konfiguration, die für jeden Schritt unterschiedliche Ziele (Aufgaben) hat.Es verwendet auch eine common.build-Datei, die mit wenigen Anpassungen von mehreren Projekten gemeinsam genutzt werden kann.

http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk

Answer 2

Ich verwende TeamCity mit einem Nant-Build-Skript.TeamCity erleichtert die Einrichtung des CI-Serverteils und das Nant-Build-Skript erleichtert die Durchführung einer Reihe von Aufgaben, was die Berichterstellung betrifft.

Hier ist ein Artikel, den ich über die Verwendung von CI mit CruiseControl.NET geschrieben habe. In den Kommentaren gibt es ein Nant-Build-Skript, das projektübergreifend wiederverwendet werden kann:

Kontinuierliche Integration mit CruiseControl

Answer 3

Der von mir bevorzugte Ansatz ist der folgende Aufbau (vorausgesetzt, Sie befinden sich in einem .NET-Projekt):

• CruiseControl.NET.
• NANT-Aufgaben für jeden einzelnen Schritt.Nant.Contrib für alternative CC-Vorlagen.
• NUnit zum Ausführen von Unit-Tests.
• NCover zur Durchführung der Codeabdeckung.
• FXCop für statische Analyseberichte.
• Subversion zur Quellcodeverwaltung.
• CCTray oder ähnliches auf allen Entwicklungsboxen, um Benachrichtigungen über Builds, Fehler usw. zu erhalten.

Bei vielen Projekten stellt man fest, dass es unterschiedliche Ebenen von Tests und Aktivitäten gibt, die stattfinden, wenn jemand einen Check-in durchführt.Manchmal können diese mit der Zeit so weit ansteigen, dass es nach einem Build lange dauern kann, bis ein Entwickler beim Einchecken erkennen kann, ob er den Build beschädigt hat.

In diesen Fällen erstelle ich drei Builds (oder vielleicht zwei):

• Ein CI-Build wird durch das Einchecken ausgelöst und führt einen sauberen SVN-Get, -Build und leichte Tests durch.Im Idealfall können Sie die Dauer auf Minuten oder weniger beschränken.
• Ein umfassenderer Build, der stündlich erfolgen könnte (bei Änderungen), der das Gleiche tut wie das CI, aber umfassendere und zeitaufwändigere Tests durchführt.
• Ein Overnight-Build, der alles erledigt und außerdem Code-Coverage und statische Analyse der Assemblys durchführt und alle Bereitstellungsschritte ausführt, um tägliche MSI-Pakete usw. zu erstellen.

Das Wichtigste an jedem CI-System ist, dass es organisch sein und ständig optimiert werden muss.Es gibt einige großartige Erweiterungen für CruiseControl.NET, die Build-Timings usw. für die Schritte protokollieren und grafisch darstellen und Ihnen ermöglichen, historische Analysen durchzuführen und so die Builds kontinuierlich zu optimieren, um sie schnell zu halten.Für Manager ist es schwer zu akzeptieren, dass eine Baukiste Sie wahrscheinlich ein Fünftel Ihrer Arbeitszeit beschäftigt, nur um zu verhindern, dass sie zum Stillstand kommt.

Answer 4

Wir gebrauchen Buildbot, wobei der Build in einzelne Schritte unterteilt ist.Es muss ein Gleichgewicht zwischen der Aufteilung der Build-Schritte mit ausreichender Granularität und der Bildung einer vollständigen Einheit gefunden werden.

In meiner jetzigen Position erstellen wir beispielsweise die Unterteile für jede unserer Plattformen (Mac, Linux, Windows) auf den jeweiligen Plattformen.Anschließend müssen wir sie in einem einzigen Schritt (mit einigen Unterschritten) zur endgültigen Version kompilieren, die in den endgültigen Distributionen landet.

Wenn bei einem dieser Schritte etwas schief geht, ist die Diagnose ziemlich einfach.

Mein Rat ist, die Schritte so vage wie möglich auf ein Whiteboard zu schreiben und dann Ihre Schritte darauf aufzubauen.In meinem Fall wäre das:

1. Erstellen Sie Plugin-Teile
   1. Kompilieren für Mac
   2. Für PC kompilieren
   3. Für Linux kompilieren
2. Erstellen Sie endgültige Plugins
3. Führen Sie Plugin-Tests durch
4. Erstellen Sie eine Zwischen-IDE (wir müssen den Bootstrap-Build durchführen)
5. Erstellen Sie die endgültige IDE
6. Führen Sie IDE-Tests durch

Answer 5

Ich würde die Jobs auf jeden Fall aufschlüsseln.Die Chancen stehen gut, dass Sie Änderungen an den Builds vornehmen werden, und es ist einfacher, Probleme aufzuspüren, wenn Sie kleinere Aufgaben haben, anstatt einen monolithischen Build zu durchsuchen.

Sie sollten auf jeden Fall in der Lage sein, aus den kleineren Teilen ein großes Projekt zu erstellen.

Answer 6

Tag auch,

Wenn Sie über Integrationstests sprechen, wäre mein großer (offensichtlicher) Tipp, den Testserver so nah wie möglich an der Bereitstellungsumgebung zu erstellen und zu konfigurieren.

</thebloodyobvious> (-:

Prost, Rob

Answer 7

Teilen Sie Ihre Aufgaben in einzelne Ziele/Vorgänge auf und verwenden Sie dann ein übergeordnetes Skript, um sie alle angemessen miteinander zu verknüpfen.

Dadurch wird Ihr Build-Prozess für andere leichter verständlich (Sie dokumentieren ihn, sodass jeder in Ihrem Team ihn nachvollziehen kann, nicht wahr?), und das Potenzial für eine Wiederverwendung wird erhöht.Wahrscheinlich werden Sie die High-Level-Skripte nicht wiederverwenden (obwohl dies möglich sein könnte, wenn Sie ähnliche Projekte haben), aber Sie können die diskreten Vorgänge auf jeden Fall ziemlich einfach wiederverwenden (auch wenn es sich um Kopieren/Einfügen handelt).

Betrachten Sie das Beispiel des Abrufens der neuesten Quelle aus Ihrem Repository.Sie möchten die Aufgaben/Vorgänge zum Abrufen des Codes mit einigen Protokollierungsanweisungen gruppieren und auf die entsprechenden Kontoinformationen verweisen.So etwas lässt sich sehr einfach von einem Projekt zum nächsten wiederverwenden.

Für die Umgebung meines Teams verwenden wir NAnt, da es eine gemeinsame Skriptumgebung zwischen Entwicklungsmaschinen (auf denen wir die Skripte schreiben/debuggen) und dem CI-Server bereitstellt (da wir einfach dieselben Skripte in einer sauberen Umgebung ausführen).Wir verwenden Jenkins, um unsere Builds zu verwalten, aber im Kern ruft jedes Projekt nur die gleichen NAnt-Skripte auf und dann manipulieren wir die Ergebnisse (z. B. archivieren die Build-Ausgabe, kennzeichnen fehlgeschlagene Tests usw.).