Git ブランチを切るとき、プルリクエストに対応するとき、ビルドの状況見えてますか? Git と CI の効果的な付き合い方

【 この記事は、4462人に読まれています】

はじめに


Git によって、ブランチの利用が促進されてきました。依然としてブランチ戦略は重要ですが、フィーチャーブランチモデル (GitHub フロー) や、git-flow により、モデル化もされてきています。

これらと深く関係がるものの一つが、ビルドです。ソースコードをバージョン管理していたとしても、最終成果物は、ビルド成果物ですし、そこでの自動テストの状況も見過ごすわけにはいきません。そこでソースコードとビルドが交わる主な場所を見ていくと、

  1. ブランチを作成するとき: 分岐元のビルド品質
  2. プルリクエストに対応するとき: レビュー対象のブランチのビルド品質

が気になります。

(1) のビルドの状況がわからないと、ビルドが通らなかったり、テストが通らないコードを対象としてコード変更を行うことになってしまいかねません。(2) のビルド状況がわからないと、不必要にコードレビューのプロセスや手間を増やすことになります。

では、どうするか?

Git リポジトリと継続的インテグレーション (CI) ツールが連携してお話ししあっていればいいということになります。

 

ブランチを作成するときにビルド状況を知る


まず、下の画面ショットをご覧ください。

image
これは、Git リポジトリ管理をしてくれる Atlassian Stash のブランチ作成の画面です。「分岐元」に着目してください。分岐元のブランチ名の横に、アイコンが表示されています。ホバーするとビルドの状況が吹き出しで表示されていることもわかります。拡大すると、

image
より状況をよく確認できます。これは、「master」から「feature/REW-8」というブランチを作成しようとしているところです。したがって、master のビルド品質がよろしくないと、REW-8 という feature を作成するときに大きな影響を与えてしまうということになりますが、上の例では、ビルドが成功しているので、今、master からブランチを切ることは問題ないと判断できます。

より詳細を見るには、アイコンをクリックするだけです。

image
6日前に #17 というビルドIDにて、ビルドが実施され、6件のテストが成功しているというレポートをみることができます。より詳細を見たい場合は、さらにクリックすると継続的インテグレーションとデプロイメントの Atlassian Bamboo の該当ビルドのレポートに遷移します。

では、こちらはどうでしょうか?

image
「feature/REW-7.2」からブランチを切ろうしていますが、アイコンが赤いです。これはビルドが失敗していることを示します。アイコンをクリックして詳細を見てみると、以下のようになっています。

image
1週間前に #2 というビルドIDで、ビルドが行われ、1件のテストが失敗していることがわかります。

このブランチを元にブランチを切るともれなく、テストが失敗するコードがついてくることがわかるわけです。

Stash と Bamboo を組み合わせて活用することで、フィーチャーブラインチモデルのように、必要に応じてブランチを作成するとしても、そのブランチでコードの変更が発生すると、それを Bamboo が自動検知して、継続的インテグレーションを実行し、レポートしてくれる環境を作ることができます(設定方法は、後述します)。利用者にあたる開発者は、この設定方法を知る必要の最小限ですみますし、ブランチ作成時や、コミット/プッシュしたときに何か特別なアクションを起こす必要は一切ありません。普段通りに開発していれば、裏で CI が実施され、そのブランチのビルド品質が自動レポートされる仕組みです。

もちろん、各ブランチのビルド品質は、一覧でみることができます。

image
 

 

レビューするときに、ビルド状況を知る


次に重要なのは、コード変更後です。まずは、こちらをご覧ください。

image
このプリリクエスト(コードレビュー依頼)をする際に、コードの変更箇所はもちろんのこと、ビルドの品質(ほかにも Atlassian JIRA と連携していれば、関連するタスクやバグの情報も)も知ることができます。

image
ご覧のように、赤いアイコンがあったら、レビュー依頼ださないですよね?自分のコードをまず自分で見直すこととなるでしょう。

もし、万が一、それでもプルリクエストを出してしまっても大丈夫です!レビュワーさんもそのことを知ることができます。

image
ビルドが失敗しているのですから、コードレビューする価値なしと判断して、即座に、「拒否」すればいいですw

image
 

image
もちろん、コード変更を終え、その後に Bamboo が自動実行した継続的インテグレーションの結果、ビルド品質に問題なければ、以下のように表示されます(過去、このブランチに関係しているビルドの履歴も表示されます)。

image

プルリクエストをすれば、レビュワーも正しく状況を知ることができます。

image
継続的インテグレーションの結果であるビルド品質、動機であるタスクやバグ修正の情報(JIRA と連携している場合)がわかれば、レビューは、省力化できるはずです。

image
安心して、適切なレビューを行い、承認し、マージすることができますね。

 

継続的インテグレーションの裏側


さて、フィーチャーブランチモデルで目的ごとに動的にブランチを作成したにも関わらず、継続的インテグレーションが実施されていました。設定は後述しますが、Bamboo がどのように動いてどのように記録しているかを見てみましょう。

image
Bamboo では、「ASP.NET」 という Git リポジトリに対して、継続的インテグレーション(一連のビルドとテストの実行ワークフロー)を定義しているだけにすぎません。それは、主に、master でのコード変更に対する自動ビルドと自動テストとして割り当ててます。

そこで、とある設定(後述)をすると、master での CI の実行だけでなく、ブランチ上でも CI を実行してくれ、各ブランチごとにレポートもしてくれるようにすることができます。この設定が活きている場合は、アイコンで表示されます。

image
に記載されている「ブランチ」っぽいアイコンがそれです。

このアイコンをクリックすると、以下のようにレポートされます。

image
このように、ブランチが作られ、コミットされた数だけ CI がそれぞれで走り、レポートされます。一覧表示だと以下になります。

image
ブランチごとに再度ビルドを実行したり、個別に設定を変えたりもできます。どのブランチでより多くのコード変更が行われているかもわかりますので、どの機能やバグについてコードが安定しにくいのかの目安とすることできますね。

それぞれのビルドの詳細ももちろん知ることができます。

 

継続的インテグレーションの裏側の設定


さて、それでは Bamboo でどのような設定をしていたのかについて見ていきましょう。なんか難しい設定をしていそうですが、実はとてもシンプルな設定をしているにすぎません。

image
まず、CI 用のプロジェクトを作成します(Bamboo はビルドとデプロイのプロジェクトを明確に切り分けているのでビルドに専念したワークフローと設定が容易にできます)。すると、いくつかのタブで設定ができることがわかります。

ここで着目したいのは、二か所のみです。「Repositories」と「Trigger」と「Branches」です。

「Repositories」では、CI を実施する対象であり、CI を実行するトリガーである Git リポジトリを指定します。

image
この例では、Bamboo としっかりお話しができるようになっている Stash で管理された Git リポジトリが指定されています。

次に「Trigger」です。

image
CI を実行するきっかけの設定では、いくつかの選択肢がありますが、Stash の場合はより密な連携ができるようになっています(GitHub や Bitbucket, Naked Git, Mercurial, Subversion などでももちろん使うことができます)。

「Stash repository triggers the build when changes are committed」を指定すれば、Stash で管理する Git リポジトリに対してコミットが発生したタイミングで即座に CI が走ります。

そして、今回のキモにあたる「Branches」です。

image
ここで、重要なのはたった一か所です。

「Automatically manage branches」にて「Create plan branches for branches detected in the repository」にチェックを入れるだけです。

また、必要に応じて、自動マージも設定できます。やりたければ、「Merging」にて、「Branch merging enabled」にチェックを入れるだけです。

余談ですが、「JIRA feature branches」にて、「Create remote links from JIRA issues to plan branches」にチェックしておけば、ブランチ名に JIRA 課題キーが含まれていれば、それを自動的にそのビルドに対して、タスクやバグ修正としてリンクを作成してくれます(JIRA と連携している場合は、とても便利です)。

ブランチが作成され、コミットするたびに CI が走るのは便利だけど、それだけ膨大なデータが残ることになるよね?と心配なあなた。もちろん、ケアされます。

image
クリーンナップの期間設定ができますので、一定期間を経過したら掃除してくれます。掃除されたくない場合は、「0」 を設定するだけです。

 

まとめ


見てきたように、ブランチを多用するワークフローであっても、CI のメリットを開発者の負担なく得ることができることがお分かりいただけたと思います。またその設定についても特段難しいことがないのも見ていただきました。

こういうところに必要以上に時間を割くのではなく、もっとクリエイティブな価値を生む仕事に注力していただけたらなと思います。その一つの選択肢として、Stash + Bamboo (+ JIRA) は、とても有効ではないでしょうか。

 

無音声デモ動画で体感を


画面ショットだけではという方は、このデモ動画をご覧ください。一連の開発の流れの中で、ブランチの作成と、プルリクエストのタイミングでビルド品質がわかるとどれだけ安心感があるのかを感じていただけるかと思います。



 

 

 

【 この記事は、4462人に読まれています】

コメントを残す