Kontinuierlicher Bauumgebung Empfehlungen für in erster Linie C ++; Greenhills Integrität

Question

Ich brauche Ihre Empfehlungen für die kontinuierlichen Build-Produkte für ein großes (1-2MLOC) Software-Entwicklungsprojekt. Eigenschaften:

• Clearcase zur Versionskontrolle
• ca. 80% C ++; 15% Java; 5% Skript oder Low-Level
• Kompiliert für Green Hills Integrität OS, sondern auch einige Fenster und JVM chunks
• Meistens ein Embedded-System; enthält auch einige UI Stücke und einige Entwicklungsunterstützung (Simulations-Tools, Konfigurationstools, etc ...)
• Jede fiktive "Version" der lieferbaren umfasst Einrichtungs-Images für eine Reihe von Platten, UI Maschinen, etc ... (~ 10 separate Bilder, 5 verschiedene Betriebssysteme)
• Need zu viele gleichzeitige Versionen pflegen / verfolgen, die, vor allem für eine Vielzahl von verschiedenen Board Support Packages gebaut werden
• Build-Zykluszeit ist ein wichtiges Thema für das Projekt, braucht Unterstützung für was auch immer bietet Hilfe Adresse dieses (meist brauchte eine große Farm von Build-Maschinen zu verwalten, ich denke, ..)
• betreibt in einer sicheren Umgebung (dies ist ein gov't Programm) ( Edited hinzufügen . Dies ist ein klassifiziertes Programm, das Outsourcing der Build-Infrastruktur ist ein Rohrkrepierer)

Sie interessieren sich für best Practices oder periphere Anleitung, die Sie anbieten könnten. Die Build-Automatisierung Probleme ist eine von mehreren überlappenden Best Practices, die auf dem Programm erscheinen zu fehlen, aber versuchen Sie Ihre Antworten auf Build-Infrastruktur Stück konzentriert zu halten und Beobachtungen in direktem Zusammenhang.

Die Kosten sind nicht das Fahren betreffen. Skalierbarkeit und einfache Umrüstung auf eine bestehende Infrastruktur sind der Schlüssel.

(Edited zu Adresse @ Dan Kommentar; -).

Answer 1

Aus meiner Erfahrung mit ähnlichen Systemen gibt es etwa zwei Teile für dieses Problem:

• Eine wiederholbare Methode für Quellen Check-out, den Aufbau der Software und testete es (wenn Sie als auch kontinuierliche Prüfung machen wollen als Gebäude), eine kleine Anzahl von Befehlszeilen Anrufungen verwendet wird.

• Ein Mittel, diese Befehlszeilen auf verschiedenen Servern in der Build-Farm aufrufen.

Für letztere haben wir mit gewesen BuildBot , das ist ziemlich gut zu funktionieren scheint.

Für die ersteren haben wir eine einheimische Lösung, dass als einen einfachen Bash-Shell-Skript gestartet und wuchs ... eher im Wesentlichen. Aus Erfahrung würde ich vorschlagen, in Python anfangen anstatt bash - Sie werden im Umgang mit Setup und die Konfiguration als in tatsächlich Aufruf Programme weit mehr Code ausgeben. (Außerdem ist es wahrscheinlich einfacher, es unter Windows laufen zu lassen, wenn Sie das tun.)

Die Dinge, die ich gefunden habe wirklich Schlüssel zu sein in unserem Skript Nützlichkeit sind:

• Ironclad Wiederholbarkeit. Wir haben einen Standardsatz von Build-Tools und Skripte beginnen von Umgebungsvariablen schrubben. Es gibt sehr wenige Befehlszeilenoptionen; alles geht in Konfigurationsdateien und diejenigen gehen in der Versionskontrolle.

• Protokollierung. Wir produzieren ein Protokoll jeder Befehl, dass die Build-Skript ausgeführt wird.

• Die Konfigurationsdatei Vererbung. Jede Variante unserer Software wird eine Konfigurationsdatei, und diese Dateien können auch mehr-allgemeine Einstellungen (darunter auch-mehr-allgemeine Einstellungen).

• Extensibility. Wenn wir eine neue Quelle-Komponente hinzufügen, es ist ziemlich einfach, eine Reihe von Anweisungen fügen für diese Komponente des Bau (und die Befehle können beliebiger bash-Code sein). Der „kann beliebigen Code sein“ Teil ist wahrscheinlich Schlüssel hier; keine Möglichkeit gibt, ein bereits bestehendes Produkt all die skurrilen Dinge in der Lage sein zu tun, dass Sie komplexe reale System.

für eine große brauchen

Sie können mit einem einigermaßen einfachen Skript beginnen und lassen Sie es organisch wachsen, wie die Notwendigkeit entsteht; ehrlich, obwohl wir ein bisschen chaotisch ist, denke ich, dass wir ein viel brauchbares Ergebnis auf diese Weise bekamen, als wir mit schwerem Top-Down-Design haben.

Answer 2

Die Kosten sind kein Objekt? Ich habe für Greenhills gearbeitet, und sie haben diese Probleme für ihre interne Build / Test Farmen gelöst. Bitten Sie sie, das gleiche für Sie zu tun.

Answer 3

Wenn ich sehe, Betonung auf Dinge wie Skalierbarkeit und Sicherheit in einem Build-System, fange ich an zu denken, dass Sie ein Kandidat für die Enterprise-Class-Build-Systeme / CI-Systeme sein könnten. Günstig, es klingt wie Sie sie auch leisten können. Ein Jahr alt SD Times zwischen den Unternehmen und Teamebene Build-Tool eine grundlegende Aufschlüsselung bietet.

Meine Firma macht AnthillPro und wir haben mit einer Reihe von Unternehmen auf großen Embedded-Projekte sowie gearbeitet hoch sichere Projekte. IBM ist wahrscheinlich die größten anderen Spieler in dem Raum mit Buildforge.

AnthillPro bringt etwas mehr Betonung auf das, was Sie tun, mit den Bildern in der Minuten / Stunden / Tage nach Build (installiere Sie sie auf Simulatoren / Hardware und automatisierte Tests durchführen? Bühne sie? Sie fördern?), Aber wir auch Leute sehen indem es nur zu bauen.