Une tâche, deux fournisseurs : coordonner les changements entre GitLab et GitHub dans une même session

Kiro Web fonctionne maintenant avec GitLab, en plus de la prise en charge existante de GitHub. La partie la plus intéressante, c'est ce qui se passe quand votre code réside à la fois sur GitLab et sur GitHub : vous pouvez ajouter des dépôts des deux à la même session, décrire un seul changement, et laisser Kiro le porter sur les deux, en ouvrant une merge request sur l'un et une pull request sur l'autre. C'est important quand votre code ne réside pas dans un seul endroit bien ordonné.

Du code qui réside à deux endroits

Beaucoup d'équipes sont réparties entre plusieurs fournisseurs, et habituellement pour de bonnes raisons. Votre SDK open source réside sur GitHub, où la communauté peut le trouver, tandis que le service auquel il s'adresse reste privé sur GitLab. Ou une acquisition a laissé la moitié de l'organisation sur un fournisseur et l'autre moitié sur un autre. Ou les équipes frontend et backend ont simplement atterri sur des outils différents il y a des années. Quelle que soit la raison, le coût se manifeste dès qu'un changement touche les deux côtés. Une mise à jour logique devient une pull request et une merge request dans deux contextes distincts, avec deux occasions d'oublier une étape et de laisser les deux côtés se désynchroniser.

Un petit exemple

Voici la configuration que je vais utiliser. C'est un substitut délibérément trivial pour l'exemple réel. Imaginez votre véritable service et SDK à sa place : des milliers de lignes, de la vraie logique d'affaires, de vrais consommateurs.

Un service privé sur GitLab :

Le dépôt user-service sur GitLab, sur la branche main, contenant quatre fichiers : .gitignore, README.md, package.json et server.js — tous provenant du commit initial de Brian Beach.

Un SDK public sur GitHub qui encapsule ce service :

Le dépôt user-sdk sur GitHub, sur la branche main avec 2 branches et 1 commit de Brian Beach. Les fichiers incluent un répertoire src, .gitignore, README.md, package.json et tsconfig.json — tous provenant du commit initial.

Imaginez que je veuille ajouter un champ email, de bout en bout. Le changement du serveur revient à GitLab. Le changement du SDK revient à GitHub. C'est une seule idée qui doit se retrouver dans deux dépôts, sur deux fournisseurs, sans que les deux se désynchronisent.

Une requête, deux dépôts

Avec GitLab et GitHub déjà connectés, je démarre une session et j'y joins les deux dépôts — user-service de GitLab et user-sdk de GitHub. Puis je décris le changement en langage simple :

L'interface de Kiro Web avec la requête « Add an email field to the user response in the service, and expose it through the SDK. » Les deux dépôts sont joints à la session : brianbeach/user-service de GitLab et brianjbeach/user-sdk de GitHub. Le mode autonome est activé.

Comme les deux dépôts sont dans la session, Kiro raisonne à leur sujet ensemble plutôt que de les traiter comme deux tâches sans lien.

Le journal de raisonnement de Kiro montrant qu'il a identifié la tâche comme un changement multi-dépôts couvrant GitLab et GitHub, a cloné les deux dépôts, a inspecté leur structure et a délégué l'implémentation à un sous-agent planificateur pour gérer à la fois les changements de code et le flux de travail MR/PR.

Travaillant dans son bac à sable isolé, il explore les deux dépôts, détermine ce dont chaque côté a besoin, et apporte les changements — en ajoutant email aux enregistrements et à la réponse dans le service, puis en mettant à jour le type User et l'exemple d'utilisation dans le SDK. Il crée une branche de fonctionnalité dans chaque dépôt et fait des commits avec des messages clairs.

Le résumé de session de Kiro après avoir terminé le changement multi-dépôts : email a été ajouté à server.js dans le user-service GitLab et à src/index.ts dans le user-sdk GitHub, avec des liens vers la MR GitLab et la PR GitHub qui en résultent.

Une fois terminé, deux changements attendent. Une merge request sur GitLab pour le service.

Merge request GitLab intitulée « Add email field to user response », ouverte par Brian Beach pour fusionner feat/add-email-field dans main. Le résumé décrit l'ajout d'un champ email au modèle de données utilisateur, le point de terminaison GET /users/:id retournant maintenant id, name et email.

Et une pull request sur GitHub pour le SDK.

Pull request GitHub #1 intitulée « Add email field to User type », ouverte par le bot kiro-agent au nom de brianjbeach. Elle fusionne la branche feat/add-email-field dans main, avec un résumé notant que email: string a été ajouté au type User dans src/index.ts et que le SDK compile proprement.

Chacune comporte une description de ce qui a changé et de l'approche. Vous révisez et fusionnez chacune sur son fournisseur d'origine, exactement selon le flux de travail que votre équipe utilise déjà. Rien ne change dans votre processus de révision. Vous n'avez simplement pas eu à faire vous-même la comptabilité entre dépôts.

En résumé

La répartition entre fournisseurs est souvent réelle et vaut la peine d'être maintenue : public par rapport à privé, une équipe par rapport à une autre. Ce qui ne vaut pas la peine d'être maintenu, c'est l'effort manuel de tenir ensemble un seul changement à travers les deux. Avec GitLab et GitHub connectés dans Kiro Web, une seule requête garde le changement cohérent de bout en bout, et vous obtenez tout de même une MR et une PR propres à réviser sur les fournisseurs auxquels vous faites déjà confiance.

Connectez GitLab et GitHub dans Kiro Web et essayez un changement qui couvre les deux. Kiro Web est en préversion sur app.kiro.dev pour les abonnés Pro, Pro+ et Power. Pour aller plus loin, consultez le guide GitLab, et suivez le journal des changements de Kiro Web pour voir ce qui s'en vient.