Auswahl eines Workflows - Lingo.dev CI/CD

Einführung

Lingo.dev CI/CD ist flexibel konzipiert und lässt sich in bestehende Workflows integrieren. Als Ausgangspunkt bietet diese Seite einige empfohlene Workflows zur Orientierung.

Hinweis: Es gibt keinen "besten" Workflow. Jeder Workflow hat unterschiedliche Kompromisse und spricht verschiedene Nutzer an – abhängig von ihren Präferenzen, der Teamgröße und etablierten Arbeitsweisen.

Empfohlene Workflows

Option 1: Commit in Main-Branch

Wenn Inhaltsänderungen in Ihren Main-Branch gemergt werden, werden Übersetzungen automatisch generiert und direkt zurück in den Main-Branch committed.

Am besten geeignet für

Teams, die unsichtbare, reibungslose Übersetzungsupdates mit minimalem Entwickleraufwand wünschen.

Vorteile

Vollständig automatisiert – keine menschliche Intervention erforderlich
Übersetzungen sind sofort im Main-Branch verfügbar
Einfachste Einrichtung und Wartung
Keine zusätzlichen Branches oder Pull Requests zu verwalten

Kompromisse

Kein Review-Prozess für Übersetzungen
Potenzial für Übersetzungs-Commits, die zusätzliche CI-Durchläufe auslösen
Änderungen erscheinen direkt im Main ohne Sichtbarkeit darüber, was übersetzt wurde
Weniger Kontrolle darüber, wann Übersetzungen deployed werden

Option 2: Pull Request aus Main-Branch

Nachdem Inhalte in Main gemergt wurden, werden Übersetzungen generiert und als neuer Pull Request aus dem Main-Branch eingereicht.

Am besten geeignet für

Teams, die Sichtbarkeit und Review-Möglichkeiten für Übersetzungen wünschen und den Prozess gleichzeitig auf dem Main-Branch zentralisiert halten möchten.

Vorteile

Übersetzungsänderungen sind sichtbar und reviewbar vor dem Mergen
Klarer Audit-Trail darüber, welche Inhalte übersetzt wurden
Möglichkeit für manuelle Anpassungen vor Akzeptanz der Übersetzungen
Erhält saubere Main-Branch-Historie mit expliziten Übersetzungs-Commits

Kompromisse

Erfordert manuelle Pull-Request-Genehmigung (sofern nicht Auto-Merge konfiguriert ist)
Leichte Verzögerung zwischen Inhaltsänderungen und Verfügbarkeit der Übersetzungen
Zusätzliche Pull-Requests, die in Ihrem Workflow verwaltet werden müssen

Option 3: Commit zum Feature-Branch

Wenn Inhaltsänderungen in Feature-Branches vorgenommen werden, werden Übersetzungen automatisch generiert und direkt in dieselben Branches committed.

Am besten geeignet für

Teams, die mit langlebigen Feature-Branches arbeiten und möchten, dass Übersetzungen Teil des Feature-Entwicklungsprozesses sind.

Vorteile

Übersetzungen sind fertig, wenn das Feature fertig ist
Keine separate Übersetzungsarbeit während der Feature-Überprüfung erforderlich
Vollständige Features umfassen sowohl Inhalte als auch Übersetzungen
Funktioniert gut mit Feature-Flag-Deployments

Kompromisse

Übersetzungs-Commits erscheinen in der Feature-Branch-Historie
Potenzielle Merge-Konflikte, wenn mehrere Entwickler am selben Branch arbeiten
Übersetzungen sind an die Feature-Fertigstellung gebunden und nicht an die Inhaltsbereitschaft
Kann Übersetzungen für experimentelle Features generieren, die nie ausgeliefert werden

Option 4: Pull-Request vom Feature-Branch

Wenn Inhaltsänderungen in Feature-Branches auftreten, werden Übersetzungen generiert und als separate Pull-Requests von diesen Branches eingereicht.

Am besten geeignet für

Teams, die maximale Kontrolle und Sichtbarkeit über Übersetzungen wünschen und gleichzeitig Feature-Branch-Workflows beibehalten.

Vorteile

Vollständige Sichtbarkeit der Übersetzungsänderungen auf Feature-Ebene
Möglichkeit, Übersetzungen vor Abschluss des Features zu überprüfen und anzupassen
Klare Trennung zwischen Feature-Entwicklung und Übersetzungsintegration
Flexible Zeitplanung für die Annahme von Übersetzungsaktualisierungen

Kompromisse

Komplexester zu verwaltender Workflow
Mehrere Pull-Requests pro Feature (Feature + Übersetzungen)
Potenzial für veraltete Übersetzungs-Pull-Requests, wenn sich Features ändern
Erfordert Koordination zwischen Feature- und Übersetzungs-Pull-Requests