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.