Teamcityを使って複数のGitリポジトリを管理する

みなさんが所属する組織ではいくつのGitリポジトリを管理していますか？きっと依存関係にある複数のGitリポジトリが存在するのではないでしょうか？私が所属する会社の顧客向けプロジェクトでは5つのGitリポジトリを用い、各チームがそれぞれのGitリポジトリを管理します。残念ながら全Gitリポジトリが依存関係にあるため、あるチームの変更したコードが他のチームのテストで障害を計上させてしまうことが多々ありました。

GitHub、GitLab、また、その他CI系ツールは素晴らしいパイプライン機能を提供していますが、単一のGitリポジトリ向けである場合が多いです。私が知る限り、複数Gitリポジトリを管理できるものは見たことがありません。「そのGitリポジトリの構成を変えたらいいんじゃないの？」と考えつくかもしれませんが、ライセンス、また、ビジネス上の理由ため、現場では構成変更できないことが多いのです。

そんな背景の中Teamcityと出会い、私なりの方法が見つかったので紹介してみたいと思います。

Teamcityの紹介

こちらを参照してください。

Docker環境でTeamcityを動かす

Docker ComposeでTeamcityを起動

1. teamcityフォルダを作成し、以下のdocker-compose.yamlファイルを配置

   以下、c:\mycode\docker\teamcityというフォルダパスを用いています。

   version: "3.9"
   services:
     teamcity-server:
       image: jetbrains/teamcity-server
       volumes:
         - c:/mycode/docker/teamcity/server/config:/data/teamcity_server/datadir/config
         - c:/mycode/docker/teamcity/server/system:/data/teamcity_server/datadir/system
         - c:/mycode/docker/teamcity/server/lib:/data/teamcity_server/datadir/lib
         - c:/mycode/docker/teamcity/server/logs:/opt/teamcity/logs
       ports:
         - "8111:8111"
     teamcity-agent:
       image: jetbrains/teamcity-agent
       user: 0:0
       environment:
         SERVER_URL: teamcity-server:8111 
       volumes:
         - c:/mycode/docker/teamcity/agent:/data/teamcity_agent/conf
         - /var/run/docker.sock:/var/run/docker.sock
       privileged: true
   

2. 同じフォルダ内にDocker Volumesマウント用のサブフォルダを作成

   • agent
   • server
   • server/config
   • server/system
   • server/lib
   • server/logs

3. Docker Composeを用いて起動

   docker-compose up -d
   

4. http://localhost:8111/からTeamcityへアクセスし初期設定を行う。

   1. Proceedをクリック
      
   2. Proceedをクリック
      
   3. スクロールダウンし、Accept license agreementのチェックを入れ、Continueをクリック
      
   4. 任意のユーザー名とパスワードを入力し、Create Accountをクリック
      
   5. Teamcityのトップ画面が表示されていることを確認
      
   6. ナビゲーションにあるAgentsをクリックし、表示された画面でUnauthorizedをクリックし。AuthorizeをクリックすることによってTeamcity Agentを登録する。
      
   7. Teamcity Agentが登録されたことを確認。
      

サンプルプロジェクトのインポート

1. サンプルプロジェクト（ZIPファイル）をダウンロード
   ダウンロード

2. ナビゲーションにあるAdministrationをクリック
   

3. 左のメニューからProject Importをクリックし、前ステップでダウンロードしたZIPファイルをアップロード
   
   
   
   

4. ナビゲーションにあるProjectsをクリックし、Sample Projectがインポートされていることを確認
   

サンプルプロジェクトの実行

1. Triggerの右にあるRunをクリックする
   

2. その後、Triggerをクリックし、実行されたBuild numberをクリックし、Dependenciesタブをクリックする
   
   
   

ここで分かることはTriggerはE2Eに、E2EはDeployに、そして、DeployはBuild Repo AとBuild Repo Bに依存していることです。そのため、依存するジョブを再帰的に実行しているのです。

他チーム影響ありのコードを書いた場合

例えば、Repo Bを扱うBチームがRepo Aを扱うAチームに影響を与えてしまう変更を新しいGitブランチに作成したとします。その場合、TriggerでそのGitブランチを実行すると、以下のような結果を得ます。

各GitリポジトリのBuildやその後のDeployには成功したものの、Gitリポジトリ間の整合性をチェックするE2Eでは失敗しています。このようにして、BチームはPull Requestを作成する時点でチームAへの影響に気づくことができます。

Teamcityの嬉しいことは選択したGitブランチが依存関係にあるジョブへ受け継がれることです。選択されたGitブランチが存在しない場合はデフォルトのGitブランチを選択してくれます。

このようなパイプラインとE2Eジョブをチーム間で共有することによって、整合性による問題をマージする前に気づくことができるのです。

Triggerジョブの設定

では、Triggerジョブがどのような設定をしているか見てみましょう。VCS Rootsに2つのGitリポジトリを登録し、このジョブではチェックアウトをしないようにしているのです。この設定をすることによって、Triggerジョブは2つのGitリポジトリからGitブランチのリストを取得することができるのです。

終わりに

開発プロジェクトを行うにあたって、各チームは「停止」することはあっても「後退」することはあってはなりません。しかし、開発規模が大きくなってしまうと、チーム間やGitリポジトリ間の整合性を取るだけでも難しくなってしまいます。今回は私が編み出した方法を紹介させていただきましたが、もし他に複数Gitリポジトリを管理する方法をご存知でしたらぜひ共有してください。