こんにちは、クラウドエース第三開発部の賀渝華です。中国・四川省の出身で、来日して 9 年になります。 背景として、弊社では会社全体としてソース管理を GitHub から GitLab へ移行していく方針があります。その流れの中で、先日、担当している案件の Google Cloud プロジェクト群の継続的インテグレーション／継続的デリバリー（以下、CI/CD）を GitLab へ移す作業を担当することになりました。 「リポジトリを移すだけでしょ？」と軽く考えていたのですが、いざ着手すると Cloud Build の世代差やトリガーの作り直し、既に開いていた Merge Request（以下

本記事は「 One Task, Two Providers: Coordinating Changes Across GitLab and GitHub in one session 」を翻訳したものです。 Kiro Web は、既存の GitHub サポートに加えて、 GitLab でも動作する ようになりました。より興味深いのは、コードが GitLab と GitHub の両方にまたがって存在する場合に何が起きるかです。両方からリポジトリを同じセッションに追加し、単一の変更を記述すれば、Kiro がそれを両方にわたって実行し、一方にはマージリクエスト（MR）を、もう一方にはプルリクエスト（PR）を開いてくれます。これは、コードが 1 つのきれいな場所に収まっていないときに意味を持ちます。 2 つの場所に存在するコード 多くのチームはプロバイダーをまたいで分かれており、たいていそれには正当な理由があります。オープンソースの SDK はコミュニティが見つけられるように GitHub に置かれ、それが通信するサービスは GitLab 上にプライベートのまま残されている。あるいは買収によって、組織の半分が一方のプロバイダーに、もう半分が別のプロバイダーに分かれてしまった。あるいはフロントエンドとバックエンドのチームが、何年も前にたまたま別々のツールに落ち着いただけ、ということもあります。理由が何であれ、そのコストは変更が両方にまたがった瞬間に現れます。1 つの論理的な更新が、2 つのコンテキストで 1 つのプルリクエストと 1 つのマージリクエストになり、ステップを忘れて両者が同期からずれてしまう機会が 2 回生じるのです。 小さな例 ここで使うセットアップを示します。本物の代わりとして、あえてシンプルなものにしています。その場所に、あなたの実際のサービスと SDK を思い浮かべてください——数千行、本物のビジネスロジック、本物の利用者がいるものを。 GitLab 上のプライベートサービスがあるとします。 そして、 GitHub 上のパブリック SDK が、そのサービスをラップしています。 email フィールドをエンドツーエンドで追加したいとします。サーバー側の変更は GitLab に属し、SDK 側の変更は GitHub に属します。これは、2 つのリポジトリ、2 つのプロバイダーにまたがって、変更を加えないといけません。 1 つのプロンプト、両方のリポジトリ GitLab と GitHub の両方をすでに接続した状態で、セッションを開始し、両方のリポジトリ（GitLab の user-service と GitHub の user-sdk ）をアタッチします。そして、変更をシンプルな言葉で記述します。 両方のリポジトリがセッション内にあるため、Kiro はそれらを無関係な 2 つのタスクとして扱うのではなく、一緒に推論します。 隔離されたサンドボックスの中で作業し、両方のリポジトリを探索し、それぞれの側が何を必要とするかを把握し、変更を行います。サービスではレコードとレスポンスに email を追加し、SDK では User 型と使用例を更新します。各リポジトリにフィーチャーブランチを作成し、明確なメッセージでコミットします。 完了すると、2つの変更が待っています。サービス用の GitLab 上のマージリクエスト は以下のようになります。 そして、SDK 用の GitHub 上のプルリクエスト は以下のようになります。 それぞれが、何が変わったかと、そのアプローチの説明を伴っています。あなたは各変更を、それぞれのホームプロバイダー上で、チームがすでに使っているまさにそのワークフローでレビューしてマージします。レビュープロセスについては何も変わりません。ただ、クロスリポジトリの調整作業を自分でやらなくて済んだ、というだけです。 まとめ プロバイダーをまたぐ分割は、しばしば現実的で、維持する価値があります——パブリック対プライベート、あるチーム対別のチーム。維持する価値がないのは、1 つの変更を両方にわたって整合させるための手作業の労力です。Kiro Web に GitLab と GitHub を接続すれば、1 つのプロンプトが変更をエンドツーエンドで一貫させ、それでもあなたはすでに信頼しているプロバイダー上で、きれいな MR と PR をレビューできます。 Kiro Web で GitLab と GitHub を接続し、両方にまたがる変更を試してみてください。Kiro Web は app.kiro.dev で、Pro・Pro+・Power のサブスクライバー向けにプレビュー提供中です。さらに詳しくは GitLab ガイド をご覧になり、次に何がリリースされるかを知るには Kiro Web の changelog をフォローしてください。

はじめに NTTデータグループ 技術革新統括本部 AI技術部の小倉 光瑛です。 私は入社1年目から現在まで、iPaaS/API連携基盤チームに所属し、4年間、MuleSoft勉強会の企画・運営に携わってきました。 その間、MuleSoftのDeveloper／Architect関連の資格を4つ取得しながら、どうすればチームとして学びを継続できるかを試行錯誤してきました。 勉強会はチームとして初の取り組みで、大変な面もありましたが、継続して良かった点も多くありました。 本記事を通じて、「エンジニア勉強会を開催してみよう」、「自組織の勉強会にも取り入れてみよう」と感じてもらえたら嬉しいで