it-swarm.com.de

Was bringt ein "Build Server"?

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 Rechnern auf oder sind es? Sind einige Projekte so groß, dass leistungsfähigere Maschinen erforderlich sind, um sie in angemessener Zeit zu erstellen?

Der einzige Ort, an dem ich einen Build-Server als nützlich erachte, ist die kontinuierliche Integration in den Build-Server, wobei ständig das erstellt wird, was für das Repository festgeschrieben ist. Habe ich gerade nicht groß genug an Projekten gearbeitet?

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

98
KingNestor

Der angegebene Grund ist tatsächlich ein großer Vorteil. Builds, die für die Qualitätssicherung verwendet werden, 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 Code für irgendetwas anderes als ihre eigenen Tests manuell erstellen, sind gefährlich. Zu viel Risiko, dass Sachen nicht eingecheckt werden, nicht auf dem neuesten Stand sind, was andere Leute ändern, usw. usw.

Joel Spolsky zu diesem Thema.

94
mkb

Build-Server sind aus mehreren Gründen wichtig.

  • Sie isolieren die Umgebung. Der lokale Code Monkey Entwickler sagt "Es kompiliert auf meiner Maschine", wenn es auf Ihrer nicht kompiliert wird . Dies kann bedeuten, dass das Einchecken nicht synchron ist, 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 billige Versicherung, dass Ihre Builds nicht auf mysteriöse Weise versagen oder versehentlich die falschen Bibliotheken packen.

  • Sie konzentrieren sich auf die mit Builds verbundenen Aufgaben. Dies umfasst das Aktualisieren des Build-Tags, das Erstellen von Distributionspaketen, 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 auf derselben Codebasis. Das Versionskontrollsystem ist das Herzstück dieser Art verteilter Entwicklung, aber je nach Tool interagieren die Entwickler möglicherweise nicht viel miteinander. Anstatt Entwickler zu zwingen, schlechte Builds zu riskieren oder sich Sorgen zu machen, dass Code zu aggressiv zusammengeführt wird, sollten Sie den Build-Prozess so gestalten, dass der automatisierte Build den entsprechenden Code erkennt und die Build-Artefakte auf vorhersehbare Weise verarbeitet. Auf diese Weise kann ein Entwickler schnell benachrichtigt werden, wenn er ein Problem begeht, z. B. keine neue Dateiabhängigkeit eincheckt. Wenn Sie dies in einem bereitgestellten Bereich tun, können Sie den erstellten Code kennzeichnen, damit Entwickler keinen Code abrufen, der ihre lokale Erstellung stören würde. PVCS hat dies recht gut mit der Idee von Fördergruppen gemacht. Clearcase könnte dies auch mithilfe von Etiketten tun, würde jedoch mehr Prozessadministration erfordern, als viele Geschäfte bereitstellen.

44
Kelly S. French

Was ist ihr Zweck?
Laden Sie Entwicklercomputer und stellen Sie eine stabile, reproduzierbare Umgebung für Builds bereit.

Warum bauen die Entwickler das Projekt nicht auf ihren lokalen Rechnern auf oder?
Weil bei komplexer Software erstaunlich viele Dinge schief gehen können, 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 im Hintergrund fehlschlagen. Die Fehlermeldung im Protokoll wird ignoriert.
  • Build mit lokalen Quellen, die noch nicht zur Quellcodeverwaltung verpflichtet sind (zum Glück noch keine Nachrichtenfelder für "verdammte Kunden").
  • Wenn Sie versuchen, das obige Problem durch Erstellen aus einem anderen Ordner zu vermeiden, wurden einige Dateien aus dem falschen Ordner ausgewählt.
  • Der Zielordner, in dem die Binärdateien zusammengefasst sind, enthält zusätzliche veraltete Entwicklerdateien, die in der Version nicht enthalten sein sollten

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

Sind einige Projekte so groß, dass leistungsfähigere 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, kann ich viele Dinge nicht tun. Anstatt die Entwickler für die Fertigstellung der Builds zu bezahlen, sollten Sie die IT bezahlen, um bereits eine echte Build-Maschine zu kaufen.

Habe ich gerade nicht groß genug an Projekten gearbeitet?

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

26
peterchen

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 gibt es einen Build-Server, um das Projekt (normalerweise eine Version, die mit einem Tag versehen ist) in einer sauberen Umgebung zu erstellen. Es stellt sicher, dass keine Entwickler-Hacks, Tweaks, nicht genehmigten Konfigurations-/Artefaktversionen oder nicht festgeschriebenen Code in den freigegebenen Code gelangen.

6
Rich Seller

Der Build-Server wird verwendet, um den Code aller zu erstellen, wenn er eingecheckt ist. Ihr Code wird möglicherweise lokal kompiliert, aber Sie werden wahrscheinlich nicht die ganze Zeit über alle anderen Änderungen vornehmen müssen.

4
kemiller2002

Ich stimme den bisherigen Antworten in Bezug auf Stabilität, Rückverfolgbarkeit und Reproduzierbarkeit zu. (Viele Leute, richtig?). Nachdem ich NUR für große Unternehmen (Gesundheitswesen, Finanzen) mit vielen Build-Servern gearbeitet habe, würde 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 ansieht oder testet ... BOOM. Superman III.

4
Greg

Hinzufügen, was bereits gesagt wurde:

Ein ehemaliger Kollege arbeitete im Microsoft Office-Team und teilte mir mit, dass ein vollständiger Build manchmal 9 Stunden dauerte. Das wäre scheiße, um es auf IHRER Maschine zu machen, nicht wahr?

3
Andrei Rînea

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

3
paulwhit

Diese Maschinen werden aus verschiedenen Gründen eingesetzt, um Ihnen zu einem überlegenen Produkt zu verhelfen.

Eine Verwendung besteht darin, eine typische Endbenutzerkonfiguration zu simulieren. Das Produkt funktioniert möglicherweise auf Ihrem Computer mit allen eingerichteten Entwicklungstools und Bibliotheken, aber der Endbenutzer hat höchstwahrscheinlich nicht die gleiche Konfiguration wie Sie. In diesem Fall haben andere Entwickler nicht genau dasselbe 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 mit welchem ​​Update beschädigt hat und wo sich das Produkt zurückgebildet hat. Immer wenn neuer Code eingecheckt wird, erstellt der Build-Server ihn und wenn er fehlschlägt, ist klar, dass etwas nicht stimmt und der Benutzer, der das letzte Commit ausgeführt hat, schuld.

3
samoz

Um eine gleichbleibende Qualität zu erzielen und den Build von Ihrem Computer zu entfernen, damit Umgebungsfehler erkannt werden und alle Dateien, die Sie vergessen, in die Quellcodeverwaltung einzuchecken, auch als Buildfehler angezeigt werden.

Ich benutze es auch, um Installer zu erstellen, da diese auf dem Desktop viel Zeit benötigen, um Code zu signieren usw.

2
Ryan O'Neill

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

1
RC.

Es geht für uns um Management und Testen. Mit einem Build-Server wissen wir immer, dass wir unsere Haupt- "Trunk" -Linie ü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 in einer einzigen Maschine wird es einfacher, diese wiederholt zu erledigen.

1
Paul Alexander

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

Aber dies sind einige Dinge, die uns unser Build-Server bietet, und wir sind keine hoch entwickelten Build-Macher:

  • Probleme mit der Versionskontrolle (einige wurden in früheren Antworten erwähnt)
  • Effizienz. Entwickler müssen nicht aufhören, 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 die Zeit umso länger, als 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 Skripts, mit denen der Build erstellt, an UAT-Umgebungen und sogar an Produktions-Staging verteilt wird. Wenn Sie sie an einem Ort aufbewahren, müssen Sie sie nicht mehr synchron halten.
  • Sicherheit. Wir machen hier nicht viel spezielles, aber ich bin sicher, ein Sysadmin kann es so machen, dass auf Produktionsmigrationstools nur von bestimmten autorisierten Entitäten auf einem Build-Server zugegriffen werden kann.
1
Bernard Dy

Vielleicht bin ich der einzige ...

Ich denke, alle sind sich einig, dass man sollte

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

Aber niemand kümmert sich um automatisch erstellte Versionen. Wenn etwas in einem automatischen Build kaputt gegangen ist, es aber nicht mehr ist - wen interessiert das? Es ist eine laufende 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 um dass Uhr 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.

1
Stroboskop

Ein Build-Server bietet Ihnen auch eine Grundlage für die Übertragungsurkunde. Er kann alle Teile erfassen, die für die Reproduktion eines Builds erforderlich sind, falls andere Eigentümerrechte haben.

0
Greg Domjan

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.

0
citn

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

0
Burkhard

Beachten Sie außerdem, dass das Kompilieren von Sprachen auf niedriger Ebene viel länger dauert als von Sprachen auf hoher Ebene. Es ist leicht zu denken: "Nun, mein .Net-Projekt wird in wenigen Sekunden kompiliert. Was ist das große Problem?" Vor einiger Zeit musste ich mich mit C-Code herumschlagen und hatte vergessen, wie lange das Kompilieren dauert.

0
Spencer Ruport