Choisir un flux de travail

Recommandations de flux de travail pour 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. Comme point de départ, cette page propose quelques flux de travail recommandés à considérer.

Remarque : Il n'existe pas de flux de travail "idéal". Chaque flux de travail présente un ensemble différent de compromis et séduira différents utilisateurs en fonction de leurs préférences, de la taille de leur équipe et des 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, sans friction et 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 simplifiées
  • Pas de branches supplémentaires ou de pull requests à gérer

Compromis

  • Absence de 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 du déploiement des traductions

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 des pull requests (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 flux de travail

Option 3 : Commit sur une branche de fonctionnalité

Lorsque des modifications de contenu sont effectuées dans des 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 des fonctionnalités.

Avantages

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

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 des fonctionnalités plutôt qu'à la disponibilité du contenu
  • Peut générer des traductions pour des fonctionnalités expérimentales qui ne seront jamais livrées

Option 4 : Pull request depuis une branche de fonctionnalité

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

Idéal pour

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

Avantages

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

Compromis

  • Flux de travail 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és et de traductions