> ## Documentation Index
> Fetch the complete documentation index at: https://docs.localmind.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Versionierung

> Workflow-Versionierung und Backup-Strategien für Automate

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.

<Warning>
  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.
</Warning>

## Workflows in Git speichern

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

<Steps>
  <Step title="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".
  </Step>

  <Step title="In Git committen">
    Legen Sie die Datei in Ihrer Repository-Struktur ab und committen Sie mit einer aussagekräftigen Message, die die Änderung beschreibt:

    ```bash theme={null}
    git add workflows/
    git commit -m "Update welcome email workflow"
    git push
    ```
  </Step>

  <Step title="Versionierung nutzen">
    Verwenden Sie Git Tags für Releases:

    ```bash theme={null}
    git tag -a v1.0.0 -m "Initial workflow version"
    git push --tags
    ```

    Und Branches für Experimente:

    ```bash theme={null}
    git checkout -b feature/new-workflow
    # Änderungen machen
    git commit -m "Add new workflow feature"
    ```
  </Step>
</Steps>

### 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
```

<Note>
  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.
</Note>

## 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.

```bash theme={null}
#!/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](#workflows-in-git-speichern) oben); zum Zurückspielen importieren Sie die gesicherte Datei wieder. Eine programmatische Verwaltung dokumentieren wir unter [Automate-API](/administration/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:

```bash theme={null}
# 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`:

```markdown theme={null}
# 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

1. **Backup erstellen:** Exportieren Sie die aktuelle Version als Backup.
2. **Änderungen prüfen:** Lesen Sie den CHANGELOG und prüfen Sie Breaking Changes.
3. **Test-Kopie:** Testen Sie die neue Version als Kopie des Workflows (z.B. aus Ihrem `development/`-Ordner importiert), bevor Sie den produktiven Workflow ersetzen.
4. **Migration:** Ersetzen Sie den produktiven Workflow durch die getestete Version.
5. **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](/automate/Naming-Conventions) und [Sicherheit](/automate/security).