An dem Webinar teilnehmen
In der agilen Softwareentwicklung werden CI/CD-Pipelines immer wichtiger, um sicherzustellen, dass Software-Updates kostengünstig und in hoher Qualität veröffentlicht werden können. Aber wie genau funktionieren CI/CD-Pipelines, und wie kann ein Projekt von ihrer Nutzung profitieren?
Dieser Newsletter soll diese Fragen anhand eines praktischen Beispiels für eine CI/CD-Pipeline beantworten. 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 über verschiedene Datenbanken hinweg enthält. Daher wird dieser Newsletter auch die Grundlagen von dbt und GitHub Actions behandeln.
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?
Unter kontinuierlicher Integration versteht man das regelmäßige Zusammenführen von Codeänderungen, wobei automatisierte Tests durchgeführt werden, um mögliche Fehler frühzeitig zu erkennen und sicherzustellen, dass die Software in einem funktionsfähigen Zustand bleibt.
Bei Continuous Delivery wird der validierte Code in einem Repository zur Verfügung gestellt. Zu diesem Zweck sollten in der Pipeline bereits CI-Tests durchgeführt werden. Es umfasst auch weitere Automatisierungen, die für eine schnelle Bereitstellung erforderlich sind, wie die Erstellung eines produktionsbereiten Builds. Der Unterschied zwischen Continuous Delivery und Continuous Deployment besteht darin, dass bei Continuous Deployment die erfolgreich getestete Software direkt für die Produktion freigegeben wird, während bei Continuous Delivery alles für die Freigabe vorbereitet wird, ohne dass es automatisch bereitgestellt wird.
Die kontinuierliche Bereitstellung ermöglicht eine schnelle Umsetzung von Änderungen durch viele kleine Versionen anstelle einer großen Version. Allerdings müssen die Tests gut konfiguriert sein, da es keinen manuellen Übergang zur Produktion gibt.
CI/CD-Pipelines bieten eine immense Zeitersparnis durch Automatisierung. Auch die Kosten für die Ressourcen, die für manuelle Tests benötigt werden, sind mit CI/CD-Pipelines geringer, da sie so konfiguriert werden können, dass Ressourcen nur für Tests hochgefahren und danach wieder heruntergefahren werden. Da keine permanenten Ressourcen erforderlich sind, zahlen Sie nur für die während der Testlaufzeit benötigten Ressourcen.
Einführung in dbt
Die Abkürzung dbt steht für "data build tool". dbt ist ein Werkzeug, das die Datentransformation direkt innerhalb eines data warehouse ermöglicht. Es verwendet SQL-basierte Transformationen, die direkt in der dbt-Umgebung definiert, getestet und dokumentiert werden können.
Das macht dbt zu einer ausgezeichneten Wahl für die Umsetzung Data Vault 2.0 as dbt kann verwendet werden, um die von Data Vault benötigten Hubs, Links und Satelliten zu erstellen und zu verwalten.
Um diesen Prozess zu erleichtern, haben wir bei Scalefree das datavault4dbt-Paket. Datavault4dbt bietet viele nützliche Funktionen, wie z. B. vordefinierte Makros für Hubs, Links, Satelliten, den Staging-Bereich und vieles mehr.
Für ein tieferes Verständnis von dbt oder datavault4dbtlesen Sie bitte einen unserer Artikel zu diesem Thema.
Die Möglichkeiten von GitHub-Aktionen
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 Auslöser für Workflows definieren, z. B. Pull Requests, Commits, Zeitpläne, manuelle Auslöser und mehr.
Dadurch ist GitHub Actions ideal für den Aufbau von CI/CD-Pipelines für private und öffentliche Repositories. Die Arbeitsabläufe sind in mehrere Aufträge unterteilt, die jeweils aus mehreren Schritten bestehen. Jeder Auftrag wird auf einer anderen virtuellen Maschine ausgeführt.
Innerhalb dieser Schritte können Sie benutzerdefinierte Aufgaben definieren oder externe oder interne Workflows verwenden. Dies bietet den großen Vorteil, dass Sie nicht alles in einem Workflow von Grund auf neu entwickeln müssen, sondern öffentliche Workflows nutzen können, die von anderen erstellt wurden.
Die nahtlose Integration von Docker bietet zudem zahlreiche Möglichkeiten, wie z.B. das schnelle Einrichten verschiedener Testumgebungen, was die Erstellung einer CI/CD-Pipeline erheblich vereinfacht.
GitHub Actions ist das Schlüsselwerkzeug in dem 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 eingerichtet, um sicherzustellen, dass alle Funktionen mit jeder Pull-Anforderung (PR) für alle 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 ein PR von einem internen Benutzer automatisiert werden, indem ein bestimmtes Label hinzugefügt wird, um die Pipeline zu starten.
Sobald die Pipeline ausgelöst wird, startet GitHub Actions automatisch eine separate virtuelle Maschine (VM) für jede Datenbank. Derzeit unterstützt das Paket datavault4dbt AWS Redshift, Microsoft Azure Synapse, Snowflake, Google BigQuery, PostgreSQL und Exasol, sodass insgesamt sechs VMs gestartet werden. Da GitHub Actions serverlos arbeitet, müssen diese VMs nicht manuell eingerichtet oder verwaltet werden.
Die VMs stellen dann eine Verbindung zu den erforderlichen Cloud-Systemen her. Zum Beispiel verbindet sich die VM für Google BigQuery mit Google Cloud, während die VM für AWS Redshift mit AWS verbunden wird. Anschließend werden die erforderlichen Ressourcen für jede Datenbank generiert, was über API-Aufrufe oder mithilfe von Tools wie Terraform erfolgen kann.
Nachdem die Ressourcen erstellt wurden, werden zusätzliche Dateien, die für die Tests benötigt werden, generiert und in die VM geladen. In unserer Beispielpipeline sind dies Dateien wie profiles.yml, die Informationen enthalten, die dbt für die Verbindung mit den Datenbanken benötigt.
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 Tests, die in einem separaten Git-Repository gespeichert sind, 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 für jede Datenbank während des nächsten Pipelinelaufs ausgeführt werden. Sobald die Images erstellt sind, werden Container mit diesen Images erstellt, in denen Tests mit verschiedenen Parametern durchgeführt werden. Nach Abschluss aller Tests werden die Container heruntergefahren, und standardmäßig werden die Ressourcen bei den jeweiligen Cloud-Anbietern gelöscht.
Die Testergebnisse sind in GitHub Actions vollständig sichtbar, wobei erfolgreiche und fehlgeschlagene Tests deutlich gekennzeichnet sind.
Wird die Pipeline manuell gestartet, kann zusätzlich festgelegt werden, ob nur bestimmte ausgewählte Datenbanken getestet werden sollen und ob die Ressourcen auf den Cloud-Systemen nach den Tests nicht gelöscht werden sollen. Dies ermöglicht es den Entwicklern, die Daten auf den Datenbanken im Falle eines Fehlers genauer zu untersuchen.
Diese Pipeline bietet zahlreiche Vorteile für die Entwicklung des datavault4dbt-Pakets. Sie ermöglicht das Testen auf Fehler in jeder der unterstützten Datenbanken bei jeder Änderung, ohne viel Zeit für die Erstellung von Testressourcen aufzuwenden. 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 durch GitHub ebenfalls vereinfacht, da alle Variablen und Geheimnisse direkt in GitHub gespeichert werden können und somit ein zentraler Ort für alles zur Verfügung steht. Sobald die Pipeline eingerichtet ist, kann sie leicht erweitert werden, um zusätzliche Datenbanken einzubeziehen, die in Zukunft unterstützt werden könnten.
Letztlich 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 entwickelt werden. Wenn wir Ihr Interesse geweckt haben und Sie weitere Fragen zu einer möglichen Pipeline für Ihr Unternehmen haben, Bitte kontaktieren Sie uns.
Kurze Zusammenfassung
In diesem Newsletter werden die Vorteile und die Funktionsweise von CI/CD-Pipelines in der agilen Softwareentwicklung anhand eines praktischen Beispiels mit einem GitHub-Repository und einem dbt-Paket für die Implementierung von Data Vault 2.0 erläutert, wobei Tools wie GitHub Actions für die Automatisierung und Effizienz der Bereitstellungsprozesse hervorgehoben werden.
Wenn Sie mehr über die Implementierung von Continuous Deployment in Data Vault erfahren möchten, sollten Sie sich an unserem nächstes Webinar am 10. September, 14 Uhr MESZ!
- Damian Hinz (Scalefree)
Updates und Support erhalten
Bitte senden Sie Anfragen und Funktionswünsche an [email protected].
Für Anfragen zu Data Vault-Schulungen und Schulungen vor Ort wenden Sie sich bitte an [email protected] oder registrieren Sie sich unter www.scalefree.com.
Um die Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio zu unterstützen, wurde eine Schablone implementiert, die zum Zeichnen von Data Vault-Modellen verwendet werden kann. Die Schablone ist erhältlich bei www.visualdatavault.com.
