settings
OTEX_BIG
Süddeutsche Zeitung Institut Auszeichnung
Image
Alle DevOps Schulungen

Schulung Database DevOps: CI/CD für SQL Server

Schema Change Management, automatisierte Tests und Deployment-Pipelines

3 Tage / S6855
Neues Seminar
Per E-Mail senden

Schulungsformen

Offene Schulung

  • Dritter Mitarbeitende kostenfrei
  • Learning & Networking in einem. Garantierte Durchführung ab 1 Teilnehmenden.
Präsenz Online
Termin auswählen

Inhouse-/Firmenschulung

  • 3 Tage - anpassbar
  • Termin nach Wunsch
  • In Ihrem Hause oder bei der GFU
  • Preis nach Angebot
  • Lernumgebung in der Cloud
  • Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Unverbindlich anfragen

Individualschulung

  • 3 Tage - anpassbar
  • Termin nach Wunsch
  • In Ihrem Hause oder bei der GFU
  • Preis nach Angebot
  • Lernumgebung in der Cloud
  • 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Unverbindlich anfragen

Beschreibung

In den meisten Organisationen ist die Datenbank das letzte manuelle Glied in der CI/CD-Kette. Applikationscode wird automatisch gebaut, getestet und deployed - in Minuten, mehrfach täglich, mit Rollback-Fähigkeit. Datenbankänderungen dagegen werden per SQL-Script per Hand eingespielt - oft am Freitagabend, mit Downtime, ohne Tests, mit einem Rollback-Plan, der aus „hoffentlich funktioniert das Backup" besteht.
Das ist nicht nur riskant, es ist auch langsam. Jede Feature-Entwicklung, die eine Schema-Änderung braucht (neue Spalte, neuer Index, neue Stored Procedure), wird zum Flaschenhals: Der Entwickler hat den Code in 2 Stunden geschrieben, aber die Datenbank-Änderung wartet 3 Tage auf den DBA, der sie manuell in Staging und Produktion einspielt.
Database DevOps löst dieses Problem: Schema-Änderungen werden wie Code versioniert (in Git), automatisch getestet (Unit Tests für Stored Procedures, Integrationstests für Schema-Konsistenz), automatisch deployed (Pipeline baut DacPac oder führt Migrations aus) und automatisch validiert (Smoke Tests nach Deployment). Das Ergebnis: Datenbankänderungen werden genauso schnell, sicher und reproduzierbar wie Applikationsänderungen.
Dieses dreitägige Seminar führt durch den gesamten Weg - von „SQL-Scripts per E-Mail verschicken" bis zur vollständig automatisierten Pipeline. Am Ende steht nicht nur Wissen, sondern eine funktionierende Demo-Pipeline , die als Vorlage für die eigene Organisation dient.


Tauchen Sie tiefer ein mit einer weiteren DevOps Schulung aus unserem Seminarangebot.

Schulungsziel

Jede teilnehmende Person verlässt das Seminar mit einer funktionierenden Database-CI/CD-Pipeline (Build, Test, Deploy), praktischer Erfahrung mit SSDT/DacPac UND Flyway, automatisierten Datenbanktests (tSQLt, 5+ Testfälle), einem Verständnis von Zero-Downtime-Deployments (Expand-Contract-Pattern), einer Drift-Detection-Lösung und einem 90-Tage-Einführungsplan für die eigene Organisation.

Details

Inhalt

Tag 1: Versionierung und Schema Change Management
1. Warum die Datenbank das letzte DevOps-Silo ist
  • Ziele und Erwartungen der Teilnehmenden
    • Klärung individueller Lernziele und Erwartungen für ein praxisnahes und relevantes Seminar
  • Das Problem: Applikations-CI/CD ist Standard (GitHub Actions, GitLab CI, Azure DevOps Pipelines), aber Datenbank-Deployments bleiben manuell. Typische Symptome: SQL-Scripts per E-Mail oder Fileshare, „works on my machine"-Probleme (Dev-Schema ≠ Staging ≠ Produktion), keine Versionierung (welches Script wurde wann auf welcher Umgebung ausgeführt?), keine Tests (Stored Procedures werden nie getestet), Downtime bei jedem Deployment.
  • Database DevOps-Prinzipien: Alles in Git (Schema, Stored Procedures, Referenzdaten, Migrations), automatisierte Tests (Unit Tests, Integrationstests, Schema-Validierung), automatisierte Deployments (Pipeline statt DBA-Handbuch), Environments (Dev -> Test -> Staging -> Produktion, identische Pipeline), Rollback-Fähigkeit (nicht „Backup zurückspielen", sondern kontrolliertes Rückgängigmachen).
  • Kulturwandel: DBA und Entwickler arbeiten zusammen statt gegeneinander. Der DBA wird nicht arbeitslos - er wird zum Database Reliability Engineer: Pipeline bauen, Standards setzen, Performance überwachen, statt Scripts manuell einspielen.
  • Praxis-Übung: Pain-Point-Analyse - Teilnehmende beschreiben ihren aktuellen Datenbank-Deployment-Prozess: Wie viele manuelle Schritte? Wie lange dauert ein Deployment? Wie oft geht etwas schief? Wo sind die größten Risiken?
2. State-based vs. Migration-based: Die fundamentale Architekturentscheidung
  • State-based Ansatz (SSDT / DacPac / SqlPackage): Das Datenbankprojekt beschreibt den Zielzustand (jede Tabelle, jeder Index, jede Stored Procedure als CREATE-Statement). Beim Deployment vergleicht SqlPackage den Ist-Zustand der Zieldatenbank mit dem Soll-Zustand im DacPac und generiert automatisch ein Diff-Script (ALTER, CREATE, DROP). Vorteil: Einfach zu verstehen, deklarativ, automatisch. Nachteil: Bei komplexen Änderungen (Spalte umbenennen, Tabelle aufteilen, Daten transformieren) versagt der automatische Diff - manuelle Pre/Post-Deployment-Scripts nötig.
  • Migration-based Ansatz (Flyway / Liquibase / EF Core Migrations): Jede Schema-Änderung wird als nummeriertes Migrations-Script gespeichert (V001__create_customer_table.sql, V002__add_email_column.sql). Beim Deployment werden alle noch nicht angewendeten Migrations in Reihenfolge ausgeführt. Eine Metadaten-Tabelle (flyway_schema_history) dokumentiert, welche Migrations bereits angewendet wurden. Vorteil: Volle Kontrolle über jeden Schritt, auch komplexe Datenmigrationen. Nachteil: Manuelle Script-Erstellung, kein automatischer Diff.
  • Entscheidungsmatrix: State-based (wenn: viele Umgebungen, relativ einfache Änderungen, starke Tool-Integration gewünscht, Microsoft-Stack). Migration-based (wenn: komplexe Datenmigrationen, Kontrolle über jedes Statement nötig, Open-Source-Präferenz, Multi-Datenbank-Support). Hybridmodell: SSDT für Schema + Flyway für Datenmigrations-Scripts.
  • Praxis-Übung: Dieselbe Schema-Änderung (neue Tabelle + Spalte umbenennen + Referenzdaten einfügen) mit SSDT/DacPac UND mit Flyway durchführen. Vergleich: Was generiert SSDT automatisch? Wo muss manuell eingegriffen werden? Wo hat Flyway die Nase vorn?
3. SSDT / SQL Database Projects: State-based Schema Management
  • SQL Database Project in Visual Studio / Azure Data Studio: Datenbankprojekt erstellen, bestehendes Schema importieren (Import from Database), Projektstruktur (Schemas, Tables, Stored Procedures, Functions, Views, Security - alles als .sql-Dateien). Build: Projekt kompilieren -> DacPac (Data-Tier Application Package). Schema Compare: Projekt vs. Datenbank vergleichen -> Diff-Report.
  • Pre- und Post-Deployment-Scripts: Für Logik, die der automatische Diff nicht abdeckt: Referenzdaten, Datentransformationen, Berechtigungen, Seed Data. Pre-Deployment: VOR dem Schema-Update (z.B. Daten sichern). Post-Deployment: NACH dem Schema-Update (z.B. Referenzdaten laden, Berechtigungen setzen).
  • Refactoring-Support: Rename, Move to Schema, Expand Wildcards - SSDT dokumentiert Refactorings in einer refactorlog.xml, damit SqlPackage die Änderung erkennt (Rename statt Drop+Create -> kein Datenverlust).
  • SqlPackage.exe: Das Deployment-Tool - DacPac gegen Zieldatenbank deployen. Modi: Publish (direkt ausführen), Script (Diff-Script generieren für Review), DeployReport (XML-Report der Änderungen). Wichtige Parameter: /p:BlockOnPossibleDataLoss (Deployment abbrechen wenn Datenverlust droht), /p:DropObjectsNotInSource (gefährlich! entfernt alles, was nicht im Projekt ist).
  • Praxis-Übung: SQL Database Project erstellen, Schema aus Demo-Datenbank importieren, in Git committen. Änderung durchführen (neue Tabelle, neue Spalte, Stored Procedure ändern). Build -> DacPac. Schema Compare gegen Zieldatenbank. SqlPackage Publish gegen Dev-Umgebung.
4. Flyway und Liquibase: Migration-based Schema Management
  • Flyway Grundlagen: Versioned Migrations (V001__, V002__), Repeatable Migrations (R__ - werden bei jeder Änderung erneut ausgeführt, z.B. Views, Functions), Undo Migrations (U001__ - optional, für Rollback). flyway_schema_history-Tabelle als Audit-Trail. CLI, Java API, Maven/Gradle Plugin, Docker Image. Flyway Community (Open Source) vs. Flyway Teams (kommerziell, Undo, Check, Dry Run).
  • Liquibase als Alternative: Changelog-Dateien in XML, YAML, JSON oder SQL. Changesets mit id und author. DATABASECHANGELOG-Tabelle. Rollback-Support (automatisch für einfache Änderungen, manuell für komplexe). Liquibase Community (Open Source) vs. Liquibase Pro.
  • Flyway vs. Liquibase vs. EF Core Migrations: Flyway (SQL-nativ, einfach, weit verbreitet). Liquibase (Multi-Format, stärkerer Rollback, komplexer). EF Core Migrations (nur für .NET-Applikationen mit Entity Framework, Code-First). Alle drei unterstützen SQL Server.
  • Best Practices: Eine Migration pro logische Änderung (nicht 5 Änderungen in einem Script). Migrations sind immutable (einmal angewendet, nie ändern - neue Migration für Korrekturen). Idempotente Migrations (IF NOT EXISTS vor CREATE, IF EXISTS vor DROP). Naming Convention: V001__create_customers_table.sql (Version + Beschreibung).
  • Praxis-Übung: Flyway-Projekt aufsetzen (Docker oder CLI). 5 Migrations schreiben (Create Table, Add Column, Create Index, Insert Seed Data, Create Stored Procedure). Gegen Dev-Datenbank migrieren. flyway_schema_history inspizieren. Neue Migration hinzufügen und erneut migrieren -> nur die neue wird angewendet.
Tag 2: Automatisierte Tests und CI/CD-Pipeline
5. Datenbanktests mit tSQLt: Unit Tests für SQL Server
  • Warum Datenbanktests? Stored Procedures, Functions und Views enthalten Geschäftslogik - genau wie Applikationscode. Aber sie werden fast nie getestet. Ergebnis: Fehler werden erst in Produktion entdeckt, Refactoring ist riskant, niemand traut sich, etwas zu ändern.
  • tSQLt Framework: Open-Source-Unit-Testing-Framework für SQL Server. Tests als Stored Procedures in speziellen Test-Schemas. Assertions: AssertEquals, AssertEqualsTable, AssertObjectExists, AssertResultSetsHaveSameMetaData. Isolation: FakeTable (Tabelle durch leere Kopie ersetzen -> Test ist unabhängig von Daten), SpyProcedure (Stored Procedure durch Mock ersetzen -> Seiteneffekte isolieren), ApplyConstraint (Constraints selektiv aktivieren/deaktivieren).
  • Test-Patterns für Datenbanken: (1) Stored Procedure testen (Input -> Ausführung -> Output prüfen). (2) View testen (Testdaten einfügen -> View abfragen -> Ergebnis prüfen). (3) Constraint testen (ungültige Daten einfügen -> ExpectException). (4) Schema testen (AssertObjectExists -> prüfen, dass Tabelle/Spalte/Index existiert nach Migration). (5) Trigger testen (DML ausführen -> Seiteneffekt prüfen).
  • tSQLt in der Pipeline: Tests als Teil des CI-Builds ausführen. EXEC tSQLt.RunAll -> XML-Output -> JUnit-kompatibles Format -> Pipeline kann Pass/Fail auswerten. Bei Failure: Build schlägt fehl, Deployment wird blockiert.
  • Praxis-Übung: tSQLt installieren. 5 Tests schreiben: (1) Test einer Stored Procedure (Bestellwert berechnen), (2) Test einer View (aktive Kunden filtern), (3) Test eines Constraints (negative Menge wird abgelehnt), (4) Schema-Test (Tabelle existiert nach Migration), (5) Test mit FakeTable (isoliert von Produktionsdaten). Alle Tests ausführen -> Ergebnis interpretieren.
6. CI-Pipeline: Build, Test und Validierung automatisieren
  • Pipeline-Architektur für Database DevOps: Trigger (Git Push auf main/develop) -> Build (DacPac kompilieren oder Flyway validate) -> Test (tSQLt gegen Testdatenbank ausführen) -> Artifact (DacPac oder Migrations-Ordner als Build-Artifact speichern). Alles automatisch, bei jedem Commit.
  • GitHub Actions für SQL Server: Workflow-Datei (.github/workflows/database-ci.yml). Steps: (1) SQL Server als Docker Container starten (mcr.microsoft.com/mssql/server:2022-latest), (2) DacPac builden (dotnet build für .sqlproj) oder Flyway migrate ausführen, (3) tSQLt-Tests deployen und ausführen, (4) Testergebnisse als JUnit-Report publishen, (5) DacPac als Artifact hochladen.
  • Azure DevOps Pipelines als Alternative: YAML-Pipeline, identische Logik. SQL Server Build Tools als Agent-Fähigkeit oder Docker-basiert. SqlPackage als Pipeline-Task (DacFx).
  • Pull-Request-Validierung: Bei jedem PR, der Schema-Änderungen enthält: Pipeline baut, testet und generiert einen Schema-Diff-Report als PR-Kommentar. Reviewer sieht: „Diese PR ändert Tabelle X (neue Spalte), erstellt Index Y, ändert Stored Procedure Z." Code Review für Datenbank-Änderungen wird informiert statt blind.
  • Branching-Strategien für Datenbanken: Feature-Branches mit eigener Testdatenbank (Docker Container pro Branch -> isolierte Umgebungen). Trunk-based: Migrations müssen additiv sein (kein DROP TABLE im Feature-Branch, das andere Branches bricht). Brücke zum GFU-Seminar „Git für Teams" (NEU, 2T).
  • Praxis-Übung: GitHub Actions Workflow erstellen: SQL Server Container starten -> Flyway migrate -> tSQLt-Tests ausführen -> DacPac als Artifact. PR öffnen mit Schema-Änderung -> Pipeline läuft -> Ergebnis im PR sichtbar.
7. CD-Pipeline: Schema-Deployment automatisieren
  • Deployment-Pipeline: Artifact (DacPac oder Migrations) -> Dev (automatisch) -> Staging (automatisch mit Approval Gate) -> Produktion (mit manuellem Approval und Deployment-Fenster).
  • Environment-Management: Jede Umgebung hat eigene Connection Strings, Credentials und Konfiguration. Secrets Management: GitHub Secrets, Azure Key Vault, Environment Variables - nie Credentials im Code.
  • SqlPackage Deployment: DacPac gegen Zielumgebung publishen. Pre-Deployment-Validierung: DeployReport generieren und prüfen (gibt es Datenverlust-Risiken?). /p:BlockOnPossibleDataLoss=True als Sicherheitsnetz. Diff-Script zur manuellen Review generieren (für Produktion: Script generieren -> DBA reviewed -> DBA gibt Approval -> Pipeline führt aus).
  • Flyway Deployment: flyway migrate gegen Zielumgebung. Dry Run (flyway info -> zeigt pending Migrations ohne Ausführung). Callbacks: beforeMigrate, afterMigrate (z.B. Statistiken aktualisieren, Berechtigungen setzen).
  • Rollback-Strategien: State-based (DacPac der vorherigen Version erneut deployen -> SqlPackage generiert Reverse-Diff). Migration-based (Flyway Undo Migrations oder manuelle Rollback-Migrations). Daten-Rollback (komplizierter: Backup-basiert oder kompensatorische Transactions). Grundregel: Rollback-Strategie VOR dem Deployment definieren und testen.
  • Praxis-Übung: Deployment-Pipeline erweitern: Dev (automatisch nach CI) -> Staging (mit Approval Gate in GitHub Actions / Azure DevOps). Schema-Änderung durch die Pipeline deployen: Dev -> Staging. Rollback-Szenario durchspielen: fehlerhafte Migration -> Rollback ausführen.
Tag 3: Fortgeschrittene Themen und Praxis
8. Zero-Downtime-Deployments für SQL Server
  • Das Problem: ALTER TABLE ADD COLUMN (schnell), ALTER TABLE ALTER COLUMN (Schema-Lock), CREATE INDEX (lang, blockiert Writes auf Standard-Editionen). Produktionsdatenbanken mit 24/7-Betrieb können sich keine Downtime leisten.
  • Expand-Contract-Pattern: Phase 1 (Expand): Neue Spalte/Tabelle hinzufügen, Applikation schreibt in alte UND neue Struktur (Dual-Write). Phase 2 (Migrate): Bestehende Daten in die neue Struktur migrieren (Background Job). Phase 3 (Contract): Alte Struktur entfernen, Applikation nutzt nur noch die neue. Jede Phase ist ein separates Deployment - kein Big Bang.
  • Online-Schema-Änderungen: CREATE INDEX ... WITH (ONLINE = ON) (Enterprise Edition), ALTER TABLE ... SWITCH (Partition Switching für Massenänderungen), sp_rename (Metadaten-Operation, kein Lock), neue Spalte mit DEFAULT und NULL (kein Rebuild nötig ab SQL Server 2012).
  • Feature Flags für Datenbank-Änderungen: Schema-Änderung deployen, aber Applikation nutzt sie erst, wenn Feature Flag aktiviert wird. Entkopplung von Schema-Deployment und Feature-Aktivierung.
  • Praxis-Übung: Expand-Contract für eine Spaltenumbenennung durchführen: (1) Neue Spalte hinzufügen, (2) Daten kopieren (Background), (3) Applikation umstellen (Feature Flag), (4) Alte Spalte entfernen. Drei separate Deployments, zero Downtime.
9. Testdaten-Management und Datenschutz
  • Das Testdaten-Dilemma: Tests brauchen realistische Daten, aber Produktionsdaten in Testumgebungen verletzen die DSGVO. Lösungen: Synthetische Daten (Faker-Libraries, SQL Data Generator), Anonymisierung/Pseudonymisierung (Namen, E-Mails, Adressen ersetzen, Strukturen und Verteilungen beibehalten), Subset-Erstellung (10 % der Produktionsdaten, anonymisiert - behält Referenzielle Integrität).
  • Testdaten als Code: Seed Data in Migrations (INSERT-Statements für Referenzdaten, Testfälle). Docker-Container mit vorbereiteter Testdatenbank (Image bauen, in Registry pushen, in Pipeline nutzen). Testdatenbank pro Feature-Branch (Container starten, migrieren, testen, wegwerfen).
  • Static Data Management: Referenzdaten (Länder, Währungen, Statuswerte) gehören in die Versionsverwaltung - als Migrations oder Post-Deployment-Scripts. Änderungen an Referenzdaten durchlaufen dieselbe Pipeline wie Schema-Änderungen.
  • Praxis-Übung: Testdaten-Setup automatisieren: Docker-Container mit SQL Server starten -> Flyway/DacPac deployen -> Seed Data laden -> tSQLt-Tests ausführen -> Container wegwerfen. Gesamtlaufzeit: unter 3 Minuten. Anonymisierungs-Script für eine Demo-Tabelle schreiben.
10. Schema Drift Detection und Governance
  • Schema Drift: Wenn jemand eine Änderung direkt auf der Produktionsdatenbank macht - ohne Pipeline, ohne Git, ohne Review. Das Produktionsschema weicht vom versionierten Schema ab. Jede manuelle Änderung untergräbt das gesamte DevOps-Konzept.
  • Drift Detection automatisieren: Regelmäßig (täglich) SqlPackage /Action:DeployReport gegen Produktion ausführen - Diff zwischen Git-Stand und Produktions-Schema. Wenn Diff ≠ leer -> Alert. Alternative: Flyway check (Teams/Pro-Feature) - vergleicht Schema-Stand mit erwarteter Migration-History.
  • Governance-Maßnahmen: DDL-Berechtigungen einschränken (nur Pipeline-Service-Account darf Schema ändern, nicht einzelne DBAs), DDL-Trigger (protokollieren jede direkte Schema-Änderung mit Timestamp und Login), regelmäßige Schema-Compare-Reports im Team-Meeting.
  • Database Reliability Engineering: Der DBA der Zukunft ist kein Script-Ausführer, sondern ein Platform Engineer: Pipeline bauen und warten, Performance monitoren, Governance durchsetzen, Entwickler coachen. Brücke zum GFU-Seminar „SQL Server Monitoring und Troubleshooting" (geplant, 2T).
  • Praxis-Übung: Schema Drift simulieren (manuelle Änderung direkt auf der Staging-Datenbank). Drift Detection laufen lassen -> Drift wird erkannt. DDL-Trigger einrichten, der jede direkte Schema-Änderung protokolliert.
11. Praxis-Workshop: „Unsere Database-DevOps-Pipeline"
Phase 1 - Toolentscheidung und Setup (20 Min):
  • Entscheidung: State-based (SSDT/DacPac) oder Migration-based (Flyway/Liquibase) - basierend auf der eigenen Umgebung (Komplexität, Team-Skills, Toolchain, Budget).
  • CI/CD-Plattform wählen: GitHub Actions, Azure DevOps, GitLab CI - was nutzt die Organisation bereits?
  • Testframework: tSQLt als Standard, Ergänzung durch Schema-Validierung und Integrationstests.
Phase 2 - Pipeline bauen (25 Min):
  • End-to-End-Pipeline für das eigene Szenario konfigurieren: Git Repository mit Datenbankprojekt oder Flyway-Migrations -> CI: Build + tSQLt Tests -> CD: Deploy nach Dev (automatisch) -> Deploy nach Staging (mit Approval).
  • Drift Detection als Scheduled Job einrichten.
  • Rollback-Strategie definieren und dokumentieren.
Phase 3 - Einführungsplan und Peer-Review (15 Min):
  • 90-Tage-Plan für die eigene Organisation: Woche 1-4 (Datenbankschema in Git bringen, erste Tests schreiben), Woche 5-8 (CI-Pipeline für Dev-Umgebung aufsetzen), Woche 9-12 (CD-Pipeline für Staging erweitern, Drift Detection aktivieren, Team schulen).
  • Peer-Review: Plan vorstellen, Stresstest: „Ein Entwickler führt eine ALTER TABLE direkt auf Produktion aus, weil die Pipeline 'zu langsam' ist. Was tust du?"

  • SQL-Server-Datenbankadministratoren: Die manuelle Schema-Deployments durch automatisierte Pipelines ersetzen und Deployment-Risiken reduzieren.
  • SQL-Server-Entwickler: Die Datenbankänderungen versionieren, testen und reproduzierbar deployen - wie Applikationscode.
  • DevOps Engineers und Platform Engineers: Die die Datenbank als letztes Silo in der CI/CD-Pipeline schließen.
  • Architekten und Tech Leads: Die Database DevOps als Praxis in ihren Teams etablieren und Toolentscheidungen treffen.
Voraussetzungen: Fundierte SQL-Server-Kenntnisse (T-SQL, Schema-Objekte, Stored Procedures, Berechtigungen). Grundverständnis von CI/CD-Konzepten (Build, Test, Deploy, Pipeline). Git-Grundkenntnisse (commit, push, pull, branch, merge). Idealerweise Besuch von „SQL Server Administration" (S1050, 3T) oder „T-SQL Aufbau" (S765, 2T) sowie „Git für Teams" (NEU, 2T) oder vergleichbare Praxiserfahrung.
Abgrenzung: Dieses Seminar behandelt DevOps-Praktiken für SQL-Server-Datenbanken - Versionierung, Testing und automatisiertes Deployment von Schema-Änderungen. Es ist kein Applikations-DevOps-Seminar (dafür: „GitHub Actions" S5399, „GitLab CI/CD" S6370), kein SQL-Server-Grundlagen-Seminar (dafür: S1050/S1051)


In Präsenz
Online
Lernmethode

Ausgewogene Mischung aus Theorie und praktischen Übungen auf persönlichem Schulungs-PC.

Wie auch bei unseren Präsenz-Seminaren: Ausgewogene Mischung aus Theorie und praktischen Übungen. Trainer durchgehend präsent.

Unterlagen

Seminarunterlagen oder Fachbuch inklusive. Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne.

Seminarunterlagen oder Fachbuch inklusive (via DHL). Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne.

Arbeitsmaterialien

DIN A4 Block, Notizblock, Kugelschreiber, USB-Stick, Textmarker, Post-its

Teilnahmezertifikat

Nach Abschluss des Seminars erhalten Sie das Teilnahmezertifikat inkl. Inhaltsverzeichnis per E-Mail als PDF.


In Präsenz
Online
Teilnehmendenzahl

min. 1, max. 8 Personen

Garantierte Durchführung

Ab 1 Teilnehmenden*

Schulungszeiten
3 Tage, 09:00 - 16:00 Uhr
Ort der Schulung
GFU Schulungszentrum oder Virtual Classroom
GFU Schulungszentrum
Am Grauen Stein 27
51105 Köln-Deutz

oder online im Virtual Classroom oder europaweit bei Ihnen als Inhouse-Schulung

Um ein optimales Raumklima zu gewährleisten, haben wir das Schulungszentrum mit 17 hochmodernen Trotec TAC V+ Luftreinigern ausgestattet. Diese innovative Filtertechnologie (H14 zertifiziert nach DIN EN1822) sorgt dafür, dass die Raumluft mehrfach pro Stunde umgewälzt wird und Schadstoffe zu 99.995% im HEPA-Filter abgeschieden und infektiöse Aerosole abgetötet werden.

Zusätzlich sind alle Räume mit CO2-Ampeln ausgestattet, um jederzeit eine hervorragende Luftqualität sicherzustellen.

Räumlichkeiten

Helle und modern ausgestattete Räume mit perfekter Infrastruktur

Bequem aus dem Homeoffice von überall

Preisvorteil

Dritter Mitarbeitende nimmt kostenfrei teil.
(Nicht mit anderen Rabatten kombinierbar.)

Eventuell anfallende Prüfungskosten für den dritten Teilnehmenden werden zusätzlich berechnet.

Hinweis: Um den Erfolg der Schulung zu gewährleisten, sollte auch der dritte Teilnehmende die erwarteten Vorkenntnisse mitbringen.

KOMPASS — Förderung für Solo-Selbstständige

Solo-Selbstständige können für dieses Seminar eine Förderung via KOMPASS beantragen.

Ausführliche Informationen dazu finden Sie hier.

All-Inclusive

Gebäck, Snacks und Getränke ganztägig, Mittagessen im eigenen Restaurant, täglich 6 Menüs, auch vegetarisch

Eine Auswahl unserer Frühstücks-Snacks und Nervennahrungs-Highlights senden wir Ihnen mit den Seminarunterlagen via DHL zu.

Barrierefreiheit

Das GFU-Schulungszentrum (Am Grauen Stein 27) ist barrierefrei

-
Rechnungsstellung

Erst nach dem erfolgreichen Seminar. Keine Vorkasse.

Stornierung

Kostenfrei bis zum Vortag des Seminars

Vormerken statt buchen

Sichern Sie sich unverbindlich Ihren Seminarplatz schon vor der Buchung - auch wenn Sie selbst nicht berechtigt sind zu buchen


In Präsenz
Online
  • Eigener Shuttle-Service
  • Reservierte Parkplätze
  • Hotelreservierung
  • Technik-Sofort-Support

Buchungsmöglichkeiten

Online oder in Präsenz teilnehmen

Sie können sowohl Online als auch in Präsenz am Seminar teilnehmen. Klicken Sie bei Ihrer Buchung oder Anfrage einfach die entsprechende Option an.

Mehr Infos

Gesicherte offene Termine

27.07.-29.07.2026 05.10.-07.10.2026 07.12.-09.12.2026 19.04.-21.04.2027 21.06.-23.06.2027

Weiterbildung Database DevOps: CI/CD für SQL Server

TerminOrtPreis
27.07.-29.07.2026
Plätze vorhanden
Köln / Online 2.030,00
Köln / Online 2.030,00 Buchen Vormerken
05.10.-07.10.2026
Plätze vorhanden
Köln / Online 2.030,00
Köln / Online 2.030,00 Buchen Vormerken
07.12.-09.12.2026
Plätze vorhanden
Köln / Online 2.030,00
Köln / Online 2.030,00 Buchen Vormerken
2027
19.04.-21.04.2027
Plätze vorhanden
Köln / Online 2.030,00
Köln / Online 2.030,00 Buchen Vormerken
21.06.-23.06.2027
Plätze vorhanden
Köln / Online 2.030,00
Köln / Online 2.030,00 Buchen Vormerken
Kein passender Termin? Termin vorschlagen
  • Buchen ohne Risiko
  • Keine Vorkasse
  • Kostenfreies Storno bis zum Vortag des Seminars
  • Rechnung nach erfolgreichem Seminar
  • All-Inclusive-Preis
  • Garantierter Termin und Veranstaltungsort
  • Preise pro Person zzgl. Mehrwertsteuer
  • Dritter Mitarbeitende kostenfrei (Nicht mit anderen Rabatten kombinierbar.)
Inhouse-/Firmenschulung
  • Lernumgebung in der Cloud
  • Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Unverbindlich anfragen
Individualschulung
  • Lernumgebung in der Cloud
  • 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Unverbindlich anfragen
Nachbetreuung

Unterstützung nach der Schulung durch
individuelle Nachbetreuung

Details & Anfrage

So haben GFU-Kunden gestimmt

Zu diesem Seminar wurden noch keine Bewertungen abgegeben.

FAQ für Offene Schulungen
  • Alle folgenden Schulungsformen können auch Online als Virtual Classroom durchgeführt werden.
  • Eine Offene Schulung findet zu einem festgelegten Zeitpunkt im voll ausgestatteten Schulungszentrum oder Online/Remote statt. Sie treffen auf Teilnehmende anderer Unternehmen und profitieren vom direkten Wissensaustausch.
  • Eine Inhouse-/Firmen-Schulung geht auf die individuellen Bedürfnisse Ihres Unternehmens ein. Sie erhalten eine kostenfreie Beratung von Ihrem Seminarleiter und können Inhalte und Dauer auf Ihren Schulungsbedarf anpassen. Inhouse-Schulungen können Europaweit durchgeführt werden.
  • Bei einer Individual-Schulung erhalten Sie eine 1-zu-1 Betreuung und bestimmen Inhalt, Zeit und Lerntempo. Der Dozent passt sich Ihren Wünschen und Bedürfnissen an.

Sie können unsere Schulungen auch als Remote Schulung im Virtual Classroom anfragen.

In drei Schritten zum Online Seminar im Virtual Classroom:

  1. Seminar auswählen und auf "Buchen" klicken
  2. Wählen Sie bei "Wie möchten Sie teilnehmen?" einfach "Online" aus.
  3. Formular ausfüllen und über den Button "Jetzt buchen" absenden.

Unser Kundenservice meldet sich bei Ihnen mit der Buchungsbestätigung.

Unsere Online Schulungen finden im Virtual Classroom statt. Ein Virtual Classroom bündelt mehrere Werkzeuge, wie Audio-Konferenz, Text-Chat, Interaktives Whiteboard, oder Application Sharing.

Vorteile von Virtual Classroom:

  • Sie erhalten 1 zu 1 die gleiche Lernumgebung, die Sie auch vor Ort bei uns vorfinden
  • Die technische Vorbereitung wird von den GFU-Technikern vorgenommen
  • Sie erhalten remote Zugriff auf Ihren persönlichen Schulungs-PC im GFU-Seminarraum
  • Die Virtual Classroom Lösung lässt sich auch im Browser betreiben
  • Die GFU-Technik leistet wie gewohnt Soforthilfe bei Problemen
  • Die Schulungsunterlagen bekommen Sie via DHL zugeschickt
  • Sie sparen Reisekosten und Zeit
  • 27. Jul. - 29. Jul. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
  • 05. Okt. - 07. Okt. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
  • 07. Dez. - 09. Dez. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
  • 19. Apr. - 21. Apr. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
  • 21. Jun. - 23. Jun. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
  • Auch als Inhouse-Schulung, bundesweit mit Termin nach Wunsch und individuellen Inhalten
  • Buchen ohne Risiko! Kostenfreie Stornierung bis zum Vortag des Seminars
Das GFU-Sorglos-Paket

Die Seminare der GFU finden in angenehmer Atmosphäre statt und sind perfekt organisiert. Profitieren Sie von dem Rundum-Service der GFU!

Shuttle-Service

Machen Sie sich keinen Kopf um die Anreise! Unser Shuttle fährt Sie. Oder Sie parken einfach auf einem extra für Sie reservierten Parkplatz.

Hotelreservierung

Hotelzimmer gesucht? Wir organisieren Ihnen eins. Ihr Vorteil: Sie sparen Zeit und Geld!

Kostenfreies Storno

Stornierung bei offenen Seminaren kostenfrei bis einen Tag vor Schulungsbeginn.

Technik-Support

Unsere Techniker sind immer zur Stelle, egal ob online oder vor Ort.

Weitere Services entdecken

Verwandte Seminare

aegallianzaxaElement 1deutsche-bankdeutsche-postlufthansamercedessonyzdf
159.446
Teilnehmende
4.783
Seminarthemen
38.944
Durchgeführte Seminare