Choisir un flux de travail - Lingo.dev CI/CD

Introduction

Lingo.dev CI/CD est conçu pour être flexible et peut s'intégrer à tous les flux de travail existants. Cependant, cette page fournit quelques flux de travail recommandés à considérer comme point de départ.

Remarque : Il n'existe pas de flux de travail « idéal ». Chaque flux de travail présente un ensemble de compromis différents et conviendra à différents utilisateurs en fonction de leurs préférences, de la taille de leur équipe et de leurs méthodes de travail établies.

Flux de travail recommandés

Option 1 : Commit sur la branche principale

Lorsque des modifications de contenu sont fusionnées dans votre branche principale, les traductions sont automatiquement générées et commitées directement sur la branche principale.

Idéal pour

Les équipes qui souhaitent des mises à jour de traduction invisibles et sans friction avec une implication minimale des développeurs.

Avantages

Entièrement automatisé - aucune intervention humaine requise
Les traductions sont immédiatement disponibles dans la branche principale
Configuration et maintenance les plus simples
Aucune branche ou pull request supplémentaire à gérer

Compromis

Aucun processus de révision pour les traductions
Risque que les commits de traduction déclenchent des exécutions CI supplémentaires
Les modifications apparaissent directement dans la branche principale sans visibilité sur ce qui a été traduit
Moins de contrôle sur le moment où les traductions sont déployées

Option 2 : Pull request depuis la branche principale

Après la fusion du contenu dans la branche principale, les traductions sont générées et soumises sous forme de nouvelle pull request depuis la branche principale.

Idéal pour

Les équipes qui souhaitent une visibilité sur les traductions et des capacités de révision tout en maintenant le processus centralisé sur la branche principale.

Avantages

Les modifications de traduction sont visibles et révisables avant la fusion
Piste d'audit claire du contenu traduit
Possibilité d'effectuer des ajustements manuels avant d'accepter les traductions
Maintient un historique propre de la branche principale avec des commits de traduction explicites

Compromis

Nécessite une approbation manuelle de la pull request (sauf si la fusion automatique est configurée)
Léger délai entre les modifications de contenu et la disponibilité des traductions
Pull requests supplémentaires à gérer dans votre workflow

Option 3 : Commit sur la branche de fonctionnalité

Lorsque des modifications de contenu sont effectuées dans les branches de fonctionnalité, les traductions sont automatiquement générées et commitées directement sur ces mêmes branches.

Idéal pour

Les équipes travaillant avec des branches de fonctionnalité à longue durée de vie qui souhaitent que les traductions fassent partie du processus de développement de la fonctionnalité.

Avantages

Les traductions sont prêtes lorsque la fonctionnalité est prête
Aucun travail de traduction séparé nécessaire pendant la revue de la fonctionnalité
Les fonctionnalités complètes incluent à la fois le contenu et les traductions
Fonctionne bien avec les déploiements par feature flags

Compromis

Les commits de traduction apparaissent dans l'historique de la branche de fonctionnalité
Conflits de fusion potentiels si plusieurs développeurs travaillent sur la même branche
Traductions liées à l'achèvement de la fonctionnalité plutôt qu'à la disponibilité du contenu
Peut générer des traductions pour des fonctionnalités expérimentales qui ne seront jamais déployées

Option 4 : Pull request depuis la branche de fonctionnalité

Lorsque des modifications de contenu se produisent dans les branches de fonctionnalité, les traductions sont générées et soumises sous forme de pull requests séparées depuis ces branches.

Idéal pour

Les équipes qui souhaitent un contrôle et une visibilité maximaux sur les traductions tout en maintenant des workflows de branches de fonctionnalité.

Avantages

Visibilité complète sur les modifications de traduction au niveau de la fonctionnalité
Possibilité de réviser et d'ajuster les traductions avant l'achèvement de la fonctionnalité
Séparation claire entre le développement de la fonctionnalité et l'intégration des traductions
Flexibilité temporelle pour accepter les mises à jour de traduction

Compromis

Workflow le plus complexe à gérer
Plusieurs pull requests par fonctionnalité (fonctionnalité + traductions)
Risque que les pull requests de traduction deviennent obsolètes si les fonctionnalités changent
Nécessite une coordination entre les pull requests de fonctionnalité et de traduction