継続的インテグレーションの 3 つの Git フック

Git フックがフィーチャー ブランチなどでクリーン ビルドをどのように実行するのかをご覧ください。

Sarah Goff-Dupont Sarah Goff-Dupont

しばらくの間 Git を使用していたなら、おそらく Git フックについて聞いたことがあるでしょう。さらに、Git フックの操作を試したことさえあるでしょう。Git フックは継続的インテグレーションの観点では素晴らしい効果を発揮します。この記事では 3 つのユース ケースについて詳述して、ワークフローに追加できる、すぐに使えるフックを示します。Git フックを初めて使用する場合でも心配無用です、基本から始めましょう。

Git フックを理解する

フックは、コミットやマージなどの操作の前後にカスタム スクリプトをトリガーするための Git のネイティブ メカニズムです。Git のプラグイン システムとして考えてください。Git リポジトリの .git ディレクトリを見ると、「hooks」という名前のディレクトリがあります。これにはフック スクリプトの例のセットが含まれています。

.git/hooks

Git フックのインストールは簡単で十分に文書化されているため、説明を省略します。

フックには、クライアントサイドとサーバーサイドの 2 つの大きなクラスがあります。クライアントサイド フックはローカル ワークステーションで、サーバーサイド フックは Git サーバーで実行されます。

フックは pre- と post- フックにも分類できます。Pre-receive フックは特定の Git 操作の前に呼び出され、必要に応じてオプションで操作をキャンセルすることができます。このフックは、自分やチームメイトが誤ったコードをコミットしないようにリポジトリを外部から守る機能があります。Post-receive フックは操作が完了してから実行されるため、操作をキャンセルするオプションはありません。代わりに、post-receive フックは開発ワークフローの一部を自動化します。

#Git フックを使用することは、小さなロボットのミニオンにすべての願いを叶えてもらうようなものです。

Git フックは次のような操作を自動化します。

  • 関連付けられた Jira 課題キーがコミット メッセージに含まれていることを確認する
  • マージの事前条件を適用する
  • チームのチャットルームに通知を送信する
  • 別のブランチに切り替えた後、ワークスペースを設定する

フィーチャーブランチでクリーンビルドを実行する

サーバー側の pre-receive フックは (コードがエリート ニンジャ ガーディアンなどの特定の条件を満たす場合を除いて) 開発者がコードを main にプッシュできないようにするため、継続的インテグレーションを特に強力に補完して不正なコードからコードを保護します。

開発者は一般に、ブランチに失敗したテストがある際には main にマージしないように十分注意しています。しかし、確認し忘れることもあります。または、他の人とブランチを共有しているときに、ブランチのビルドを最後に確認してからさらに多くの変更が行われることがあります。実によくあることです。

したがって、main への着信マージを検索するサーバーサイド フックを追加できます。見つかった際にスクリプトはブランチの最新のビルドをチェックして、失敗したテストがある場合はマージは拒否されます。同僚で Atlassian のデベロッパー アドボケイトである Tim Petterson は、このためのフック スクリプトを作成して Bamboo で動作するように設計し、Bitbucket で利用できるようにしました。そのスクリプトを入手してカスタマイズし、リポジトリに追加できます。

苦労して得たコードカバレッジを保護する

私が見てきた中で多くのチームが苦労しているのは、コード カバレッジを維持することです。チームは多くの場合、テストでコード ベースを遡って羅列する必要がありました。さらに、テストなしで多数の機能が追加されると苦労して得たカバレッジが低下するのを見て、本当にイライラします。そのため Tim はコード カバレッジの低下から main を保護するために、Pre-receive サーバーサイド フックも作成しました。

また、このフックは main への着信マージも検索します。その後、継続的インテグレーション サーバーを呼び出して、main 上の現在のコード カバレッジとブランチ上のカバレッジをチェックします。ブランチのカバレッジが低下している場合、マージは拒否されます。

ほとんどの継続的インテグレーション サーバーはリモート API を介してコード カバレッジ データを公開しないため、スクリプトによってコード カバレッジ レポートがプルされます。これを行うには、main とブランチのビルドの両方で、共有アーティファクトとしてレポートを公開するようにビルドを設定する必要があります。公開されたら、継続的インテグレーション サーバーを呼び出して main から最新のカバレッジ レポートを取得できます。ブランチ カバレッジの場合は、最新のビルドから、またはマージされるコミットに関連するビルドから、カバレッジ レポートを取得します。

ここで確認しておくと、これはすべてすでにコード カバレッジを実行していることを前提としています。フックは、魔法のようにそれを行うのではなくビルド結果でカバレッジ データを検索するだけです。これはデフォルトで Bamboo だけでなく、Clover (Java と Groovy 用の Atlassian のコード カバレッジ ツール) でも動作します。ただし、任意のビルド サーバーやコード カバレッジ ツールと統合するようにカスタマイズできます。

ブランチのビルドのステータスを確認する

なぜなら、本当の友達は壊れたブランチを友達に確認させないからです。

クライアントサイドの Git フックである、ターミナル ウィンドウ内でブランチ ビルド ステータスを公開する post-checkout フック スクリプトを使用するチャンスです。これも Tim が作成したものです。このスクリプトは、ローカル コピーからブランチのヘッド リビジョン番号を取得して、継続的インテグレーション サーバーにクエリを実行して、そのリビジョンがビルドされているかどうかを、さらにビルドされている場合はそのビルドが成功したかどうかを確認します。

main からブランチを作成するとします。このフックは main の HEAD コミットが正常にビルドされたかを確認し、このコミットからフィーチャー ブランチを作成しても「安全」かどうかを知らせます。または、あるリビジョンのビルドが失敗したことをフックが示しているにもかかわらず、チームのウォールボードでは緑色のビルドが表示されている (またはその逆) とします。これは、ローカル コピーが最新ではないことを示しています。最新版をプルするか、現在のローカル コピーで作業を続けるかはユーザーの自由です。

このフックを使用することで、アトラシアン開発者を悩ませていた無数の頭痛の種が取り除かれました。上述したサーバーサイドのフックの採用についてチームを説得できなかった場合は、少なくともローカルワークステーションでこちらのクライアントサイドのフックをインストールしてください。決して後悔しないでしょう。

こちらの記事で紹介した、継続的インテグレーションのすべての Git フックは、初期設定では Bamboo、Clover、Bitbucket で機能します。ただし、Git フックはベンダーに依存しないため、カスタマイズすればお手持ちのどのようなツールスタックとも使用できます。自動化で成功を勝ち取りましょう!