Was ist der Zweck einer dedizierten Build-Maschine?

Aufgrund einer Reihe von Umständen, die zu einer schlechten Bereitstellung im letzten Build-Zyklus führten, habe ich in unserem Büro eine Kampagne durchgeführt, um alle zukünftigen Bereitstellungen mit einer dedizierten Build-Maschine durchzuführen, und mein Chef hat diesen Vorschlag angenommen.

Anstatt jedoch eine Maschine in unserem Büro in Betrieb zu nehmen, müssen wir uns eine Maschine mit mehreren anderen Gruppen teilen - und den Aufwand, mein Büro mit allen erforderlichen Informationen zu verlassen und dann eine Treppe hinunterzugehen Ich frage mich, warum ich das überhaupt vorgeschlagen habe, wenn ich nur einen einfachen Bau in ein anderes Büro verlegte.

Die Idee, eine separate Build-Maschine zu haben, bestand ursprünglich darin, meinen eigenen lokal geschriebenen Code vom Code mehrerer anderer Entwickler zu trennen und alle entführten Dateien, die ich auf meiner Maschine hatte, von der Bereitstellung zu trennen. Es sollte auch ein wachsendes Problem gelöst werden, das ich mit unserem ClearCase-Dateiverwaltungssystem hatte, das es mir oft verweigert, bestimmte Build-Aktivitäten bereitzustellen, es sei denn, ich habe auch eine andere Aktivität aufgenommen, für die es Abhängigkeiten gibt.

Da ich diesen Prozess nun tatsächlich fortsetze, frage ich mich, ob ich den gesamten Zweck der Verwendung einer Build-Maschine missverstanden habe - und da wir diese Maschine nur für die Code-Bereitstellung in unseren Test-, Staging- und Produktionsumgebungen verwenden und Ich bin mir nicht sicher, ob es für unsere persönlichen Developer-Testbereitstellungen überhaupt einen Zweck erfüllt.

Also, was ist der eigentliche Grund für die Verwendung einer Build-Maschine, und habe ich mich überhaupt der korrekten Verwendung angenähert?

Normalerweise verfügen Sie nicht nur über einen dedizierten Build-Computer, sondern führen auch einen Build-Server auf diesem dedizierten Computer aus. Eine dedizierte Build-Maschine bietet lediglich den Vorteil, die Arbeit eines Entwicklers niemals zu blockieren und von einer zentralisierten Maschine aus bereitzustellen.

Ein Build-Server bietet viel mehr. Ein Build-Server ermöglicht CI (Continuous Integration), was bedeutet, dass er automatisch bei jedem Push an Ihr VCS (wie git) erstellt wird und bei Bedarf sogar Komponententests ausführt und die Bereitstellung mit einem Klick ermöglicht. Build-Server können Sie per E-Mail benachrichtigen, wenn Builds oder Tests fehlschlagen. Sie bieten historische Daten und Trends zu dem, was passiert ist.

Auf Build-Server können im Allgemeinen mehrere Benutzer oder Teams gleichzeitig zugreifen, indem sie eine Web-GUI verwenden, die in einem Browser ausgeführt wird.

In der Java-Welt ist Jenkins einer der am häufigsten verwendeten Build-Server. Jenkins funktioniert auch einwandfrei mit C ++ - Builds (da Sie diese beiden Sprachen zu verwenden scheinen). Jenkins nennt sich Automatisierungsserver, da er alle Arten von Aufgaben ausführen kann, die nicht mit Programmieren und Erstellen zusammenhängen müssen.

Neben der Antwort von Traubenfuchs haben Sie in Ihrer Frage einen weiteren Grund für eine Baumaschine angedeutet.

Nur weil die Software auf Ihrem Computer installiert ist, bedeutet dies nicht, dass sie auf der Software eines anderen Benutzers installiert ist. Möglicherweise verlassen Sie sich auf zufällige Dateien, die sich zufällig auf Ihrem Computer befinden (und möglicherweise nicht einmal unter Versionskontrolle stehen). Möglicherweise verlassen Sie sich auf eine vergessene Anwendung oder Bibliothek, die von einem obskuren Build-Skript aufgerufen wird.

Wenn Sie eine dedizierte Build-Maschine haben, sollten Sie wissen, was darauf installiert ist. Dies sollte gut dokumentiert sein. Sollte es jemals notwendig sein, die Software neu zu erstellen, vielleicht Jahre später, sollte es nur notwendig sein, eine neue Build-Maschine mit dem dokumentierten Material zu erstellen, das darauf installiert ist.

Der Hauptgrund für eine dedizierte Build-Maschine besteht darin, konsistente Builds zu erhalten, unabhängig davon, wer den Build ausführt. Entwicklerarbeitsplätze sind selten (gelesen: nie) identisch. Es ist schwer zu wissen, dass jeder Build exakt die gleichen Versionen von Abhängigkeiten und Compilern verwendet. Eines der schlimmsten Probleme bei Dev-Workstation-Builds ist, dass Entwickler aus Code erstellen können, der nicht in die Versionskontrolle eingecheckt ist.

Es ist nicht klar, welche Plattform / Sprache (n) Sie verwenden, aber Sie sollten idealerweise einen Build-Server haben, der direkt von der Quellcodeverwaltung abruft. Das heißt, wenn ein Build erforderlich ist, wird die Quelle aus einer bestimmten Version des Repository abgerufen und automatisch kompiliert. Dies erfordert die Verwendung automatisierter Build-Tools zum Erstellen eines Skripts. Wenn Sie dies nicht haben, sollte dies Schritt 1 sein.

Denken Sie daran, dass es nichts Falsches gibt, wenn Sie lokal für die Entwicklung bauen. Sie sollten auf jeden Fall vor Ort Unit-Tests, Code-Qualitätsanalysen und das Honen von Build-Skripten durchführen. Sonst verschwenden Sie viel Zeit. Die Ausgabe des Build-Servers ist für alles bestimmt, was Sie möglicherweise in die Produktion verlagern möchten. Alle QA-Aktivitäten wie Integrations- und Abnahmetests sollten nur mit Builds vom Build-Server durchgeführt werden.

In den anderen Antworten wurde zu Recht darauf hingewiesen, dass Sie den Build automatisieren sollten, sodass Sie nicht in ein anderes Büro gehen müssen. Lassen Sie mich jedoch eine Reihe von Schritten vorschlagen, die Sie zur Verbesserung Ihres Erstellungsprozesses ausführen können:

• Richten Sie zunächst den Fernzugriff auf den Build-Server ein! Wenn Sie manuell erstellen, indem Sie den Befehl "make" eingeben, bedeutet dies, dass Sie nicht mehr in ein anderes Büro gehen müssen, um "make" einzugeben. Sie können einfach SSH in den Build-Server eingeben und "make" eingeben. Wenn Sie make oder ein ähnliches Build-System noch nicht verwenden, nehmen Sie ein solches Build-System in Betrieb.
• Zweitens: Installieren Sie eine fortlaufende Integrationsumgebung, die automatisch die neuesten Änderungen aus dem Versionskontrollsystem abruft (Sie haben ein Versionskontrollsystem, oder, wenn nicht, wäre dies ein zusätzlicher Schritt) und erstellt diese. Ich empfehle Jenkins. Richten Sie Jenkins so ein, dass auch Ihre Komponententests und Integrationstests auf Systemebene ausgeführt werden (Sie haben beide Möglichkeiten, wenn nicht, erstellen Sie sie von Komponententests bis hin zu Integrationstests auf Systemebene).
• Drittens sollten Sie die Virtualisierung in Betracht ziehen, wenn Sie Probleme haben, denselben Computer mit anderen Teams zu teilen (z. B. wenn Sie unterschiedliche Meinungen zu welchem ​​Betriebssystem und welcher Version und Bitterkeit Sie verwenden sollten). Ein guter Server kann heute eine große Anzahl virtueller Maschinen ausführen. Vielleicht könnten Sie sich eine 32-Bit-Maschine und eine 64-Bit-Maschine einrichten, damit Sie wissen, dass der Build auf beiden Architekturen funktioniert.
• Schließlich ist dies möglicherweise nicht erforderlich: Wenn Sie unbedingt einen dedizierten Computer benötigen, z. B. wenn die Leistung Ihrer Anwendung von großer Bedeutung ist und andere Builds / Testläufe, die gleichzeitig ausgeführt werden, Ihre Ergebnisse zu stark beeinträchtigen, installieren Sie einen dedizierten Hardwareserver als nur du verwendest. Auf neueren Servern mit bis zu 40 oder mehr virtuellen CPU-Kernen ist es jedoch relativ einfach, einige virtuelle Maschinen zu erstellen, die keinen gemeinsamen Zugriff auf dieselben CPU-Kerne haben.

Ich würde eine gemeinsam genutzte Maschine viel besser als manuelle Builds betrachten. In meinem aktuellen Projekt wird derzeit eine virtuelle Maschine verwendet. Da jedoch Leistungstests für die Integration auf Systemebene erforderlich sind, wechseln wir zu einem dedizierten Server mit 40 virtuellen CPU-Kernen, für die Leistungstests 17 erforderlich sind.

... anstatt eine tatsächliche Maschine in unserem Büro zu verwenden, müssen wir eine einzelne Maschine mit mehreren anderen Gruppen teilen ...

Sie sagen, dass es eine schlechte Sache ist.

Sie haben jetzt einen gemeinsamen Build-Server, durch den alle Ihre Builds - Ihre und die der anderen Teams - erstellt werden. Konsistenz des Builds? Prüfen.

... die Mühe, mein Büro mit allen notwendigen Informationen zu verlassen und dann eine Treppe hinunter zu einem anderen Büro zu gehen, nur um einen einfachen Bau durchzuführen, lässt mich fragen, warum ich das überhaupt vorgeschlagen habe.

Sie führen den Build immer noch manuell durch und das ist nicht gut.

Sie benötigen einen Serverprozess, an den Sie Anfragen senden / in die Warteschlange stellen, damit Builds in Ihrem Namen ausgeführt werden können, und dieser Prozess sendet Ihnen die Ergebnisse zurück.

Neben anderen relevanten Antworten klingt es auch so, als würden Sie Ihre Builds direkt auf dem betreffenden Computer ausführen.

Für ein zuverlässiges Build-System, insbesondere wenn Sie den Build-Computer für andere Benutzer freigeben, ist es normal, Ihre Builds auf einem virtuellen Computer auszuführen. Dadurch wird sichergestellt, dass andere Benutzer das Verhalten Ihrer Builds nicht ändern können, indem sie ihre eigenen Versionen von Anwendungen oder Bibliotheken installieren, von denen Ihr Code abhängt. Ein großer Vorteil davon ist, dass die VM einfach gesichert und auf jeden anderen PC (einschließlich Ihrer eigenen Entwicklungsmaschine) geklont werden kann.

Es bietet einen zentralen, neutralen Speicherort für Builds, unabhängig von den IDE-, Betriebssystem- und Bibliothekskonfigurationen der einzelnen Entwickler.

Mit einer dedizierten Build-Maschine können Sie sie jedes Mal neu erstellen lassen, wenn ein Code-Push an das Repository gesendet wird. Wenn jemand den Build bricht, kann der Prozess sofort eine Warnung senden, damit das Problem sofort behoben werden kann.

Zusätzlich dazu, dass alles reproduzierbarer und zuverlässiger wird und das Repository nicht mit lauernden Abhängigkeitsproblemen überfüllt ist, erleichtert dies den Entwicklern das Leben, da alles, was sie tun müssen, um den Build auf ihrem Computer zum Laufen zu bringen, das Kopieren von allem wird auf der Build-Maschine durchgeführt.