CI/CD Git: CI フレンドリーな Git リポジトリに役立つ 5 つのヒント

Artifactory (Bamboo 用のアドオンを作成)、Nexus、Archiva のような外部ストレージ システムには、自分のチームや周囲のチームが生成するアーティファクトに対するサポート機能があります。こうしたシステムでは、ビルド開始時に必要なファイルをビルド ディレクトリにプルできます。Maven や Gradle を通してサード パーティのライブラリをプルするようなものです。

ネットワーク上に外部ストレージ システムがまだない場合は、Git Large File 対応 (LFS) の活用が最も簡単です。

Git LFS はリポジトリの大きなファイルにファイルそのものではなくポインターを保存する拡張機能です。ファイル自体はリモートサーバーに保存されます。ご想像のとおり、これでクローン時間が大幅に短縮されます。

おそらく、Git LFS はすでに利用できます。Bitbucket と GitHub はどちらも Git LFS 対応です。

しかし、ビルドが完全なリポジトリの履歴を必要とする場合はどうでしょう。たとえば、ビルド内の工程で POM (または類似の) のバージョン番号を更新する場合、または 2 つのブランチを各ビルドにマージする場合などです。どちらのケースでもリポジトリに変更を反映するには Bamboo が必要になります。

Git では、ファイルの簡単な変更 (バージョン番号の更新など) は、履歴全体がなくてもプッシュできます。しかし、マージについては、Git が 2 つのブランチをさかのぼって共通の祖先を見つける必要があるため、依然としてリポジトリの履歴が必要です。ビルドでシャロー クローンを利用している場合は、このことが問題になります。そこで 3 つめのヒントが登場します。

これによって、クローン作成操作が大幅に高速化します。Bamboo では初期設定でこれが実行されます。

リポジトリキャッシングが役に立つのは、複数のビルドを通じてエージェントを使用している場合のみです。EC2 や他のクラウドプロバイダーでビルドを実行するたびに、ビルドエージェントを作成し削除している場合は、リポジトリキャッシングに意味がなくなります。なぜなら、空のビルドディレクトリで作業していることになり、どのみち毎回リポジトリのフルコピーをプルする必要があるためです。

Shallow clone とリポジトリキャッシングを足して常住エージェントまたはエラスティックエージェントを割ると興味深い事実が分かります。以下の表は戦略を立てる際に役立ちます。

アクティブなブランチのすべてで CI を実行することがよいのは（ほぼ）言うまでもないことです。しかし、あらゆるコミットに対してすべてのブランチでビルドを実行するのはよい考えと言えるでしょうか。たぶん変わりません。その理由は次のとおりです。

たとえば、アトラシアンの場合を考えてみましょう。アトラシアンには 800 人を超える開発者がいて、それぞれ毎日数回リポジトリに変更をプッシュしています。そのほとんどはフィーチャー ブランチへのプッシュです。ビルドの回数は大量です。ビルド エージェントの数をただちに大きく増やさない限り、大量の待ち行列ができます。

アトラシアンの内部 Bamboo サーバーの 1 つには、さまざまなビルド プランが 935 本収納されています。アトラシアンでは 141 のビルド エージェントをこのサーバーに接続して、アーティファクト パッシングやテストの並行実施といったベスト プラクティスによって各ビルドを可能な限り効率的に行えるようにしました。それでもなお、プッシュのたびにビルドすると作業が停滞しました。

Bamboo インスタンスごとに 100 以上のエージェントを毎回ひたすら設定するかわりに、一歩下がってこの作業は本当に必要か考えてみました。答えはノーでした。

そこで、ブランチビルドを常に自動的にトリガーするのではなく、開発者にプッシュボタンを作成する選択肢を与えました。これは厳密なテストとリソースの保全のバランスを取るよい方法です。ほとんどの変更アクティビティはブランチで発生していることから、大きく節約できるチャンスがあります。

開発者の多くはプッシュボタンによる追加制御を好み、ワークフローに自然になじむと感じています。いつビルドを実行するか考えずにすむ自動トリガーを好む開発者もいます。どちらのアプローチも有効です。重要な点は、まずブランチをテストし、ビルドに問題がないことを確認してから上流にマージすることです。

ただし、main や安定版リリース ブランチのような重要なブランチでは話は別です。これらのブランチにおけるビルドは、リポジトリの変更をポーリングするか、Bitbucket から Bamboo にプッシュ通知を送信することによって自動でトリガーされます。すべての進行中の作業で開発ブランチを使用しているため、main に入るコミットは (理論的には) マージされる開発ブランチのみのはずです。さらに、これらのコード行はリリースや開発ブランチ作成の元になります。したがって、各マージに対してタイムリーなテスト結果を得ることが非常に重要です。

数分おきにリポジトリをポーリングして変更を探すのは、Bamboo にとって非常に容易な操作です。しかし、数千のブランチに対する数百のビルドになり、数十個のリポジトリが関与するとなると、あっという間に負荷が膨れ上がります。Bamboo をポーリングする代わりに、変更がプッシュされてビルドが必要になったときに Bitbucket で合図するように設定できます。

通常、この作業はリポジトリにフックを追加することで行いますが、折よく行われた Bitbucket と Bamboo の統合によってこうした内部のセットアップがすべて行われます。Bamboo と Bitbucket をバック エンドでリンクすれば、リポジトリ主導のビルド トリガーが細かい設定なしで即時に機能します。フックも特別な設定も不要です。

ツールに関係なく、リポジトリ主導のトリガーには、ターゲット ブランチがアクティブでなくなったときに自動で終了するというメリットがあります。つまり、何百もの放棄されたブランチをポーリングして CI システムの CPU サイクルを無駄にすることはありません。または、ブランチのビルドを手動でオフにする作業でユーザーが時間を無駄にすることもありません (ただし、やはりポーリングが必要であれば、アクティブでない期間が X 日間続いた後にブランチを無視するように Bamboo を簡単に設定できることは注目に値します)。