9 Tipps für bessere Build Pipelines

 Wird Ihre Build Pipeline aktuellen Anforderungen noch gerecht – oder ist es Zeit für neue Impulse?
Gorodenkoff | shutterstock.com

Zu Mainframe-Zeiten gab es keine Notwendigkeit, eine Build Pipeline aufzubauen. Damals haben wir ein bisschen an den Frontpanels der Großrechner herumgespielt und der Code ist gelaufen – oder auch nicht. Softwareentwicklung war zu dieser Zeit noch eine ziemlich „straighte“, eher unkomplizierte Angelegenheit.

Heute kann jede einzelne Codezeile diverse Maßnahmen durchlaufen. Der Build-Prozess ist inzwischen so aufwändig und komplex, dass selbst mittelgroße Teams meist nicht umhinkommen, einen oder mehrere Engineers in Vollzeit dafür abzustellen, diesen zu managen. Der Build-Prozess ist im Laufe der Jahre gehörig gewachsen, um den unterschiedlichsten Problemen zu begegnen: Ist der Code zu langsam, hilft ein Optimierungsprozess. Kommt es zu Programmabstürzen, unterstützen Unit Tests. Um zu überprüfen, ob die Unit Tests richtig laufen, sind Meta-Tests nötig. Und so weiter.    

All diese Maßnahmen zahlen sich zweifellos aus. Dennoch lohnt es sich, von Zeit zu Zeit innezuhalten und sich mit dem Zustand Ihrer Build Pipeline zu befassen. Zum Beispiel, um zu überprüfen:

ob es neue Entwicklungen und Innovationen in diesem Bereich gibt oder

ob Ihre Build-Prozesse noch zeitgemäß sind.

In diesem Artikel geben wir Ihnen neun Tipps an die Hand, die Sie dabei unterstützen.

1. 1JPM nutzen

In der Vergangenheit verließen sich Java-Entwickler auf populäre Build Tools wie Ant, Maven oder Gradle, um Abhängigkeiten zu Standard-Bibliotheken zu behandeln und diverse Tests auszuführen. Das gewährleistete auch einen praktischen, zentralisierten Mechanismus, um alle Schritte des Prozesses zu organisieren. Dazu mussten diese lediglich in XML (für Ant und Maven) oder Groovy/Kotlin (für Gradle) formuliert werden.  

Mit dem Open-Source-Tool 1JPM hat das ein Ende: Es ermöglicht Ihnen, Build-Anweisungen direkt in Java zu schreiben. Dabei stellt 1JPM im Wesentlichen einen Wrapper für Maven dar. Sie können also auf dessen Infrastruktur zurückgreifen. 1JPM verwandelt Ihre Java-Build-Datei in das entsprechende Maven-Pendant – das klassische pom.xml.

2. Notebooks verwenden

Geht es darum, Code für Data-Science-Zwecke auszuliefern, sind Notebook-Formate eine beliebte Option. In einigen Umgebungen kommen sie auch als Ersatz für traditionelle Builds zum Einsatz. Das Notebook-Format kombiniert normalen Text mit Codeblöcken und Datenzugriff und ermöglicht den Rezipienten, den Textinhalt aufzunehmen und anschließend auf den Code zu klicken, um ihn auszuführen. Das bündelt alle Informationen und Data-Analytics-Schritte in einer Entität.  

Inzwischen existieren mehrere, verschiedene hochwertige Notebook-Formate, die diverse Programmiersprachen unterstützen. Dabei ist das ursprüngliche Format – das IPython Notebook (.ipynb) – weiterhin eines der gängigsten, hat jedoch weitere Formate inspiriert. Zum Beispiel:

R Markdown (.rmd), das auf der Sprache R basiert,

Quarto (.qmd), das R und Python kombiniert oder

Myst Markdown (.md), das R- und Python-Code in reguläre Markdown-Dateien überführt.

Darüber hinaus existieren auch noch „Metaformate“ wie JupyterLab (.jlpb) und Observable Notebook (.ipynb). Diese fassen mehrere Notebooks in Websites zusammen, um Daten und Informationen zu sammeln.

Die Popularität der Notebook-Formate hat dazu geführt, dass Jupyter Notebooks für weitere Sprachen angepasst wurden – in Form eines separaten Kernels, der die Kompilier- und Ausführungsarbeit übernimmt. Das bieten zum Beispiel die im Umfeld der Datenwissenschaft populären Sprachen:

MATLAB,

Julia,

Java,

Scala,

Scheme und

Octave.

3. Auf Low-Code setzen

Die Buzzwords Low-Code und No Code adressieren im Regelfall eher Nicht-Programmierer, die entwickeln wollen. Allerdings haben einige Plattformen in diesem Bereich auch Anklang unter Devs gefunden. Schließlich lassen sich damit auch weite Teile der Build Pipeline automatisieren – die Dev-Spezialisten können sich hingegen auf ihre Kernaufgaben fokussieren.

REI3 ist nur ein Beispiel für eine solche Low-Code-Lösung, mit der sich Webapplikationen mit nur wenigen Code-Zeilen erstellen lassen. Die Open-Source-Lösung wird mit MIT-Lizenz vertrieben und kann wahlweise lokal oder in der Cloud installiert werden. Für Funktionen, die in Code-Form hinzugefügt werden müssen, bietet das Tool auch einen integrierten Editor – ähnlich wie eine IDE. Es übernimmt den kompletten Build- und Distributionsprozess für Applikationen.

4. Java als Skriptsprache einsetzen

Vor etlichen Dekaden war Java eine kompilierte Sprache für große Projekte, JavaScript sein kleiner Cousin für den Webbrowser. Im Laufe der Jahre haben viele, smarte Devs den kleinen Cousin zu einem riesigen Ökosystem weiterentwickelt, das große Entwicklungsprojekte mit Just-in-Time-Kompilierung unterstützt. Java hat sich hingegen parallel in die entgegengesetzte Richtung entwickelt, hin zur Imitation einer Skriptsprache.

Inzwischen ist es allerdings möglich, ein Java-Programm in eine einzelne Datei zu schreiben – mit X.java. In diesem Fall übernimmt die Java-Infrastruktur alle Kompilierungs- und Build-Aufgaben. Entwickler, die an kleineren Projekten arbeiten, müssen sich so erst gar nicht mit der Build-Konfiguration herumschlagen.

5. Build-Kosten ermitteln

Developer fokussieren sich meist auf Metriken wie die Ausführungszeit oder den RAM-Verbrauch. Bei erfolgreichen Projekten sind sie oft damit beschäftigt, zusätzliche Anpassungs- und Konfigurationsebenen hinzuzufügen, um den Code wartbar zu gestalten. Deshalb sind viele Entwickler nicht vorbereitet auf Fragen wie:  

Wie viel wird es kosten, diesen Code auszuführen? oder

Wie viel Hardware wird dazu benötigt?

Auch an dieser Stelle können Devops-Teams auf Tools zurückgreifen, um Kosten nicht nur zu veranschaulichen, sondern auch unter Kontrolle zu halten. Das bewerkstelligen diese, indem sie im Rahmen des gesamten Build-Prozesses jeweils entsprechende Kostenschätzungen bereitstellen. So können Dev-Teams etwa ermitteln, wie viel ein Pull Request einspart – oder kostet. Empfehlenswerte Lösungen in diesem Bereich sind zum Beispiel:

Infracost und

Finout.

6. Build Pipeline dokumentieren

In den frühen Jahren der Softwareentwicklung war die Dokumentation etwas, an das eher nachträglich gedacht wurde – wenn die „wirkliche“ Arbeit erledigt war. Das hat sich in den letzten Jahren grundlegend geändert. Inzwischen ist das Thema Dokumentation – ähnlich wie die Kostenschätzung – Bestandteil des Build-Prozesses geworden.

Einige Programmiersprachen bieten zu diesem Zweck spezifische Formate – etwa JavaDoc oder PyDoc. Diese definieren eine starre Struktur für Code-Kommentare, die sich automatisch in Dokumentationsseiten für Webseiten umwandeln lassen.

Andere Sprachen gehen an dieser Stelle noch einen Schritt weiter. Manche Datenwissenschaftler, die mit R oder Python arbeiten, nutzen Tools, um ihre finale Präsentation und ihren Code gleichzeitig zu schreiben. Das funktioniert mit Packages wie:

Sweave,

Pweave oder

knitr.

Die Idee dahinter ist, die Datenanalyse-Software mit dem Datenanalyse-Text zu bündeln, sodass Tabellen, Grafiken und Abbildungen zur Laufzeit direkt aus den Rohdaten generiert werden.

7. Von domänenspezifischen Sprachen profitieren

Die Entwickler domänenspezifischer Sprachen (Domain-specific Languages; DSLs) haben zwar nicht damit gerechnet, Build Pipelines zu vereinfachen, es aber dennoch geschafft. Denn DSLs erfordern im Regelfall deutlich weniger Bibliotheken, weil ein Großteil der Komplexität bestimmter Tasks durch die Definition der Sprache selbst absorbiert wird. In einigen Fällen sind auch Semi-Standard-Tests enthalten.

In anderen Fällen ist die DSL Teil eines größeren Tool-Systems oder einer integrierten Entwicklungsumgebung, was den Build-Prozess zusätzlich simplifizieren kann. Einige gute Beispiele dafür sind:

UnrealScript, das im Bereich der Games-Entwicklung eingesetzt wird,

QuantLib, das für grundlegende Finanzanalysen angewendet wird, oder

das Robot Operating System, mit dem entsprechende Applikationen optimiert werden können.

8. Bibliotheken lokal erstellen

In der Vergangenheit waren Programmierer in der Regel froh darüber, wenn jemand anderes ihre Bibliotheken und andere Komponenten erstellte. Das Motto: Binärdatei downloaden – fertig.

Das änderte sich, nachdem kriminelle Hacker Bibliotheken zunehmend für sich entdeckt, Malware eingeschleust und Hintertüren eingebaut haben. Seitdem setzen viele Entwickler(-Teams) auf einen zusätzlichen Schritt innerhalb ihres Build-Prozesses: Sie bauen Drittanbieter-Bibliotheken auf lokaler Ebene nach. Das schließt zwar nicht aus, dass der zugrundeliegende Code frei von Kompromittierungen ist, erhöht aber die Chance, dass diese entdeckt werden.

9. Generative AI integrieren

Inzwischen dürfte sich herumgesprochen haben, dass Large Language Models (LLMs) immer besser darin werden, Code zu erstellen. Weniger offensichtlich ist hingegen bislang, wie Generative AI (GenAI) die Build Pipeline bereichern kann. Bislang experimentieren die Build Engineers dieser Welt noch mit LLMs. Zum Beispiel nutzen sie GenAI, um:

Code für High-Level-Dokumentationen zusammenzufassen.

über natürlichsprachliche Queries nachzuvollziehen, wo ein Bug zum ersten Mal aufgetreten ist.

ihren Code zu refaktorieren.

bessere und umfassendere Test-Cases zu erstellen.

LLMs dürften mit fortschreitender Entwicklung noch deutlich mehr zum Build-Prozess beitragen. Bis es so weit ist, sind weiterhin menschliche Experten gefragt, um Build Pipelines instand zuhalten.

Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!