CI/CD
CI/CD-Pipelines werden immer wichtiger, um sicherzustellen, dass Software-Updates kosteneffizient und bei gleichbleibend hoher Qualität veröffentlicht werden können. Aber wie genau funktionieren CI/CD-Pipelines und wie kann ein Projekt von ihrem Einsatz profitieren?
Dieser Newsletter beantwortet diese Fragen anhand des praktischen Beispiels einer CI/CD-Pipeline. Das Beispiel konzentriert sich auf eine CI/CD-Pipeline für ein GitHub-Repository, das ein Paket zur Implementierung von Data Vault 2.0 in dbt für verschiedene Datenbanken enthält. Daher befasst sich dieser Newsletter auch mit den Grundlagen von dbt und GitHub Actions.
Von Continuous Integration zu Data Vaults: Ein umfassender Workflow
In diesem Webinar wird erklärt, was CI/CD-Pipelines sind und welche Vorteile sie bieten. Wir werden Teile der CI/CD-Pipeline für das öffentliche datavault4dbt-Paket vorstellen, um zu demonstrieren, wie eine CI/CD-Pipeline genutzt werden kann. Das Webinar stellt die wichtigsten Funktionen von GitHub Actions vor und erläutert diese anhand von Beispielen. Dies zeigt, wie jede Funktion in der Praxis eingesetzt werden kann, und hebt die vielfältigen Möglichkeiten hervor, die GitHub Actions bietet. Ziel des Webinars ist es, die Vorteile von CI/CD-Pipelines zu erläutern und anhand eines praktischen Beispiels zu veranschaulichen, wie eine solche Pipeline aussehen kann.
Was ist CI/CD?
CI steht für Continuous Integration und CD steht für Continuous Delivery oder Continuous Deployment. Aber was genau bedeuten diese Begriffe?
Continuous Integration bezieht sich auf das regelmäßige Zusammenführen von Codeänderungen, bei dem automatisierte Tests durchgeführt werden, um potenzielle Fehler frühzeitig zu erkennen und sicherzustellen, dass die Software in einem funktionsfähigen Zustand bleibt.
Continuous Delivery beinhaltet die Bereitstellung des validierten Codes in einem Repository. Zu diesem Zweck sollten bereits CI-Tests in der Pipeline durchgeführt werden. Es umfasst auch weitere Automatisierungen, die für eine schnelle Bereitstellung erforderlich sind, wie beispielsweise die Erstellung eines produktionsreifen Builds. Der Unterschied zwischen Continuous Delivery und Continuous Deployment besteht darin, dass bei Continuous Deployment die erfolgreich getestete Software direkt in die Produktion überführt wird, während Continuous Delivery alles für die Freigabe vorbereitet, ohne sie automatisch bereitzustellen.
Continuous Deployment ermöglicht es, Änderungen durch viele kleine Releases statt durch ein einziges großes Release schnell zu implementieren. Die Tests müssen jedoch gut konfiguriert sein, da es keine manuelle Freigabe für den Übergang in die Produktion gibt.
CI/CD-Pipelines bieten durch Automatisierung eine immense Zeitersparnis. Auch die Kosten für Ressourcen, die für manuelle Tests benötigt werden, sind bei CI/CD-Pipelines geringer, da sie so konfiguriert werden können, dass Ressourcen nur für die Tests hochgefahren und danach wieder heruntergefahren werden. Da keine permanenten Ressourcen erforderlich sind, zahlen Sie nur für die Ressourcen, die während der Testlaufzeit benötigt werden.
Einführung in dbt
Die Abkürzung dbt steht für „data build tool“. Dbt ist ein Werkzeug, das die Datentransformation direkt in einem Data Warehouse ermöglicht. Es nutzt SQL-basierte Transformationen, die direkt in der dbt-Umgebung definiert, getestet und dokumentiert werden können.
Dies macht dbt zu einer hervorragenden Wahl für die Implementierung von Data Vault 2.0, da dbt verwendet werden kann, um die von Data Vault benötigten Hubs, Links und Satellites zu erstellen und zu verwalten.
Um diesen Prozess zu erleichtern, haben wir bei Scalefree das Paket datavault4dbt entwickelt. Datavault4dbt bietet viele nützliche Funktionen, wie vordefinierte Makros für Hubs, Links, Satellites, die Staging Area und vieles mehr.
Für ein tieferes Verständnis von dbt oder datavault4dbt finden Sie tiefergehende Informationen in unseren Artikeln zu diesem Thema.
Die Funktionen von GitHub Actions
GitHub Actions ist eine Funktion von GitHub, mit der Sie Workflows direkt in GitHub-Repositories erstellen und ausführen können. Sie können verschiedene Trigger für Workflows definieren, wie z. B. Pull Requests, Commits, Zeitpläne, manuelle Trigger und mehr.
Dies macht GitHub Actions ideal für den Aufbau von CI/CD-Pipelines sowohl für private als auch für öffentliche Repositories. Die Workflows sind in mehrere Jobs unterteilt, die jeweils aus mehreren Schritten bestehen. Jeder Job läuft auf einer anderen virtuellen Maschin
Innerhalb dieser Schritte können Sie benutzerdefinierte Aufgaben definieren oder externe sowie interne Workflows nutzen. Dies bietet den großen Vorteil, dass Sie in einem Workflow nicht jeden Schritt von Grund auf neu entwickeln müssen, sondern auf öffentliche Workflows zurückgreifen können, die von anderen erstellt wurden.
Die nahtlose Integration von Docker bietet zudem zahlreiche Möglichkeiten, wie beispielsweise das schnelle Einrichten verschiedener Testumgebungen, was die Erstellung einer CI/CD-Pipeline erheblich vereinfacht.
GitHub Actions ist das zentrale Werkzeug im folgenden Beispiel einer CI/CD-Pipeline.
Praktisches Beispiel: CI/CD-Pipeline für datavault4dbt
Für das öffentliche Repository des datavault4dbt-Pakets haben wir eine CI/CD-Pipeline aufgebaut, um sicherzustellen, dass alle Funktionen bei jedem Pull Request (PR) auf allen unterstützten Datenbanken weiterhin funktionieren. Wenn ein PR von einem externen Benutzer eingereicht wird, muss jemand aus unserem Entwicklerteam den Start der Pipeline genehmigen. Im Gegensatz dazu kann die Pipeline bei einem PR eines internen Benutzers automatisch durch das Hinzufügen eines bestimmten Labels gestartet werden.
Sobald die Pipeline ausgelöst wird, startet GitHub Actions automatisch eine separate virtuelle Maschine (VM) für jede Datenbank. Derzeit unterstützt das datavault4dbt-Paket AWS Redshift, Microsoft Azure Synapse, Snowflake, Google BigQuery, PostgreSQL und Exasol, sodass insgesamt sechs VMs gestartet werden. Da GitHub Actions serverless arbeitet, müssen diese VMs nicht manuell eingerichtet oder verwaltet werden.
The VMs then connect to the required cloud systems. For instance, the VM for Google BigQuery connects to Google Cloud, while the VM for AWS Redshift connects to AWS. Subsequently, the necessary resources for each database are generated, which can be done via API calls or using tools like Terraform.
Nach der Erstellung der Ressourcen werden zusätzliche, für die Tests benötigte Dateien generiert und auf die VM geladen. In unserer Beispiel-Pipeline gehören dazu Dateien wie die profiles.yml, die alle für die dbt-Verbindung zu den Datenbanken erforderlichen Informationen enthält.
Als Nächstes wird auf jeder VM ein Dockerfile verwendet, um ein Image zu erstellen, das automatisch alle Abhängigkeiten für die jeweilige Datenbank installiert. In dieser Phase wird auch Git auf jedem Image installiert, damit in einem separaten Git-Repository gespeicherte Tests auf das Image geladen werden können.
Das Laden der Tests aus einem Repository ermöglicht eine zentrale Verwaltung der Tests und stellt sicher, dass alle Änderungen beim nächsten Pipeline-Durchlauf für jede Datenbank ausgeführt werden. Sobald die Images erstellt sind, werden aus diesen Images Container erstellt, in denen Tests mit verschiedenen Parametern durchgeführt werden. Nach Abschluss aller Tests werden die Container heruntergefahren und die Ressourcen bei den jeweiligen Cloud-Anbietern standardmäßig gelöscht.
Die Testergebnisse sind in GitHub Actions vollständig sichtbar, wobei erfolgreiche und fehlgeschlagene Tests klar gekennzeichnet sind.
Wenn die Pipeline manuell gestartet wird, besteht zusätzlich die Möglichkeit festzulegen, ob nur bestimmte ausgewählte Datenbanken getestet werden sollen und ob die Ressourcen in den Cloud-Systemen nach den Tests erhalten bleiben sollen. Dies ermöglicht es Entwicklern, die Daten in den Datenbanken im Fehlerfall genauer zu untersuchen.
Diese Pipeline bietet zahlreiche Vorteile für die Entwicklung des datavault4dbt-Pakets. Sie ermöglicht es, bei jeder Änderung auf allen unterstützten Datenbanken nach Fehlern zu suchen, ohne viel Zeit für die Erstellung von Testressourcen aufwenden zu müssen. Gleichzeitig spart sie Kosten, da alle Ressourcen nur so lange wie nötig laufen und nach den Tests sofort heruntergefahren werden.
Die Verwaltung der Pipeline wird auch durch GitHub vereinfacht, da alle Variablen und Secrets direkt in GitHub gespeichert werden können, wodurch alle Konfigurationen an einem zentralen Ort gebündelt sind. Sobald die Pipeline eingerichtet ist, kann sie problemlos um zusätzliche Datenbanken erweitert werden, die in Zukunft unterstützt werden könnten.
Letztendlich ist dies nur ein Beispiel dafür, wie eine CI/CD-Pipeline aussehen kann. Solche Pipelines sind so vielfältig wie die Software, für die sie konzipiert sind. Wenn wir Ihr Interesse geweckt haben und Sie weitere Fragen zu einer möglichen Pipeline für Ihr Unternehmen haben, können Sie uns gerne kontaktieren.
Fazit
Dieser Newsletter beleuchtet die Vorteile und Funktionsweisen von CI/CD-Pipelines in der agilen Softwareentwicklung. Veranschaulicht an einem praktischen Beispiel mit einem GitHub-Repository und einem dbt-Paket zur Implementierung von Data Vault 2.0, zeigt er, wie Werkzeuge wie GitHub Actions die Automatisierung und Effizienz in Bereitstellungsprozessen steigern können.