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?
quelle
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.
quelle
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:
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.
quelle
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.
quelle
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.
quelle
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?
quelle
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.
quelle
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.
quelle
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.
quelle
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.
quelle
Wir verwenden eine, damit wir wissen, dass auf den Produktions- / Testboxen dieselben Bibliotheken und Versionen dieser Bibliotheken installiert sind wie auf dem Buildserver.
quelle
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.
quelle
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:
quelle
Vielleicht bin ich der einzige ...
Ich denke, alle sind sich einig, dass man sollte
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.
quelle
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.
quelle
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.
quelle
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.
quelle
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.
quelle