Im vorherigen Blogbeitrag haben wir verschiedene DevOps-Funktionen in Snowflake vorgestellt. Diese Funktionen sind die Bausteine, mit denen Sie Ihre Snowflake-Infrastruktur als Code pflegen – und das automatisiert.
In diesem Beitrag zeigen wir, wie sich diese Funktionen kombinieren lassen, um CI/CD-Pipelines für die automatisierte Bereitstellung von Snowflake-Infrastruktur aufzubauen. Dabei setzen wir auf native Snowflake-Funktionen wie CREATE OR ALTER, die Git-Integration oder EXECUTE IMMEDIATE FROM. Als Repository-Dienst nutzen wir GitHub, als Orchestrator GitHub Actions.
Starten wir mit einer kurzen Einführung in GitHub-Actions-Workflows.
GitHub-Actions-Workflows
GitHub Actions ist eine leistungsstarke, direkt in GitHub integrierte CI/CD-Plattform, mit der Entwickler Software-Workflows über ereignisgesteuerte Pipelines automatisieren können. Grundlage sind Workflows, die in YAML-Dateien im Verzeichnis .github/workflows/ Ihres Repositories abgelegt werden. Jeder Workflow kann aus einem oder mehreren Jobs bestehen, die auf virtuellen Maschinen – sogenannten Runnern – laufen. Diese Runner kann GitHub für Sie hosten, sodass Sie sich um den Betrieb nicht kümmern müssen. Beim Auslösen des Workflows wird Ihrer Pipeline automatisch ein Runner zugewiesen – alternativ können Sie auch einen selbst gehosteten Runner einsetzen.
Für eine Pipeline müssen Sie mehrere zentrale Elemente definieren:
Trigger
Das kann ein Ereignis im Repository sein (z. B. push, pull_request usw.), ein geplanter Cron-Job oder ein manueller Trigger.
Runner-Umgebung
Hier legen Sie fest, wo Ihr Code läuft – also das Betriebssystem des Runners. Gängige Beispiele sind ubuntu-latest oder windows-latest.
Aufbau der Automatisierung
Als Nächstes definieren Sie die eigentliche Automatisierung: eine Abfolge von Schritten, die ausgeführt werden sollen. Wichtig dabei: Bei jedem Lauf startet die Runner-Maschine in einem standardmäßigen, frischen Zustand. Das heißt, Sie müssen die Umgebung für Ihren konkreten Job vorbereiten – etwa benötigte Sprachen installieren (z. B. Python), den Code aus Ihrem Repository abrufen und Umgebungsvariablen einlesen. Einzelne Schritte können aus Shell-Befehlen, Skriptaufrufen oder vorgefertigten Actions bestehen. Jeder Schritt kann zudem auf Kontextinformationen zugreifen, etwa ${{ github.event_name }} oder ${{ secrets.SF_ACCOUNT_ID }}.
Diese Eigenschaften machen GitHub Actions zu einer guten Wahl für unterschiedlichste CI/CD-Pipelines: Sie verwalten Datenbank-Zugangsdaten sicher, führen SQL-Skripte aus, rollen Änderungen über mehrere Umgebungen hinweg aus und sehen jederzeit nach, wer was geändert hat – inklusive integrierter Versionskontrolle.
Snowflake-CI/CD-Pipeline für die Account-Infrastruktur
Wir arbeiten lokal in VS Code und entwickeln dort die SQL-Skripte sowie die YAML-Definition für den GitHub-Actions-Workflow. Sobald alles steht, pushen wir die Änderungen ins Remote-Repository, erstellen einen Pull Request und mergen die Änderungen in unseren Dev-Branch. Wie das Diagramm zeigt, kommen dafür mehrere Snowflake-Funktionen zum Einsatz. Außerdem bauen wir die CI/CD-Pipeline in zwei Varianten:
1 Mit der Git-Erweiterung in Snowflake Bei diesem Ansatz dient GitHub Actions nur als Orchestrator. Dank der Git-Erweiterung lässt sich der gesamte Code direkt in Snowflake ausführen.
2 Code auf einem GitHub-Runner mit SnowCLI ausführen Wenn Sie die Git-Erweiterung in Snowflake nicht einsetzen möchten, gibt es eine Alternative: Sie führen den Code direkt auf der Runner-Maschine über das Snowflake Command Line Interface ( SnowCLI) aus. Auch diese Variante zeigen wir.
Snowflake-Infrastruktur anlegen
Legen wir zunächst die Infrastruktur an und verteilen sie auf mehrere SQL-Dateien.
Unsere Warehouses:
USE ROLE sysadmin;
--ELT warehouse definition
CREATE WAREHOUSE IF NOT EXISTS elt WITH
WAREHOUSE_SIZE = XSMALL
AUTO_SUSPEND = 60
AUTO_RESUME = True
INITIALLY_SUSPENDED = True;
--developers warehouse definition
CREATE WAREHOUSE IF NOT EXISTS developers WITH
WAREHOUSE_SIZE = SMALL
AUTO_SUSPEND = 120
AUTO_RESUME = True
INITIALLY_SUSPENDED = True;
Außerdem brauchen wir eine Rolle:
/*
* Role name: LOADER
* Description: Used by ELT pipelines to load data */
*/
USE ROLE securityadmin;
CREATE OR ALTER ROLE loader;
Und schließlich Datenbank und Schema:
/*
* DB name: DEVOPS
* Description: Used for showcasing Snowflake DevOps capabilities
*/
use role sysadmin;
create or alter database devops;
------------------------SCHEMAS------------------------
/*
* Schema name: ADMIN
* Description: To keep all admin stuff at one place
*/
Code erweitern
CI/CD-Pipeline mit Git Stage
Die ersten SQL-Skripte stehen – jetzt geht es an den GitHub-Actions-Workflow. Dieser Workflow nutzt die Git-Erweiterung in Snowflake. Voraussetzung ist eine aktive Integration zwischen Ihrem Snowflake-Account und Ihrem GitHub-Repository. Wie Sie diese Integration einrichten, haben wir in einem eigenen Beitrag zur Git-Integration von Snowflake beschrieben.
name: Deploying Snowflake objects with CLI v1
env:
SNOWFLAKE_ACCOUNT: ${{ secrets.SF_ACCOUNT }}
SNOWFLAKE_USER: ${{ secrets.SF_USER }}
SNOWFLAKE_PASSWORD: ${{ secrets.SF_PASSWORD }}
SNOWFLAKE_DATABASE: ${{ secrets.SF_DATABASE }}
SNOWFLAKE_SCHEMA: ${{ secrets.SF_SCHEMA }}
SNOWFLAKE_ROLE: ${{ secrets.SF_ROLE }}
SNOWFLAKE_WAREHOUSE: ${{ secrets.SF_WAREHOUSE }}
on:
workflow_dispatch:
jobs:
deploy-Snowflake-changes:
Code erweitern
Gehen wir den Code Schritt für Schritt durch.
Zu Beginn konfigurieren wir die Umgebungsvariablen, die für die Verbindung zu Snowflake nötig sind. Die Werte stammen aus den GitHub Secrets. Anschließend definieren wir den Trigger – hier workflow_dispatch, sodass der Workflow manuell aus dem Repository heraus gestartet werden muss.
Der Rest ist recht unkompliziert. Wir müssen SnowCLI auf der GitHub-Runner-Maschine installieren, damit wir:
- uns mit Snowflake verbinden können
- die erforderlichen Befehle absetzen können
Snowflake stellt dafür eine native GitHub Action bereit, die Setup und Verbindungsmanagement vereinfacht.
Zuerst synchronisieren wir den Snowflake-Git-Repository-Stage über den Befehl ALTER GIT REPOSITORY mit dem Remote-Repository. Damit landen die neuesten Änderungen direkt im Git Stage innerhalb von Snowflake.
Anschließend nutzen wir EXECUTE IMMEDIATE, um Code direkt aus unseren SQL-Dateien auszuführen. So deployen wir Warehouses, Rollen sowie Datenbanken samt Schemas. Und das war's – ein schlanker, effektiver Workflow, um Änderungen an Ihrer Snowflake-Infrastruktur automatisch als Code auszurollen.
CI/CD-Pipeline mit Code-Ausführung auf dem GitHub-Runner
Bauen wir eine ähnliche Pipeline – diesmal allerdings führen wir alles direkt auf der GitHub-Runner-Maschine aus, ohne den Snowflake Git Stage zu nutzen. So nützlich der Git Stage auch ist: Er hat einige Einschränkungen – er ist nur lesend nutzbar und für Repositories hinter privaten Netzwerken nicht erreichbar. In manchen Szenarien sind das gute Gründe, auf die Git-Integration von Snowflake zu verzichten. Hier ist unsere YAML-Workflow-Definition:
name: Deploying Snowflake objects with cli v2
env:
SNOWFLAKE_ACCOUNT: ${{ secrets.SF_ACCOUNT }}
SNOWFLAKE_USER: ${{ secrets.SF_USER }}
SNOWFLAKE_PASSWORD: ${{ secrets.SF_PASSWORD }}
SNOWFLAKE_DATABASE: ${{ secrets.SF_DATABASE }}
SNOWFLAKE_SCHEMA: ${{ secrets.SF_SCHEMA }}
SNOWFLAKE_ROLE: ${{ secrets.SF_ROLE }}
SNOWFLAKE_WAREHOUSE: ${{ secrets.SF_WAREHOUSE }}
on:
workflow_dispatch:
jobs:
deploy-Snowflake-changes:
name: Snowflake infrastructure deployment
Code erweitern
Schauen wir uns die Unterschiede zur vorherigen Version an. Diesmal müssen wir den Code aus dem Remote-Repository auf die Runner-Maschine holen. Dafür nutzen wir eine andere Action namens checkout, die genau das übernimmt.
Anschließend setzen wir wieder SnowCLI ein – diesmal allerdings führen wir den Code aus Dateien aus, die auf der Runner-Maschine liegen, statt aus Dateien im Repository-Stage.
Verbesserungsmöglichkeiten
Das war ein einfaches Beispiel dafür, wie sich eine grundlegende CI/CD-Pipeline für das Deployment von Snowflake-Infrastruktur entwickeln lässt. Bis zur Produktionsreife gibt es viel Spielraum. In einer realen Umgebung hätten Sie:
- eigene Pipelines pro Umgebung (dev, prod)
- Trigger auf Push- und Pull-Request-Events, beschränkt auf bestimmte Branches
- unterschiedliche Schritte für Push- und Pull-Request-Events
Wünschenswert wäre außerdem ein "Plan"-Schritt wie in Terraform, der vor jeder Änderung anzeigt, welche Ressourcen angelegt, aktualisiert oder gelöscht werden. Ich hoffe, dass es solche Funktionen auch in den nativen Snowflake-Features geben wird.
Fazit
In diesem Beitrag haben wir gezeigt, wie sich die nativen DevOps-Funktionen von Snowflake für Continuous Integration und Deployment einsetzen lassen. Wir haben eine CI/CD-Pipeline mit einem GitHub-Actions-Workflow umgesetzt, um Snowflake-Infrastrukturobjekte als Code direkt aus unserem Remote-Repository bereitzustellen – einfach, indem wir Updates von lokalen Maschinen ins Repo pushen.
Dies ist der letzte Teil unserer Serie zu DevOps in Snowflake. Wir haben das Thema in drei Blogbeiträgen behandelt:
- Ein tiefer Einblick in die Git-Integration von Snowflake
- CI/CD und DevOps in Snowflake (Teil 1): Umfassender Überblick über Funktionen und Tools
- CI/CD und DevOps in Snowflake (Teil 2): Schritt-für-Schritt-Anleitung zur Umsetzung
Tomáš Sobotík·Senior Data Engineer & Snowflake SME bei Norlys
Tomas ist langjähriger Snowflake Data SuperHero und ausgewiesener Snowflake-Experte. Seine Erfahrung in der Datenwelt reicht über mehr als ein Jahrzehnt zurück; in dieser Zeit war er als Snowflake Data Engineer, Architekt und Admin in Projekten unterschiedlichster Branchen und Technologien tätig. Tomas ist ein zentrales Community-Mitglied, das sein Wissen aktiv teilt und andere inspiriert. Außerdem ist er O'Reilly-Instructor und leitet Live-Online-Trainings.