Versionierung

Eine solide Versionierungsstrategie ist essentiell für die Wartbarkeit und Zuverlässigkeit Ihrer Automate-Workflows: Sie macht Änderungen rückverfolgbar, ermöglicht Teamarbeit ohne gegenseitiges Überschreiben, erlaubt bei Problemen ein schnelles Rollback auf eine funktionierende Version und schafft Audit-Trails für Compliance.

Ob eine integrierte Workflow-Historie verfügbar ist, hängt von Ihrer Automate-Version ab — verlassen Sie sich für belastbare Versionierung auf den Export-Weg unten. Er funktioniert unabhängig von der eingesetzten Version.

Workflows in Git speichern

Der verlässliche Weg zur Versionierung: Sie laden den Workflow als JSON-Datei herunter und verwalten ihn in Git.

Workflow herunterladen

Öffnen Sie den Workflow, dann das Workflow-Menü (⋯ oben rechts), und klicken Sie auf Download — der Workflow wird als JSON-Datei gespeichert. Der Menüpunkt heißt Download, nicht „Export”.

In Git committen

Legen Sie die Datei in Ihrer Repository-Struktur ab und committen Sie mit einer aussagekräftigen Message, die die Änderung beschreibt:

git add workflows/
git commit -m "Update welcome email workflow"
git push

Versionierung nutzen

Verwenden Sie Git Tags für Releases:

git tag -a v1.0.0 -m "Initial workflow version"
git push --tags

Und Branches für Experimente:

git checkout -b feature/new-workflow
# Änderungen machen
git commit -m "Add new workflow feature"

Empfohlene Repository-Struktur

localmind-workflows/
├── .gitignore
├── README.md
├── workflows/
│   ├── production/
│   │   ├── welcome-email.json
│   │   └── order-processing.json
│   ├── staging/
│   │   └── welcome-email.json
│   └── development/
│       └── test-workflow.json
├── scripts/
│   ├── export-all.sh
│   └── import-workflow.sh
└── docs/
    └── workflow-documentation.md

Die Ordner production/, staging/ und development/ sind eine reine Git-Ordnerkonvention zur Organisation Ihrer Dateien. Automate selbst kennt keine Environments — alle Workflows laufen in derselben Instanz.

Backup-Strategien

Automatisieren Sie regelmäßige Exports (täglich oder wöchentlich), speichern Sie sie in sicherem Speicher und behalten Sie mehrere Backup-Generationen. Exportieren Sie zusätzlich manuell vor größeren Änderungen und Updates — und testen Sie die Wiederherstellung Ihrer Backups regelmäßig.

#!/bin/bash
# backup-workflows.sh

BACKUP_DIR="./backups/$(date +%Y-%m-%d)"
mkdir -p "$BACKUP_DIR"

# Die über die Web-App heruntergeladenen Workflow-JSON-Dateien
# in das datierte Backup-Verzeichnis ablegen

echo "Backups erstellt in: $BACKUP_DIR"

Die Workflow-JSON-Dateien laden Sie über die Web-App herunter (siehe Workflows in Git speichern oben); zum Zurückspielen importieren Sie die gesicherte Datei wieder. Eine programmatische Verwaltung dokumentieren wir unter Automate-API, sobald die Schnittstelle verifiziert ist.

Versionsnummern

Verwenden Sie semantische Versionierung im Format MAJOR.MINOR.PATCH: MAJOR für Breaking Changes, MINOR für neue, rückwärtskompatible Features, PATCH für Bugfixes. Beispiel: 1.0.0 (Initial Release) → 1.1.0 (neue Features) → 1.1.1 (Bugfix) → 2.0.0 (Breaking Changes). Setzen Sie die Versionen als Git Tags:

# Major Release
git tag -a v2.0.0 -m "Major update with breaking changes"

# Minor Release
git tag -a v1.1.0 -m "Added new features"

# Patch Release
git tag -a v1.0.1 -m "Fixed critical bug"

Dokumentieren Sie Versionsänderungen in einer CHANGELOG.md:

# Changelog

## [2.0.0] - 2026-01-15

### Breaking Changes
- Workflow-Struktur geändert: Neue Node-Reihenfolge erforderlich
- API-Endpunkt geändert: Migration erforderlich

### Added
- Neue Error-Handling-Logik
- Retry-Mechanismus für API-Calls
- Performance-Monitoring

### Changed
- Verbesserte Datenvalidierung
- Optimierte API-Call-Reihenfolge

### Fixed
- Bug bei Timeout-Behandlung
- Fehlerhafte Daten-Transformation behoben

## [1.1.0] - 2026-01-01

### Added
- Neue E-Mail-Templates
- Erweiterte Logging-Funktionen

Migration zwischen Versionen

Backup erstellen: Exportieren Sie die aktuelle Version als Backup.
Änderungen prüfen: Lesen Sie den CHANGELOG und prüfen Sie Breaking Changes.
Test-Kopie: Testen Sie die neue Version als Kopie des Workflows (z.B. aus Ihrem development/-Ordner importiert), bevor Sie den produktiven Workflow ersetzen.
Migration: Ersetzen Sie den produktiven Workflow durch die getestete Version.
Validierung: Überprüfen Sie, dass alles funktioniert.

Checkliste

Workflows sind in Git versioniert
Regelmäßige Backups werden erstellt
Versionsnummern werden verwendet
CHANGELOG wird gepflegt
Migration-Strategien sind dokumentiert
Backup-Wiederherstellung wurde getestet

Weiterführend: Naming Conventions und Sicherheit.

Grundlagen

Localmind anbinden

Workflows

Erweitert

Betrieb

Workflows in Git speichern

Empfohlene Repository-Struktur

Backup-Strategien

Versionsnummern

Migration zwischen Versionen

Checkliste

​Workflows in Git speichern

​Empfohlene Repository-Struktur

​Backup-Strategien

​Versionsnummern

​Migration zwischen Versionen

​Checkliste

Workflows in Git speichern

Empfohlene Repository-Struktur

Backup-Strategien

Versionsnummern

Migration zwischen Versionen

Checkliste