Auswahl eines Workflows - Lingo.dev CI/CD

Einführung

Lingo.dev CI/CD ist darauf ausgelegt, flexibel zu sein und kann in alle bestehenden Workflows integriert werden. Als Ausgangspunkt bietet diese Seite jedoch einige empfohlene Workflows zur Berücksichtigung.

Hinweis: Es gibt keinen "besten" Workflow. Jeder Workflow hat unterschiedliche Kompromisse und wird je nach Präferenzen, Teamgröße und etablierten Arbeitsweisen unterschiedliche Nutzer ansprechen.

Empfohlene Workflows

Option 1: Commit zum Main-Branch

Wenn Inhaltsänderungen in Ihren Main-Branch zusammengeführt werden, werden Übersetzungen automatisch generiert und direkt wieder in den Main-Branch committed.

Am besten geeignet für

Teams, die unsichtbare, reibungslose Übersetzungsaktualisierungen mit minimaler Entwicklerbeteiligung 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 Überprüfungsprozess für Übersetzungen
Potenzial für Übersetzungs-Commits, zusätzliche CI-Läufe auszulösen
Änderungen erscheinen direkt im Main-Branch ohne Sichtbarkeit dessen, was übersetzt wurde
Weniger Kontrolle darüber, wann Übersetzungen bereitgestellt werden

Option 2: Pull-Request vom Main-Branch

Nachdem Inhalte in den Main-Branch zusammengeführt wurden, werden Übersetzungen generiert und als neuer Pull-Request vom Main-Branch eingereicht.

Am besten geeignet für

Teams, die Übersetzungssichtbarkeit und Überprüfungsmöglichkeiten wünschen, während der Prozess auf dem Main-Branch zentralisiert bleibt.

Vorteile

Übersetzungsänderungen sind sichtbar und überprüfbar vor dem Zusammenführen
Klarer Prüfpfad darüber, welche Inhalte übersetzt wurden
Möglichkeit, manuelle Anpassungen vor dem Akzeptieren von Übersetzungen vorzunehmen
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 in 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 des Feature-Reviews erforderlich
Vollständige Features beinhalten 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 aus Feature-Branch

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

Am besten geeignet für

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

Vorteile

Volle Transparenz bei Übersetzungsänderungen auf Feature-Ebene
Möglichkeit, Übersetzungen vor Feature-Fertigstellung zu überprüfen und anzupassen
Klare Trennung zwischen Feature-Entwicklung und Übersetzungsintegration
Flexible Zeitplanung für die Akzeptanz von Übersetzungsupdates

Kompromisse

Komplexester Workflow zu verwalten
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