Was ist der Sinn eines "Build Servers"? [geschlossen]

Ich habe nicht für sehr große Organisationen gearbeitet und ich habe nie für eine Firma gearbeitet, die einen "Build Server" hatte.

Was ist ihr Zweck? Warum bauen die Entwickler das Projekt nicht auf ihren lokalen Computern auf oder? Sind einige Projekte so groß, dass leistungsstärkere Maschinen erforderlich sind, um sie in angemessener Zeit zu erstellen?

Der einzige Ort, an dem ich sehe, dass ein Build-Server nützlich ist, ist die kontinuierliche Integration mit dem Build-Server, wobei ständig erstellt wird, was für das Repository festgeschrieben wird. Habe ich gerade nicht an Projekten gearbeitet, die groß genug sind?

Jemand, bitte klären Sie mich auf: Was ist der Zweck eines Build-Servers?

Der angegebene Grund ist tatsächlich ein großer Vorteil. Builds, die zur Qualitätssicherung gehen, sollten immer nur von einem System stammen, das nur aus dem Repository erstellt wird. Auf diese Weise sind Build-Pakete reproduzierbar und nachvollziehbar. Entwickler, die manuell Code für alles erstellen, außer für ihre eigenen Tests, sind gefährlich. Zu hohes Risiko, dass Dinge nicht eingecheckt werden, mit den Änderungen anderer Leute nicht mehr auf dem neuesten Stand sind usw. usw.

Joel Spolsky in dieser Angelegenheit.

Build-Server sind aus mehreren Gründen wichtig.

• Sie isolieren die Umgebung Der lokale Code Monkey-Entwickler sagt "Es wird auf meinem Computer kompiliert ", wenn es auf Ihrem Computer nicht kompiliert wird. Dies kann bedeuten, dass die Eincheckvorgänge nicht synchron sind oder dass eine abhängige Bibliothek fehlt. Jar Hölle ist nicht so schlimm wie .dll Hölle; In beiden Fällen ist die Verwendung eines Build-Servers eine günstige Versicherung dafür, dass Ihre Builds nicht auf mysteriöse Weise fehlschlagen oder versehentlich die falschen Bibliotheken verpacken.

• Sie konzentrieren sich auf die mit Builds verbundenen Aufgaben. Dies umfasst das Aktualisieren des Build-Tags, das Erstellen von Verteilungspaketen, das Ausführen automatisierter Tests sowie das Erstellen und Verteilen von Build-Berichten. Automatisierung ist der Schlüssel.

• Sie koordinieren die (verteilte) Entwicklung. Im Standardfall arbeiten mehrere Entwickler an derselben Codebasis. Das Versionskontrollsystem ist das Herzstück dieser Art der verteilten Entwicklung, aber je nach Tool interagieren die Entwickler möglicherweise nicht viel miteinander. Anstatt Entwickler zu zwingen, fehlerhafte Builds zu riskieren oder sich Sorgen zu machen, dass Code zu aggressiv zusammengeführt wird, entwerfen Sie den Build-Prozess so, dass der automatisierte Build den entsprechenden Code sehen und die Build-Artefakte auf vorhersehbare Weise verarbeiten kann. Auf diese Weise können Entwickler schnell benachrichtigt werden, wenn sie Probleme mit einem Problem begehen, z. B. wenn sie keine neue Dateiabhängigkeit einchecken. Wenn Sie dies in einem bereitgestellten Bereich tun, können Sie den erstellten Code kennzeichnen, damit Entwickler keinen Code abrufen, der ihren lokalen Build beschädigen würde. PVCS hat dies mit der Idee von Werbegruppen recht gut gemacht. Clearcase könnte dies auch mithilfe von Etiketten tun, würde jedoch mehr Prozessverwaltung erfordern, als viele Geschäfte bereitstellen möchten.

Was ist ihr Zweck?
Nehmen Sie die Last der Entwicklermaschinen und stellen Sie eine stabile, reproduzierbare Umgebung für Builds bereit.

Warum bauen die Entwickler das Projekt nicht auf ihren lokalen Computern auf oder?
Denn mit komplexer Software können erstaunlich viele Dinge schief gehen, wenn nur "kompiliert" wird. Probleme, auf die ich tatsächlich gestoßen bin:

• unvollständige Abhängigkeitsprüfungen verschiedener Art, die dazu führen, dass Binärdateien nicht aktualisiert werden.
• Veröffentlichen Sie Befehle, die unbemerkt fehlschlagen. Die Fehlermeldung im Protokoll wird ignoriert.
• Build mit lokalen Quellen, die noch nicht zur Quellcodeverwaltung verpflichtet sind (zum Glück noch keine "verdammten Kunden" -Nachrichtenfelder ..).
• Wenn Sie versuchen, das oben genannte Problem zu vermeiden, indem Sie aus einem anderen Ordner erstellen, werden einige Dateien aus dem falschen Ordner ausgewählt.
• Der Zielordner, in dem Binärdateien zusammengefasst sind, enthält zusätzliche veraltete Entwicklerdateien, die nicht in der Version enthalten sein sollten

Wir haben eine erstaunliche Stabilitätssteigerung, da alle öffentlichen Veröffentlichungen mit einem Zugriff von der Quellcodeverwaltung auf einen leeren Ordner beginnen. Vorher gab es viele "lustige Probleme", die "verschwunden sind, als Joe mir eine neue DLL gab".

Sind einige Projekte so groß, dass leistungsstärkere Maschinen erforderlich sind, um sie in angemessener Zeit zu erstellen?

Was ist "vernünftig"? Wenn ich einen Batch-Build auf meinem lokalen Computer ausführe, gibt es viele Dinge, die ich nicht tun kann. Anstatt Entwickler für die Fertigstellung von Builds zu bezahlen, zahlen Sie die IT, um bereits eine echte Build-Maschine zu kaufen.

Habe ich gerade nicht an Projekten gearbeitet, die groß genug sind?

Größe ist sicherlich ein Faktor, aber nicht der einzige.

Ein Build-Server ist ein anderes Konzept als ein Continuous Integration-Server. Der CI-Server ist vorhanden, um Ihre Projekte zu erstellen, wenn Änderungen vorgenommen werden. Im Gegensatz dazu ist ein Build-Server vorhanden, um das Projekt (normalerweise eine Version gegen eine mit Tags versehene Revision) in einer sauberen Umgebung zu erstellen. Es stellt sicher, dass keine Entwickler-Hacks, Optimierungen, nicht genehmigten Konfigurations- / Artefaktversionen oder nicht festgeschriebenen Code in den freigegebenen Code gelangen.

Der Build-Server wird verwendet, um den Code aller Benutzer beim Einchecken zu erstellen. Ihr Code wird möglicherweise lokal kompiliert, aber höchstwahrscheinlich werden nicht alle Änderungen ständig von allen anderen vorgenommen.

Um das bereits Gesagte hinzuzufügen:

Ein ehemaliger Kollege arbeitete im Microsoft Office-Team und sagte mir, dass ein vollständiger Build manchmal 9 Stunden dauerte. Das wäre scheiße, wenn du es auf DEINER Maschine machen würdest, nicht wahr?

Es ist eine "saubere" Umgebung erforderlich, die frei von Artefakten früherer Versionen (und Konfigurationsänderungen) ist, um sicherzustellen, dass Builds und Tests funktionieren und nicht von den Artefakten abhängen. Eine effektive Möglichkeit zum Isolieren besteht darin, einen separaten Build-Server zu erstellen.

Ich stimme den bisherigen Antworten in Bezug auf Stabilität, Rückverfolgbarkeit und Reproduzierbarkeit zu. (Viele davon, richtig?). Nachdem ich NUR für große Unternehmen (Gesundheitswesen, Finanzen) mit vielen Build-Servern gearbeitet habe, möchte ich hinzufügen, dass es auch um Sicherheit geht. Schon mal den Film Office Space gesehen? Wenn ein verärgerter Entwickler eine Bankanwendung auf seinem lokalen Computer erstellt und niemand anderes sie sich ansieht oder testet ... BOOM. Superman III.

Diese Maschinen werden aus verschiedenen Gründen eingesetzt, um Ihnen zu helfen, ein überlegenes Produkt bereitzustellen.

Eine Verwendung besteht darin, eine typische Endbenutzerkonfiguration zu simulieren. Das Produkt funktioniert möglicherweise auf Ihrem Computer, wenn alle Entwicklungstools und Bibliotheken eingerichtet sind, aber der Endbenutzer hat höchstwahrscheinlich nicht die gleiche Konfiguration wie Sie. Im Übrigen haben andere Entwickler auch nicht genau das gleiche Setup wie Sie. Wenn Sie irgendwo in Ihrem Code einen fest codierten Pfad haben, funktioniert dieser wahrscheinlich auf Ihrem Computer, aber wenn Dev El O'per versucht, denselben Code zu erstellen, funktioniert er nicht.

Sie können auch verwendet werden, um zu überwachen, wer das Produkt zuletzt beschädigt hat, mit welchem ​​Update und wo das Produkt zurückgegangen ist. Jedes Mal, wenn neuer Code eingecheckt wird, erstellt der Build-Server ihn. Wenn dies fehlschlägt, ist klar, dass etwas nicht stimmt und der Benutzer, der zuletzt einen Commit durchgeführt hat, schuld ist.

Um eine gleichbleibende Qualität zu erzielen und den Build "von Ihrem Computer" zu entfernen, um Umgebungsfehler zu erkennen und um sicherzustellen, dass alle Dateien, die Sie vergessen haben, in die Quellcodeverwaltung einzuchecken, auch als Buildfehler angezeigt werden.

Ich verwende es auch, um Installationsprogramme zu erstellen, da diese auf dem Desktop viel Zeit für die Codesignatur usw. benötigen.

Wir verwenden eine, damit wir wissen, dass auf den Produktions- / Testboxen dieselben Bibliotheken und Versionen dieser Bibliotheken installiert sind wie auf dem Buildserver.

Es geht um Management und Testen für uns. Mit einem Build-Server wissen wir immer, dass wir unsere Hauptleitung über die Versionskontrolle erstellen können. Wir können eine Master-Installation mit einem Klick erstellen und im Web veröffentlichen. Wir können alle unsere Unit-Tests jedes Mal ausführen, wenn der Code eingecheckt wird, um sicherzustellen, dass er funktioniert. Durch das Sammeln all dieser Aufgaben auf einer einzigen Maschine wird es einfacher, sie wiederholt richtig zu machen.

Sie haben Recht, dass Entwickler auf ihren eigenen Maschinen bauen könnten.

Aber dies sind einige der Dinge, die uns unser Build-Server kauft, und wir sind kaum anspruchsvolle Build-Hersteller:

• Probleme mit der Versionskontrolle (einige wurden in früheren Antworten erwähnt)
• Effizienz. Entwickler müssen nicht anhalten, um Builds lokal zu erstellen. Sie können es auf dem Server starten und mit der nächsten Aufgabe fortfahren. Wenn Builds groß sind, ist dies noch mehr Zeit, in der die Maschine des Entwicklers nicht belegt ist. Für diejenigen, die kontinuierliche Integration und automatisierte Tests durchführen, noch besser.
• Zentralisierung. Unsere Build-Maschine verfügt über Skripte, die den Build erstellen, an UAT-Umgebungen und sogar an die Produktionsbereitstellung verteilen. Wenn Sie sie an einem Ort aufbewahren, wird der Aufwand für die Synchronisierung verringert.
• Sicherheit. Wir machen hier nicht viel Besonderes, aber ich bin sicher, ein Systemadministrator kann es so machen, dass auf Produktionsmigrations-Tools nur bestimmte autorisierte Entitäten auf einem Build-Server zugreifen können.

Vielleicht bin ich der einzige ...

Ich denke, alle sind sich einig, dass man sollte

• Verwenden Sie ein Datei-Repository
• Builds aus dem Repository (und in einer sauberen Umgebung)
• Verwenden Sie einen kontinuierlichen Testserver (z. B. Tempomat), um festzustellen, ob nach Ihren "Korrekturen" etwas kaputt ist.

Aber niemand kümmert sich um automatisch erstellte Versionen. Wenn etwas in einem automatischen Build kaputt gegangen ist, aber nicht mehr - wen interessiert das? Es ist in Arbeit. Jemand hat es repariert.

Wenn Sie eine Release-Version erstellen möchten, führen Sie einen Build aus dem Repository aus. Und ich bin mir ziemlich sicher, dass Sie die Version zu diesem Zeitpunkt im Repository markieren möchten und nicht alle sechs Stunden, wenn der Server seine Arbeit erledigt.

Vielleicht ist ein "Build-Server" nur eine Fehlbezeichnung und tatsächlich ein "kontinuierlicher Testserver". Ansonsten klingt es ziemlich nutzlos.

Ein Build-Server gibt Ihnen eine Art Zweitmeinung über Ihren Code. Beim Einchecken wird der Code eingecheckt. Wenn es funktioniert, hat der Code eine Mindestqualität.

Denken Sie außerdem daran, dass das Kompilieren von Low-Level-Sprachen viel länger dauert als von High-Level-Sprachen. Es ist leicht zu denken: "Nun, mein .Net-Projekt wird in wenigen Sekunden kompiliert! Was ist die große Sache?" Vor einiger Zeit musste ich mich mit C-Code herumschlagen und hatte vergessen, wie lange das Kompilieren noch dauert.

Ein Build-Server wird verwendet, um Kompilierungsaufgaben (z. B. nächtliche Builds) für normalerweise große Projekte in einem Repository zu planen, die manchmal länger als ein paar Stunden dauern können.

Ein Build-Server bietet Ihnen auch eine Grundlage für die Übertragungsurkunde und kann alle Teile erfassen, die für die Reproduktion eines Builds erforderlich sind, falls andere möglicherweise Eigentumsrechte haben.