tools - Welche Toolchains existieren für die Continuous Integration mit C++?




open source deployment server (4)

Visual Build Professional ist mein Lieblingswerkzeug, um alle anderen Tools zusammen zu ziehen. Natürlich nur Windows, aber es integriert sich in alle Varianten von Visual Studio und eine Vielzahl von Test-Tools, Tools zur Quellcode-Kontrolle, Issue-Tracker usw. Es ist jedoch nur Windows. Ich weiß, das ist nicht der ganze Stapel, aber es ist ein Anfang.

Continuous Integration Toolchains für .NET, Java und andere Sprachen sind relativ gut definiert, aber der C ++ - Markt scheint eine große Vielfalt zu haben.

Unter CI "toolchain" verstehe ich insbesondere Tools für Build-Skripte, automatisiertes Testen, Coding-Standards, etc.

Was verwenden C ++ - Teams für CI-Toolchains?


Tag auch,

Wir hatten dieses Problem tatsächlich an einem Standort, an dem ich vorher schon Verträge hatte.

Ein Typ setzte sich und schrieb Werkzeuge, hauptsächlich Shell-Skripte, an

  1. Schau dir die aktuelle Codebasis jede Stunde oder so an und mach einen Build, um zu überprüfen, ob es kaputt ist, und
  2. Sehen Sie sich den neuesten guten Build an, erstellen Sie einen kompletten Build und führen Sie etwa 8.000 Regressionstests durch.

Wir konnten einfach nichts kommerziell finden, um dies zu tun und so setzte sich Charlie hin und schrieb dies in Bash-Shell-Skripten und es lief auf HP-UX.

Prost, Rob


Wie bei scheinbar jeder anderen Aufgabe in C ++ humple ich gerade mit kontinuierlicher Integration kaum hin. Mein Setup startet mit Eclipse. Ich habe es eingerichtet, um Make-Dateien für meine Projekte zu generieren. Ich habe ant-Skripte, die die gesamten Build-Aufgaben ausführen, indem Sie "make all" oder "make clean" auf den entsprechenden Makefiles ausführen. Diese ant-Skripte sind Teil meines Projekts, und ich muss sie aktualisieren, wenn ich dem System eine neue Build-Konfiguration oder ein neues Teil hinzufüge. Es ist aber nicht so schlimm.

Ich verwende CruiseControl, um die Builds tatsächlich auszuführen. Jedes Projekt (alle davon) besitzt ein eigenes Ameisen-Skript, das Build-spezifische Aufgaben ausführt (Artefakte kopieren, Ergebnisse verarbeiten) und in das Projekt-Ameisen-Skript aufruft, um das Gebäude zu bauen.

Ich musste cppunit für meine Tests verwenden und die Ergebnisse mit einer xslt Datei verarbeiten, die ich irgendwo gefunden habe. Ich habe auch das falsche SVN-Revisions-Label auf jedem Build, weil ich keinen passenden Svn-Labeler finden kann. Alles, was ich finden kann, ist halbfertiger, jahrelanger Code und Leute, die argumentieren, dass andere Leute es falsch machen.

Es sieht für mich so aus, als ob CC ein absterbendes System ist, aber ich habe nichts Besseres für C ++ gefunden. Andererseits habe ich auch das Gefühl, dass C ++ eine aussterbende Sprache ist, also ist es vielleicht größer als nur das.


Wir verwendeten SCONs für die kontinuierliche Integration, die von einem zentralen Build-Server ausgeführt wurde. Einige Projekte wurden zu Buildbot migriert.

Ich beschäftige mich jetzt mit Rake und betrachte Lösungen wie in diesem Blog beschrieben . Fowler erwähnt, dass ThoughtWorks in seinem Continuous Integration- Artikel gelegentlich Rake für das Build-Scripting verwendet.





continuous-integration