So aktualisieren Sie Ihre Dokumentation bei jedem Release automatisch

Aktualisiert am 3. November 2026

Um die Dokumentation bei jedem Release automatisch zu aktualisieren, starten Sie einen Dokumentations-Job direkt mit dem Release: einem veröffentlichten GitHub-Release, einem GitLab-Release-Event, einem Bitbucket-Tag oder einem neuen Eintrag in Ihrem öffentlichen Changelog. Der Job liest die Release-Notes, findet die betroffenen Hilfeseiten und Videos, entwirft die Änderungen und sendet sie zur Genehmigung an eine Person. Bei kundenorientierter Dokumentation ist dieser Prüfungsschritt entscheidend für die Sicherheit der Dokumentationsautomatisierung.

Dieser Leitfaden führt Sie zunächst durch diese Pipeline mit beliebigen Tools (GitHub Actions, GitLab, Bitbucket, Changelog-Seite) und zeigt dann, wie Clevera Autopilot denselben Ablauf für ein Hilfe-Center mit Videos durchführt.

Was ist kontinuierliche Dokumentation?#

Swimm, das den Begriff populär gemacht hat, definiert continuous documentation als das inkrementelle Erstellen und Aktualisieren von Dokumentationen als Teil des Entwicklungs-Workflows, anstatt dies in gelegentlichen Nachholprojekten zu tun. Die meisten Tools, die auf dieser Idee basieren und heute oft als "selbstaktualisierende Dokumentation" vermarktet werden, überwachen Commits oder Pull Requests und aktualisieren Entwicklerdokumentationen direkt neben dem Code.

Kundenorientierte Hilfe-Center benötigen einen anderen Auslöser. Leser sehen keinen Commit; sie sehen ein Release. Die Tabelle zeigt die Vor- und Nachteile.

Das Argument für Automatisierung ist das Tempo. Die DORA-Studie „State of DevOps 2021“ ergab, dass Elite-Teams 973-mal häufiger bereitstellen als leistungsschwache Teams. Nicht jeder Deploy ändert, was Leser sehen, aber Teams veröffentlichen weit häufiger, als irgendjemand Artikel manuell überprüfen könnte. Dieselbe Studie ergab, dass Teams mit qualitativ hochwertiger Dokumentation 3,8-mal häufiger Sicherheits-Best-Practices implementieren, die Dokumentation ist also kein Nebenthema. Und veraltete Dokumentation ist weit verbreitet: In GitHubs Open Source Survey von 2017 gaben 93 % der Befragten an, auf unvollständige oder veraltete Dokumentation gestoßen zu sein, und 60 % der Mitwirkenden sagten, sie würden selten oder nie zur Dokumentation beitragen.

Schritt 1: Schreiben Sie Release-Notes, die ein Dokumentations-Job nutzen kann#

Automatisierung kann Dokumente nur so gut aktualisieren, wie die Release-Notes die Änderung beschreiben. Zwei Konventionen helfen dabei.

• Gruppieren Sie Änderungen nach Typ. Keep a Changelog verwendet Added, Changed, Deprecated, Removed, Fixed und Security. „Added“ bedeutet meist einen neuen Artikel oder ein neues Video; „Changed“ und „Removed“ bedeuten, dass bestehende Inhalte nun falsch sind.
• Trennen Sie, was Benutzer sehen, von dem, was sie nicht sehen. Die automatisch generierten Release-Notes von GitHub sortieren zusammengeführte Pull Requests nach Labels in .github/release.yml und können Labels vollständig ausschließen.

# .github/release.yml
changelog:
  exclude:
    labels: [internal, chore]
  categories:
    - title: New
      labels: [feature]
    - title: Changed in the app
      labels: [ui-change]
    - title: Fixes
      labels: [bug]
    - title: Other changes
      labels: ["*"]

Ein „ui-change“-Label ist das nützlichste Label: Es sagt dem Dokumentations-Job, welche Elemente einen Artikel ungültig machen können. Benennen Sie den Bildschirm auch im Titel des Pull Requests („Abrechnungseinstellungen: Erinnerungen zu Automatisierungen verschieben“), damit die Änderung den Seiten zugeordnet werden kann, die diesen Bildschirm zeigen.

Schritt 2: Dokumentation bei Release automatisch aktualisieren: Job starten#

Jeder große Git-Host kann einen Job starten, wenn Sie veröffentlichen. So generieren Sie Dokumentations-Updates aus GitHub-Releases oder deren GitLab- und Bitbucket-Äquivalenten. Die Details unterscheiden sich.

Auf GitHub sieht ein minimaler Workflow so aus:

# .github/workflows/docs-on-release.yml
name: Docs on release
on:
  release:
    types: [published]
permissions:
  contents: read
jobs:
  draft-docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - name: Draft docs updates for this release
        env:
          TAG: ${{ github.event.release.tag_name }}
          NOTES: ${{ github.event.release.body }}
        run: ./scripts/draft-docs-updates.sh

Verwenden Sie published anstelle von created: Laut GitHubs Event-Referenz feuert created nicht bei Entwurfs-Releases, während published sowohl stabile Releases als auch Pre-Releases abdeckt. Übergeben Sie die Release-Notes wie oben über eine Umgebungsvariable und nicht direkt in den Shell-Befehl, da Release-Texte Benutzereingaben sind. Und wenn ein Tool wie release-please oder semantic-release Ihre Releases mit dem Standard-Token erstellt, starten die dadurch ausgelösten Events Ihren Dokumentations-Workflow nicht; geben Sie diesem Tool stattdessen ein GitHub App-Token oder ein persönliches Zugriffstoken.

Auf GitLab und Bitbucket ist das Äquivalent ein Job, der bei Tags läuft:

# .gitlab-ci.yml
draft-docs:
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - ./scripts/draft-docs-updates.sh "$CI_COMMIT_TAG"

# bitbucket-pipelines.yml
pipelines:
  tags:
    'v*':
      - step:
          script:
            - ./scripts/draft-docs-updates.sh "$BITBUCKET_TAG"

Schritt 3: Finden Sie die Seiten und Videos, die jedes Release betreffen#

Dies ist der Schritt, den die meisten Anleitungen überspringen, und derjenige, der entscheidet, ob die Automatisierung hilft. Eine Release-Note sagt „Erinnerungen zu Abrechnung → Automatisierungen verschoben“; Ihr Job muss daraus machen: „Diese drei Artikel und zwei Videos sind jetzt falsch“.

Drei Methoden, von der einfachsten bis zur stärksten:

1. Suchen Sie nach umbenannten Labels. Ziehen Sie jede UI-Zeichenfolge aus den Release-Notes und durchsuchen Sie Ihre Artikel und Videoskripte nach der alten Formulierung.
2. Führen Sie ein Bildschirminventar. Markieren Sie jeden Artikel und jedes Video mit den Bildschirmen, die es zeigt, und gleichen Sie die Bildschirmnamen in den Pull-Request-Titeln damit ab. Unser Leitfaden zum Aktuellhalten der Dokumentation enthält eine Inventarvorlage.
3. Lassen Sie ein Modell jeden Kandidaten vollständig lesen. Geben Sie einem Sprachmodell die Release-Notes und den vollständigen Text (oder das Transkript) jeder Kandidatenseite und bitten Sie um ein Urteil: noch korrekt, benötigt eine Textkorrektur oder benötigt neue Screenshots oder Aufnahmen. Das Lesen der gesamten Seite ist wichtig, da der fehlerhafte Schritt oft nicht der ist, den die Release-Note nennt.

Ein Prompt für dieses Urteil kann kurz sein:

You check help articles against a software release.
Release notes: {release_notes}
Article ({url}): {article_text}

Answer in JSON: {"verdict": "still_right" | "text_fix" | "new_screenshots_or_footage",
"reason": "<one sentence quoting the release item>",
"changed_steps": [<step numbers>]}
Only use facts from the release notes. If unsure, answer "text_fix" and say why.

Schritt 4: Entwerfen Sie die Updates#

Bei Texten ist der Entwurf der einfache Teil: Das Modell erhält die Release-Notes, den aktuellen Artikel sowie Ihre Stilvorgaben und liefert eine überarbeitete Version zurück. Behalten Sie die ID und URL des Artikels bei, damit Sie die bestehende Seite aktualisieren, anstatt ein nahezu identisches Duplikat zu erstellen, und protokollieren Sie, welches Release die letzte Änderung vorgenommen hat. Die Regeln unter how to write help center articles eignen sich hervorragend als Stil-Prompt.

Screenshots und Videos sind schwieriger. Ein Modell kann keinen Screenshot von einem Bildschirm erstellen, den es nicht gesehen hat. Sie können entweder neue Bilder in Ihrer UI-Testsuite erfassen, den geänderten Ablauf neu aufzeichnen oder das Element für eine manuelle Neuaufnahme markieren. Kennzeichnen Sie jedes Element im Plan: Textkorrektur, neuer Screenshot oder Neuaufnahme. Sobald der geänderte Ablauf aufgezeichnet ist, erhalten Sie durch turning the recording into documentation in einem Durchgang neue Schritte und Screenshots.

Schritt 5: Setzen Sie eine Person zwischen Entwurf und Leser#

Pull-Request-Beschreibungen werden von vielen Personen geschrieben und nie mit Blick auf die Kunden geprüft. Behandeln Sie sie und Release-Notes als nicht vertrauenswürdige Eingaben: Sie können Anweisungen enthalten, denen ein Modell folgt. Senden Sie jeden Entwurf zur Überprüfung.

• Wer genehmigt: Der Support- oder Dokumentationsleiter für Hilfe-Center-Inhalte, ein Ingenieur für die API-Referenz.
• Was eine gute Überprüfung zeigt: Jede betroffene Seite mit einem Vorher-Nachher-Diff, das Release-Element, das dies verursacht hat, und eine klare „Nichts zu ändern“-Liste, damit Prüfer darauf vertrauen können, was übersprungen wurde.
• Was automatisch veröffentlicht werden sollte: Zunächst nichts, was für Kunden sichtbar ist. Sobald einige Releases ohne Überraschungen durchgelaufen sind, können Sie die Regel für risikoarme Elemente wie Textkorrekturen auf Tippfehler-Ebene lockern.

Welches Setup passt zu Ihrem Team?#

Wenn Ihr Team bereits mit Claude Code arbeitet, können Sie es auch bitten, die Dokumentation nach einem Release über MCP zu aktualisieren; wir zeigen dies in wie man Dokumentation mit Claude Code nach jedem Release aktualisiert.

So aktualisieren Sie Dokumentation automatisch bei einem Release mit Clevera Autopilot#

Clevera ist eine KI-Plattform, die eine Bildschirmaufnahme in ein kommentiertes Anleitungsvideo, einen Schritt-für-Schritt-Hilfeartikel und eine Seite in Ihrem gehosteten Hilfecenter verwandelt – in 74 Sprachen. Die Funktion Autopilot in den Tarifen Pro und Custom führt die oben genannten Schritte 2 bis 5 für ein Clevera-Hilfecenter aus.

• Auslöser. Das Rezept Mein Hilfecenter bei Releases aktuell halten überwacht die Releases oder Gemergten Änderungen eines Repositorys oder eine Changelog-Seite, die täglich oder wöchentlich gelesen wird. GitHub wird über eine schreibgeschützte App verbunden; GitLab (gitlab.com) und Bitbucket Cloud werden bei Verfügbarkeit auf die gleiche Weise verbunden. Clevera prüft das Repository etwa einmal pro Stunde. Es liest Release-Notes, Tags sowie Titel und Beschreibungen von Pull Requests, niemals Ihren Code.
• Abgleich. Jeder Durchlauf prüft bis zu 40 Videos und Artikel des Hilfecenters und liest jeden betroffenen Inhalt vollständig.
• Entwurf. Jeder Eintrag erhält ein Urteil: weiterhin korrekt, eine Textkorrektur mit Vorher-Nachher-Vergleich oder erneut aufnehmen mit den neuen Schritten. Für eine Neuaufnahme ist Meine App verwenden erforderlich: die Adresse Ihrer App und, falls nötig, ein Login (ein Test-Account funktioniert am besten). Das neue Video ersetzt das alte unter demselben Link, sodass Einbettungen und Hilfecenter-Seiten es ohne neue Links anzeigen, genau wie bei LiveSync-Bearbeitungen.
• Überprüfung. Jeder Durchlauf wartet auf Sie. Sie entfernen die Auswahl bei Inhalten, die Sie nicht möchten, und klicken auf Ausführen, oder Sie klicken auf Änderungen anfordern für einen neuen Plan. Ein Plan läuft nach sieben Tagen ab, und der nächste Durchlauf erfasst alles, was seitdem hinzugekommen ist.

Das Überwachen und Planen ist kostenlos; jede Zeile eines Plans zeigt die benötigten Credits an, und ein typischer Durchlauf kostet 10 bis 150 Credits. Dieselbe Schleife ist für Videos ohne Hilfecenter über Meine Videos bei Produktänderungen aktualisieren verfügbar, und Ein Video für jedes neue Feature aufnehmen schlägt eine neue Anleitung für die Neuerungen jedes Releases vor (siehe wie man ein Release-Notes-Video erstellt für die manuelle Version).

Wo Clevera nicht das richtige Tool ist: Es generiert keine API-Referenz aus Code und schreibt nicht Ihre CHANGELOG.md. Für diesen Bereich sehen Sie sich unseren Vergleich von KI-Changelog-Generatoren an oder MCP-Server für Dokumentation, falls Sie einen KI-Agenten zur Bearbeitung von Dokumentationen in einer anderen Plattform wünschen.

Kostenlos starten, um zuerst das Hilfecenter und die Videos aufzubauen; Autopilot ist in Pro enthalten. Einrichtungsschritte finden Sie im Hilfeartikel GitHub oder ein anderes Repository mit Autopilot verbinden.

FAQ#

Kann sich Dokumentation bei einem Release automatisch aktualisieren?#

Die Erkennung und Erstellung von Entwürfen kann automatisch erfolgen: Ein Release startet einen Job, der betroffene Seiten findet und die Korrekturen entwirft. Die Veröffentlichung sollte bei kundenorientierter Dokumentation eine menschliche Entscheidung bleiben, da Release-Notes nicht immer genau beschreiben, was die Leser tun sollen.

Sollte die Dokumentation bei jedem Commit oder jedem Release aktualisiert werden?#

Für Hilfecenter: bei jedem Release. Commits und Pull Requests ändern sich ständig und liegen oft hinter Feature-Flags; ein Release ist der Zeitpunkt, an dem die Leser die Änderung tatsächlich sehen. Entwickler-Dokumentation, die direkt beim Code liegt, kann Pull Requests folgen.

Wie löse ich eine GitHub Action aus, wenn ein Release veröffentlicht wird?#

Verwenden Sie on: release mit types: [published]. Wenn das Release durch einen anderen Workflow mit dem Standard-GITHUB_TOKEN erstellt wird, startet Ihr Workflow nicht; verwenden Sie für das Release-Tool ein GitHub App-Token oder ein Personal Access Token.

Was ist, wenn wir keine Releases auf GitHub veröffentlichen?#

Nutzen Sie das Signal, das Ihnen zur Verfügung steht: GitLab-Release-Events, Bitbucket-Tag-Pipelines oder einen geplanten Job, der Ihre öffentliche Changelog-Seite oder deren RSS-Feed liest. Cleveras Autopilot kann genau für diesen Fall täglich oder wöchentlich eine Changelog-Seite überwachen.

Können Screenshots und Videos ebenfalls automatisch aktualisiert werden?#

Screenshots können bei jedem Build in UI-Tests erfasst werden. Videos erfordern eine erneute Aufnahme des geänderten Ablaufs; ein KI-Rekorder kann eine gespeicherte Anweisung gegen die neue UI erneut ausführen, und Autopilot kann dies für Clevera-Videos tun, wenn Sie die Adresse Ihrer App (und bei Bedarf einen Login) angeben. Prüfen Sie die neue Aufnahme, bevor Sie sie freigeben.