Definition „Build Environment“ Was ist eine Build-Umgebung?

Anbieter zum Thema

OutSystems

Die Build-Umgebung dient der Kompilierung des Quelltextes in der Software- und Anwendungsentwicklung. Im Rahmen des Builds wird eine vollständige und lauffähige Software erzeugt. Das Ergebnis ist ein ausführbares Programm.

Die Build-Umgebung dient der zentralen Kompilierung, nicht jedoch der Ausführung des Quelltexts. Es ist nicht zwingend erforderlich, dass die Build-Umgebung der Produktiv-Umgebung ähneln muss. Doch muss sie die für die Kompilierung erforderlichen Abhängigkeiten bereitstellen.

Der Begriff Build selbst bezieht sich zum einen auf den Prozess der Erstellung einer vollständigen und lauffähigen Software und andererseits auf das Resultat dieses Vorgangs, sprich die ausführbaren Programme und Anwendungen sowie deren Ressourcen. Demnach wird sowohl der Prozess als auch die fertige Version als Build bezeichnet.

Nahezu jede Software und Anwendung besteht aus mehreren Quelldateien. Vor ihrer Ausführung ist es erforderlich, dass sie in ein ausführbares Konstrukt umgewandelt werden. An dieser Stelle kommt der Build-Prozess zum Einsatz. In den meisten Fällen ist zur Kennzeichnung einzelner Builds die Zuweisung einer eindeutigen Build-Nummer Gang und Gäbe.

Eine Ausnahme sind quelloffene Software-Lösungen, bei denen Endnutzer den Build-Vorgang selbst in Angriff nehmen. Die Build-Nummer kann die Form einer einfachen und fortlaufenden Nummerierung annehmen. Oftmals beinhaltet sie jedoch auch die Versionsnummer der genutzten Quellen.

Eine komplexere Build-Nummer ist beispielsweise die von Google für Android-Apps genutzte Build-Nummer. Zu Beginn steht der Buchstabe, der dem ersten Buchstabens des Codenamens der jeweiligen Android-Version entspricht (zum Beispiel O wie Oreo). Im weiteren Verlauf steht an zweiter Stelle ein Buchstaben-Code zur Kennzeichnung des Versionsstands des Quelltexts. Nach der anschließenden Datumsangabe folgt an letzter Stelle noch ein Code, der für jeden einzelnen Build-Prozess innerhalb der gleichen Version sowie mit der gleichen Datumsangabe fortlaufend und sequentiell gestaltet ist.

Ein Build und sein Ablauf

Im Fokus eines jeden Builds steht das Kompilieren des Quellenmaterials. Die Quellen sind typischerweise in Programmiersprachen geschrieben, die den Kompilierungs-Schritt erfordern (beispielsweise C) oder zumindest ermöglichen (so etwa Python oder Java). Der Build-Prozess beinhaltet in erster Linie die Bereitstellung geeigneter sowie aktueller Quellen.

Im Ablauf eines Builds spielen auch Automatisierungs-Tools eine große Rolle. Automatisieren lassen sich beispielsweise Schritte wie der Download eines Quelltext-Archivs oder die Bereitstellung der Quelle. Build-Tools dienen ferner dazu, für Konsistenz in den Rahmenbedingungen zwischen unterschiedlichen Builds zu sorgen.

Das aus dem Unix-Universum stammende Automatisierungs-Tool „make“ ist ein oft verwendetes Programm. Seine Aufgabe ist das Lesen einer Konfigurationsdatei (normalerweise mit dem Namen Makefile versehen), die genaue Anweisungen für die Schritte des Build-Prozesses beinhaltet. Hierbei ist es möglich, jeden Schritt von genauen Bedingungen abhängig zu machen, so beispielsweise von der Aktualität benötigter Dateien.

Auf diese Weise lässt sich etwa sicherstellen, dass sämtliche für einen Build erforderlichen Schritte in der korrekten Reihenfolge ausgeführt werden. Weiterhin dient dies der Reduktion zusätzlichen Aufwands, wenn beim weiteren Durchlauf die Ergebnisse oder Teilergebnisse vorausgehender Build-Schritte noch aktuell sind.

Neben dieser Mutter der Build-Tools finden sich auf dem Markt verschiedene Derivate für unterschiedliche Programmiersprachen. Ein Build-Tool, das sich lange als Standard für Java sowie andere Sprachen aus dem JVM-Umfeld durchgesetzt hat, ist Maven. Ein Standard für die Anwendungs-Entwicklung in Android ist Gradle. Durch diverse Plug-ins lässt sich dessen Funktionsumfang über das JVM-Umfeld hinaus erweitern.

Grundsätzlich liegen für nahezu jede Sprache ein eigenes Build-Tool vor. Oder es existieren spezialisierte Plug-ins, die auf einem bereits existierendes Build-Werkzeug aufbauen. Ähnlich wie bei der Wahl der Programmiersprachen oder der Editoren oder der Betriebssysteme ist daher eine große Auswahl gegeben. Über die Auswahl und Eignung der Build-Tools herrscht oftmals kein Konsens unter Entwicklern.

Das Ende des (teilweise durch Tools automatisierten) Build-Prozesses ist gekennzeichnet von der lokalen Installation der erzeugten Anwendung (wenn sie für den Einsatz unmittelbar auf dem Zielsystem vorgesehen ist) oder dem Packen der Dateien für den Export.

Stellenwert der Build-Umgebung im Prozess der Software-Entwicklung

Zum genaueren Verständnis der Build-Umgebung ist es wichtig, sie im Kontext weiterer Umgebungen beziehungsweise Environments zu betrachten, die im Rahmen der Software-Entwicklung von Relevanz sind.

Grundsätzlich lassen sich die Entwicklungs-Umgebung (Development-Environment), die Staging-Umgebung und die Produktiv-Umgebung unterscheiden. Diese lassen sich durch zahlreiche weitere Umgebungen und Schritte ergänzen. Oftmals kommt noch eine Test-Umgebung dazu. Ergänzt werden die Umgebungen in der Software-Entwicklung durch eine Qualitätssicherungs-Umgebung.

Dabei stellt die Development-Umgebung eine Art Arbeitsversion der Software oder Anwendung vor, die auf einem gesicherten Server oder lokalen Rechner liegt. Die Staging-Umgebung dient dem Test der Anwendungen unter möglichst realitätsnahen Voraussetzungen und setzt auf ähnliche Komponenten wie die Release-Version. Die Produktivumgebung dient der Verwendung des Programms im direkt angedachten Nutzungszweck beim Kunden.

Produktiv- und Staging-Umgebung entsprechen nach Möglichkeit weitgehend einander. Bei der Produktiv-Umgebung kommt es im Idealfall zu keinen Veränderungen durch die Entwickler mehr. Auch die möglicherweise ergänzte Qualitätssicherungs-Umgebung sollte der Produktiv-Umgebung möglichst ähneln. In dieser optionalen Umgebung sollen Fehler oder Bugs im Code identifiziert und behoben werden.

(ID:47486847)