Build Chain

Veröffentlicht am 15.11.2021 von Marc Willmann
Lesezeit ca. 0 Min.

Wie wir Software entwickeln
Teil 3: Build-Chain

Moderne Software - auch Websites - besteht aus zahlreichen Softwarepaketen. Einige davon entwickeln wir für das aktuelle Projekt individuell. Für viele Standardaufgaben greifen wir auf externen Code zurück, der uns hilft, schnell zum Ziel zu kommen und das Rad nicht neu zu erfinden. Hier kommt es insbesondere im zeitlichen Verlauf darauf an, welche Version von welchem Softwarepaket installiert war - nur in der jeweiligen Kombination funktioniert am Ende auch die Gesamtsoftware. Um diese Aufgabe in den Griff zu bekommen, gibt es Paketmanager, die Abhängigkeiten von Softwarepaketen auflösen und darüber Buch führen, welche Versionen aktiv sind. Und über unsere Versionsverwaltung können wir damit zu einem späteren Zeitpunkt alle Softwarepakete in genau der Version installieren, wie wir sie für den jeweiligen Stand unserer Software benötigen. 

Damit eine moderne Internetpräsenz funktioniert, müssen ziemlich viele Dinge zusammenspielen. Neben den Softwarepaketen, die für die Funktionalität benötigt werden, müssen auch z.B. Frontend-Assets (in der Regel CSS und JavaScript) gebaut werden, die dafür sorgen, dass sich die Website auch im Browser so verhält, wie unsere Kunden das wünschen. 

Weil wir sicherstellen möchten, dass unsere Applikation immer funktioniert, bauen wir die Website bei Änderungen ziemlich oft zusammen. Dabei muss ziemlich viel beachtet werden und es muss in der richtigen Reihenfolge passieren. Aus diesem Grund haben wir diesen Vorgang automatisiert. Das ist die Build-Chain.

Durch die Build-Chain haben wir zudem sichergestellt, dass wir das Projekt und alle benötigten Pakete unabhängig vom Entwickler und dem Entwicklungsrechner zusammenbauen können. Und wir haben einen Automatismus geschaffen, der bei jeder Änderung vollautomatisch sicherstellt, dass unser Projekt anschließend weiterhin zusammengebaut werden kann. 

Dieser Automatismus ist wie geschaffen, weitere Aufgaben zu übernehmen, die ggf. recht lange dauern und von denen wir möchten, dass sie bei jeder Änderung ausgeführt werden: 

Coding-Guidelines und Softwarequalität

Wir arbeiten nach Coding-Guidelines und stellen über Tests in unserer Build-Chain sicher, dass diese auch eingehalten werden. Dies führt zu übersichtlicheren Projekten und besserem Code.

Neben statischer Code-Analyse und Lintern haben wir Test-Suites im Einsatz, die sicherstellen, dass der von uns produzierte Code funktioniert und mit anderen Komponenten zusammenarbeitet.

Da wir beim Bau und dem Deployment diese Tests automatisiert ausführen, erkennen wir sehr schnell, wenn während der Entwicklung an anderer Stelle etwas kaputt geht - bevor es der Code auf die Produktionsumgebung schafft.

Und ausliefern bitte! 

Erst wenn wir unseren Code auf dem Zielserver haben und alles funktioniert, ist unsere Arbeit getan. Das Ausliefern unserer Software auf einen Server nennen wir Deployment. Auf dem Zielserver möchten wir nur Softwarekomponenten haben, die dort wirklich im Einsatz sind und gebraucht werden. Durch den Bau unserer Applikation in der Build-Chain können wir das Ergebnis - die fertige Anwendung - durch einfache Netzwerkprotokolle, die auf jedem Server vorhanden sind, auf das Zielsystem kopieren. Es liegt nahe, auch das Deployment zu automatisieren. Und natürlich haben wir auch das getan und diesen Vorgang in unsere Build-Chain integriert. 

Das klingt ganz schön kompliziert? Auf den ersten Blick: ja. Aber treten wir einen kleinen Schritt zurück und betrachten, was wir bisher schon erreicht haben: 

Wir können jeden beliebigen Zustand des Projektes aus der Vergangenheit wiederherstellen, alle Komponenten in der damals vorhandenen Version herunterladen, zusammenbauen und auf jedem beliebigen Server ausliefern. Automatisiert.

Unsere Build-Chain wird zentral über unseren Gitlab-Server ausgeführt, und zwar jedes Mal, wenn ein Entwickler eine Änderung in das System übermittelt. Durch die häufigen automatisierten Tests finden wir Fehler und Verstöße gegen unsere Coding-Guidelines, direkt wenn sie entstehen und können sie direkt lösen. 

Im nächsten Teil dieser Artikelserie stellen wir unseren Review-Server vor, für den uns unsere Kunden lieben.

Ihr Feedback

Schreiben Sie uns Ihre Meinung zu unserem Blog-Beitrag. Bei Fragen beraten wir Sie gerne und freuen uns über Ihre Nachricht!

Ihre E-Mail Adresse wird nicht veröffentlicht.

* Diese Felder sind erforderlich

Kommentar schreiben

Weitere Artikel

03.11.2021 | Marc Willmann

Lokale Entwicklungsumgebung

Damit ein Entwickler an einem Projekt arbeiten kann, benötigt er eine Kopie davon auf seinem Rechner. Das Aufsetzen eines neuen Projekts dauert bei uns nicht länger, als sich eine frische Tasse Kaffee aus der Küche zu holen.

Weiterlesen

24.11.2021 | Marc Willmann

Continuous Deployment

Der richtige Zeitpunkt zum Ausliefern eines Features ist aus unserer Sicht: Wenn es fertig ist. Warum das so ist und warum Kunden unseren Review-Server lieben, beschreibe ich in diesem Teil der Serie "Wie wir Software entwickeln"

Weiterlesen