Was sind die Vorteile von Build-Skripten?

Automatisierung.

Nur während der Entwicklung In den einfachsten Projekten wird die Standardschaltfläche „Erstellen“ alles tun, was Sie dazu benötigen. Möglicherweise müssen Sie WS aus APIs erstellen, Dokumente generieren, mit externen Ressourcen verknüpfen, die Änderungen auf einem Server bereitstellen usw. Bei einigen IDEs können Sie den Erstellungsprozess anpassen, indem Sie zusätzliche Schritte oder Builder hinzufügen. Dies bedeutet jedoch nur, dass Sie es sind Generieren Ihres Build-Skripts über die IDE-Commodities.

Bei der Entwicklung eines Systems wird jedoch nicht nur Code geschrieben. Es gibt mehrere Schritte. Ein IDE-unabhängiges Skript kann automatisch ausgeführt werden. Dies bedeutet:

• Wenn Sie eine Änderung an der Versionskontrolle vornehmen, kann der Server automatisch einen neuen Build starten. Dadurch wird sichergestellt, dass Sie nicht vergessen haben, die für den Build erforderlichen Daten festzuschreiben.

• Ebenso können nach Abschluss des Builds automatisch Tests ausgeführt werden, um festzustellen, ob Sie etwas beschädigt haben.

• Jetzt verfügt der Rest der Organisation (QS, Systemadministratoren) über ein Produkt, das

  a) nur mit der Kontrollversion perfekt reproduzierbar ist.

  b) ist allen gemeinsam.

Selbst wenn ich als Ein-Mann-Team gearbeitet habe, habe ich zu diesem Zweck Skripte verwendet. Wenn ich das Update entwickelt hatte, habe ich mich für SVN entschieden, das SVN wieder in ein anderes Verzeichnis exportiert und das Build-Skript verwendet, um die Lösung zu generieren, die dann zu Preproduction-Systemen und später zu Production ging. Wenn sich einige Wochen später (da sich meine lokale Codebasis bereits geändert hat) jemand über einen Fehler beschwert, würde ich genau wissen, welche SVN-Revision ich auschecken müsste, um das System ordnungsgemäß zu debuggen.

Kommentare

• Dies ist meiner Meinung nach die beste Antwort. Jeder hat Recht mit seiner Idee, aber diese zeigt wirklich, warum Sie Skripte erstellen möchten. Da sie die Automatisierung unterstützen, die bei der Erweiterung Ihres Projekts weiterentwickelt wird, sparen Sie viel Zeit.
• @Alexus Nicht nur Zeit, sondern auch dumme Fehler. 😉 “ Wiederholung führt zu Langeweile. Langeweile führt zu schrecklichen Fehlern. Schreckliche Fehler führen zu ‚ Ich wünschte, ich wäre immer noch gelangweilt.‘ “ (Sie könnten auch dumme Fehler in der Zeit messen, aber ‚ s Es ist wichtig zu wissen, dass ‚ Ihnen Zeit aus verschiedenen Gründen spart.)
• Selbst bei Ein-Mann-Projekten sollten Sie einen lokalen Jenkins-Server zur Automatisierung des “ in einem separaten Verzeichnis erstellen “ kann helfen. Ich ‚ arbeite unter Windows an etwas, das ich auch für Cross-Compiles bestätigen muss. Wenn Jenkins Tests erstellt und ausführt und dann die Cross-Compiled-Version erstellt, bin ich viel sicherer ( und natürlich effizient!), wenn ich Fehlerbehebungen veröffentlichen muss.
• Ich stimme ‚ dem Argument reproduzierbarer Builds nicht zu. Es gibt so viele unkontrollierte Variablen in heutigen Build-Systemen, dass es ziemlich schwierig ist, reproduzierbare Builds zu erhalten. Ihr Argument klingt so, als würden Sie das sofort einsatzbereit machen, was völlig falsch ist.
• @JonasGr ö ger Automation nimmt eine der folgenden Optionen heraus Größte Variablen: Menschen.

Wie Code wird ein Build-Skript vom Computer ausgeführt. Computer sind außergewöhnlich gut darin, eine Reihe von Anweisungen zu befolgen. Tatsächlich führen Computer (außerhalb des selbstmodifizierenden Codes) dieselbe Befehlsfolge bei gleicher Eingabe genauso aus. Dies liefert ein Maß an Konsistenz, das nur ein Computer erreichen kann.

Im Gegensatz dazu sind wir wassergefüllten Fleischsäcke geradezu verabscheuungswürdig, wenn es um die folgenden Schritte geht. Dieses lästige analytische Gehirn hat die Tendenz, alles in Frage zu stellen, was ihm begegnet. „Oh … das brauche ich nicht“ oder „Muss ich diese Flagge wirklich benutzen? Eh … ich werde es einfach ignorieren. Darüber hinaus neigen wir dazu, selbstgefällig zu werden. Sobald wir ein paar Mal etwas getan haben, glauben wir, dass wir die Anweisungen kennen und müssen nicht auf das Anweisungsblatt schauen.

Von „The Pragmatic Programmer“:

Darüber hinaus möchten wir die Konsistenz und Wiederholbarkeit des Projekts sicherstellen. Manuelle Verfahren lassen die Konsistenz sich ändern. Die Wiederholbarkeit kann nicht garantiert werden, insbesondere wenn Aspekte des Verfahrens von verschiedenen Personen interpretiert werden können.

Darüber hinaus sind wir bei der Ausführung von Anweisungen HILARIOUS schleppend ( im Vergleich zu einem Computer). Bei einem großen Projekt mit Hunderten von Dateien und Konfigurationen würde es Jahre dauern, alle Schritte in einem Erstellungsprozess manuell auszuführen.

Ich werde Ihnen ein Beispiel aus der Praxis geben. Ich habe an eingebetteter Software gearbeitet, bei der der größte Teil des Codes auf verschiedenen Hardwareplattformen geteilt wurde. Jede Plattform hatte unterschiedliche Hardware, aber der größte Teil der Software war gleich. Es gab jedoch kleine Teile, die für jede Hardware spezifisch waren. Im Idealfall werden die gemeinsamen Stücke in einer Bibliothek abgelegt und mit jeder Version verknüpft. Die gemeinsamen Teile konnten jedoch nicht in eine gemeinsam genutzte Bibliothek kompiliert werden. Sie musste mit jeder unterschiedlichen Konfiguration kompiliert werden.

Zuerst habe ich jede Konfiguration manuell kompiliert. Das Umschalten dauerte nur wenige Sekunden Konfigurationen, und war nicht so ein großer Schmerz. Gegen Ende des Projekts wurde ein kritischer Fehler im gemeinsam genutzten Teil des Codes entdeckt, bei dem ein Gerät im Wesentlichen den Kommunikationsbus übernehmen würde. Das war schlecht! Wirklich schlecht. Ich habe den Fehler im Code gefunden, behoben und jede Version neu kompiliert. Außer einem. Während des Erstellungsprozesses wurde ich abgelenkt und vergaß einen. Die Binärdateien wurden freigegeben, die Maschine wurde gebaut, und einen Tag später erhielt ich einen Anruf, der besagte, dass die Maschine nicht mehr reagierte. Ich überprüfte es und stellte fest, dass ein Gerät den Bus gesperrt hatte. „Aber ich habe diesen Fehler behoben!“.

Ich habe ihn vielleicht behoben, aber er hat nie seinen Weg auf dieses eine Board gefunden. Warum? Weil ich keinen automatisierten Erstellungsprozess hatte, der jede einzelne Version mit einem Klick erstellte.

Kommentare

• Und Sie können während des Kaffee trinken gehen Das Build-Skript wird ausgeführt!

Wenn Sie jemals nur , Build-Skripte dienen wenig Zweck (obwohl man argumentieren kann, dass wenn Sie im Projekt ein Makefile sehen, Sie wissen, dass Sie es mit ). Die Sache ist – nicht triviale Projekte erfordern normalerweise mehr als das – zumindest müssen Sie normalerweise Bibliotheken hinzufügen und (wenn das Projekt ausgereift ist) Build-Parameter konfigurieren.

IDEs sind normalerweise mindestens so konfigurierbar – aber jetzt basiert der Erstellungsprozess auf IDE-spezifischen Optionen.Wenn Sie Eclipse verwenden, bevorzugt Alice NetBeans und Bob möchte IntelliJ IDEA können Sie die Konfiguration nicht freigeben. Wenn einer von Ihnen eine Änderung an der Quellcodeverwaltung vornimmt, muss er entweder die von der IDE erstellten Konfigurationsdateien von manuell bearbeiten die anderen Entwickler oder benachrichtigen Sie die anderen Entwickler, damit sie es selbst tun (was bedeutet, dass es Commits gibt, bei denen die IDE-Konfiguration für einige der IDEs falsch ist …).

Sie müssen dies auch tun Finden Sie heraus, wie diese Änderung in jeder der vom Team verwendeten IDEs vorgenommen werden kann, und wenn eine von ihnen diese bestimmte Einstellung nicht unterstützt …

Nun ist dieses Problem kulturabhängig – Ihre Entwickler finden es möglicherweise akzeptabel, nicht die Wahl zwischen IDEs zu haben. Entwickler, die Erfahrung mit einer IDE haben, sind jedoch in der Regel sowohl zufriedener als auch effizienter, wenn sie verwendet werden, und Benutzer von Texteditoren neigen dazu, sich religiös für ihren Favoriten zu interessieren Dies ist einer der Orte, an denen Sie den Entwicklern Freiheit geben möchten – und mit Build-Systemen können Sie genau das tun. Einige Leute haben vielleicht eine Build-System-Präferenz, aber sie ist bei weitem nicht so fanatisch wie die IDE- / Editor-Präferenzen …

Selbst wenn Sie alle Entwickler dazu bringen, dieselbe IDE zu verwenden – viel Glück, den Build zu überzeugen Server, um es zu verwenden …

Nun, das ist für die einfachen Anpassungen des Erstellungsprozesses, für die IDEs in der Regel eine schöne GUI bereitstellen. Wenn Sie komplexere Dinge möchten – wie das Vorverarbeiten / automatische Generieren von Quelldateien vor dem Kompilieren – müssen Sie normalerweise ein vorgefertigtes Skript in einen grundlegenden Textbereich innerhalb der IDE-Konfiguration schreiben. In welchen Build-Systemen müssten Sie diesen Teil noch codieren, aber Sie können dies im eigentlichen Editor tun, in dem Sie den Code schreiben, und was noch wichtiger ist: Das Framework des Build-Systems selbst bietet normalerweise Unterstützung für die Organisation dieser Skripte. P. >

Schließlich – Build-Systeme eignen sich nicht nur zum Erstellen des Projekts – Sie können sie so programmieren, dass sie andere Aufgaben ausführen, die möglicherweise alle im Team ausführen müssen. In Ruby on Rails gibt es beispielsweise Build-System-Aufgaben zum Ausführen von Datenbankmigrationen, zum Bereinigen der temporären Dateien usw. Durch das Einfügen dieser Aufgaben in das Build-System wird sichergestellt, dass alle Mitglieder des Teams sie konsistent ausführen können.

Kommentare

• ‚ ist nicht nur eine Frage verschiedener IDEs. Einige Entwickler hassen und verabscheuen IDEs aller Art.
• @DavidHammen Ich ‚ bin einer dieser Entwickler (obwohl ich ‚ mein Vim so hart konfiguriert habe, ist ‚ ist es möglich, dass ich daraus eine IDE gemacht habe …), und während ich diesen Absatz schrieb, schrieb ich automatisch “ Editoren “ und musste es auf IDE korrigieren, da ich denke, dass das Fixture auf IDEs ein wichtiger Teil meiner Antwort ist. Der Fragesteller stammt eindeutig aus der IDE-Welt, und in der Frage geht es um die Entwicklung ohne IDE als etwas, zu dem Sie gezwungen sind, wenn keine richtige IDE verfügbar ist. Mit dieser Antwort soll gezeigt werden, wie nützlich Build-Systeme auch für Teams sind, die ausschließlich aus IDE-Benutzern bestehen.
• Auch ich bin einer dieser Entwickler. Ich möchte nicht, dass ‚ meine Finger die Tastatur verlassen müssen. Dies unterbricht meine Denkprozesse.
• Ich bin anderer Meinung. Ich bevorzuge IDEs. Sie erlauben mir, mich nicht um Namen, einfache Suche, Refactoring, nette Benutzeroberfläche zu kümmern. Ich meine, wenn eine IDE etwas für mich tun kann, das ich sonst mit sed ack usw. tun würde, verwende ich das.
• Der Punkt ist, dass jeder Entwickler im Team mit Build-Skripten verwenden kann, was er will. Während Sie mit der Build-Funktionalität der IDE ‚ alle dazu zwingen, nicht nur eine IDE zu verwenden, sondern auch die sehr spezifische IDE zu verwenden, für die das Projekt konfiguriert ist (es sei denn, Sie haben sie für mehrere konfiguriert IDEs und viel Glück beim Synchronisieren …)

Viele IDEs packen einfach die verwendeten Befehle zusammen Um etwas zu erstellen und dann ein Skript zu generieren und aufzurufen!

In Visual Studio können Sie beispielsweise die Befehlszeilenparameter für eine C ++ – Kompilierung im Feld „Befehlszeile“ anzeigen. Wenn Sie sich die Build-Ausgabe genau ansehen, sehen Sie die temporäre Datei, die das Build-Skript enthält, mit dem die Kompilierung ausgeführt wurde.

Heutzutage ist alles MSBuild , aber das wird immer noch direkt von der IDE ausgeführt.

Der Grund, warum Sie die Befehlszeile verwenden, ist, dass Sie direkt zur Quelle gehen und den mittleren Mann überspringen, a Mittelsmann, der möglicherweise aktualisiert wurde oder eine Menge Abhängigkeiten benötigt, die Sie auf einem kopflosen Server, der als kontinuierliche Integration (CI) fungiert, nicht benötigen oder benötigen. Server.

Darüber hinaus führen Ihre Skripte mehr aus als die üblichen entwicklerorientierten Schritte, für die sie entwickelt wurden.Beispielsweise möchten Sie nach einem Build möglicherweise, dass Ihre Binärdateien gepackt und an einen bestimmten Speicherort kopiert oder ein Installationspaket erstellt oder ein Dokumentationstool darauf ausgeführt wird. Viele verschiedene Aufgaben werden von einem CI-Server ausgeführt, die auf einem Entwicklercomputer sinnlos sind. Während Sie also ein IDE-Projekt erstellen können, das alle diese Schritte ausführt, müssen Sie zwei davon verwalten – ein Projekt für Entwickler und ein anderes für Builds. Einige Build-Aufgaben (z. B. statische Analyse) können eine lange Zeit in Anspruch nehmen, die Sie für Entwicklerprojekte nicht benötigen.

Kurz gesagt, es ist nur einfacher – erstellen Sie ein Skript, um alle Ihre Aufgaben zu erledigen wollen und es ist schnell und einfach, dies über die Befehlszeile oder eine Build-Server-Konfiguration zu starten.

make 

ist viel einfacher zu merken und einzugeben als

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h 

Und Projekte können sehr komplexe Kompilierungsbefehle haben. Ein Build-Skript kann auch nur die Änderungen neu kompilieren. Wenn Sie einen sauberen Build durchführen möchten, ist

make clean 

nach ordnungsgemäßer Einrichtung einfacher und zuverlässiger als der Versuch, sich an jeden Ort zu erinnern, den eine Zwischendatei möglicherweise hat wurde erstellt.

Wenn Sie eine IDE verwenden, können Sie natürlich auch einfach auf eine Schaltfläche zum Erstellen oder Bereinigen klicken. Es ist jedoch viel schwieriger, das Bewegen des Cursors an eine bestimmte Stelle auf dem Bildschirm zu automatisieren, insbesondere wenn sich diese Stelle möglicherweise bewegt, wenn sich das Fenster bewegt, als einen einfachen Textbefehl zu automatisieren.

Wie würden Sie es sonst tun? Die einzige andere Möglichkeit besteht darin, einen langen Befehlszeilenbefehl anzugeben.

Ein weiterer Grund ist der folgende Makefiles ermöglichen eine inkrementelle Kompilierung, wodurch die Kompilierungszeit erheblich verkürzt wird.

Makefiles können einen Buildprozess auch plattformübergreifend erstellen. CMake generiert verschiedene Build-Skripte basierend auf der Plattform.

Bearbeiten:

Mit einer IDE sind Sie an eine bestimmte Vorgehensweise gebunden. Viele Menschen verwenden Vim oder Emacs, obwohl sie nicht viele IDE-ähnliche Funktionen haben. Sie tun dies, weil sie die Leistung dieser Funktionen wünschen Editoren bieten Build-Skripte für Benutzer, die keine IDE verwenden.

Selbst für Benutzer, die eine IDE verwenden, möchten Sie möglicherweise wirklich wissen, was gerade passiert. Das Build-Skript bietet Ihnen daher detaillierte Informationen der Implementierung, die ein GUI-Ansatz nicht hat.

IDEs selbst verwenden häufig auch intern erstellte Skripte. Die Schaltfläche „Ausführen“ ist nur eine weitere Möglichkeit, den Befehl „make“ auszuführen.

Die obigen Antworten decken viele gute Gründe ab. Ein Beispiel aus der Praxis, das ich hinzufügen möchte (das ich aufgrund fehlenden Karmas nicht als Kommentar hinzufügen kann), stammt aus der Android-Programmierung.

Ich bin ein professionelles Android / iOS / Windows Telefonentwickler und ich verwenden Google Services-APIs (hauptsächlich Google Maps) ein Los .

In Android Für diese Dienste muss ein Keystore hinzugefügt werden. oder eine Art Entwickler-ID-Datei, die Google gegenüber einer Entwicklerkonsole mitteilt, dass ich der bin, von dem ich sage, dass ich es bin. Wenn meine App mit einem anderen Schlüsselspeicher kompiliert wird, funktioniert der Abschnitt Google Maps der App nicht.

Anstatt ein Dutzend Keystores zur Entwicklerkonsole hinzuzufügen und zu verwalten, von denen ohnehin nur einer zum Aktualisieren der App verwendet werden kann, füge ich diesen Keystore in unser sicheres Repo ein und verwenden Sie Gradle, um Android Studio genau mitzuteilen, welcher Keystore beim Erstellen für „Debug“ oder „Release“ verwendet werden soll. Jetzt muss ich meiner Google-Entwicklerkonsole nur noch zwei Keystores hinzufügen, einen für „Debug“ und einen für „Release“, und alle meine Teammitglieder können das Repo klonen und sofort mit der Entwicklung beginnen, ohne zum Entwickler gehen zu müssen Konsole und füge den SHA-Hash ihres jeweiligen Keystores hinzu, oder schlimmer noch, damit ich sie verwalte . Dies hat den zusätzlichen Vorteil, dass jedem Teammitglied eine Kopie des Signatur-Keystores zur Verfügung gestellt wird. Wenn ich nicht im Büro bin und ein Update geplant ist, muss ein Teammitglied nur eine sehr kurze Liste von Anweisungen befolgen, um eine zu pushen Update.

Eine solche Build-Automatisierung hält die Builds konsistent und reduziert die technische Verschuldung, indem die Einrichtungszeit verkürzt wird, wenn wir einen neuen Entwickler, eine neue Maschine oder ein neues Image erhalten Maschine.

Skriptvorteile erstellen:

• Änderungen sehen aus wie Code (für Beispiel: in einem git diff-Befehl), nicht wie bei verschiedenen aktivierten Optionen in einem Dialogfeld

• , das mehr Ausgabe erzeugt als ein einfacher Build

In einigen meiner vorherigen Projekte habe ich die Build-Skripte verwendet, um:

• die Projektdokumentation (auf Sauerstoffbasis)
• Build

zu generieren

Oft können Sie die Schaltfläche „Build“ aufrufen auf automatisierte Weise (Visual Studio akzeptiert beispielsweise Befehlszeilenargumente). Benutzer schreiben Build-Skripte, sobald sie etwas benötigen, das die Build-Schaltfläche nicht bereitstellen kann.

In den meisten IDEs können Sie beispielsweise nur erstellen jeweils eine Plattform oder nur eine Sprache zu einem Zeitpunkt. Dann machen Sie Folgendes mit den erstellten Ausgaben: Kann Ihre IDE sie alle zu einem Installationspaket zusammenfassen?