実践反復型ソフトウェア開発を読む part3～再現可能なビルド管理

「実践 反復型ソフトウェア開発」は何度読み直しても参考になる。
今まで暗黙的に行なってきた作業に、きちんとした名前が付与されることで、その作業の意味を捉え直すことができるからだ。
多分、ソフトウェア工学の中でも開発プロセスに興味がある人にとっては必須の本だろうと思う。

「実践 反復型ソフトウェア開発」の内容は、構成管理・ビルド管理・障害管理・テスト管理の4つの分野に大きく分けることができる。
第4章「構成管理とブランチの戦略」の部分は以前まとめたので、今回は、ビルド管理についてメモ書き。

【参考】
実践反復型ソフトウェア開発を読む part1～ブランチの戦略: プログラマの思索

実践反復型ソフトウェア開発を読む part2～マージの戦略: プログラマの思索

【1】ビルドの再現可能性

ビルドの重要な性質は、再現性または再現可能性、反復可能性。
つまり、いつ誰がビルドしても、同じようなモジュールを作れること。

WF型開発では、プロセスという工程の品質を再現させることに注力する。
そのために、属人化を廃し、作業手順を標準化する方向に走って、ソフトウェア開発からクリエイティビティをなくした。

でも、ソフトウェア開発における再現性の対象は、ビルド管理であるべき。
プログラミングや設計ではなく、ソースがあれば、いつ誰でも同じモジュールを作れることの方が大切だ。

【2】ビルドの種類

ビルドには幾つかの種類がある。
まずは、ビルドタイミングや品質に関する観点。

(1)CIビルド、継続的な統合ビルド
　必要に応じて、1日に数回ビルドして、自動テスト(オートメーション)も走らせる。
　ビルドエラーが発生すれば、すぐに障害票を起票して、即修正する。

(2)デイリービルド、日次ビルド
　1日1回、普通は夜間にビルドする。
　すべてのオートメーションを実行する。

(3)ウイークリービルド、週次ビルド
　週1回ビルドする。
　テストチームにリリース可能な製品を渡す。
　開発チームは、Testableな品質を保証するのが前提。
　品質OKなら、テストチームは受入テストを実施する。

　ビルドをテストチームにリリースする前に、テストチームによるテストが実施できる品質かどうか判定するテスト、つまり、スモークテスト(またはBVT)を実施するのが普通。
　スモークテストは主要な受入テストケースによるテストが多いだろう。

(4)マイルストーンビルド
　ユーザにリリース可能な製品を渡す。

次は、ビルドの手順に関する観点。

(1)フルビルド、完全ビルド
　全ソースをビルドする。
　普通は、各種コンポーネントを組み合わせて最終モジュールをビルドするので、全てのコンポーネントもビルドするとなると、ビルド時間がとてもかかるのが普通。

(2)インクリメンタルビルド、部分ビルド
　前回のビルド時から修正されたソースとそれに依存するファイルのみをビルドする。
　ビルド時間を短縮できる。
　但し、ビルドブレークが多発して、ビルドの再現性が落ちる場合、フルビルドに戻す。

(3)クリーンビルド、リビルド
　前回のビルドで生成された中間ファイルを全て削除して、ビルドする。
　ant cleanなどの処理に相当する。
　クリーン後にインクリメンタルビルドするなら、フルビルドと同じ。

　リビルドは、ビルドを再実行すること。
　VisualStudioの機能では、ビルドのメニューを選択するとインクリメンタルビルド、リビルドのメニューを使うとフルビルドのように使い分けることができるようだ。

ビルドの準備と管理

Visual Studio でのプロジェクトとソリューションのビルドおよびクリーン

(4)並行ビルド、分散ビルド
　マルチスレッド化したビルド処理が並行ビルド。
　複数のマシンで複数のビルドを並行して走らせるのが分散ビルド。
　いずれも、ビルド時間を劇的に短縮できるのが利点。

　並行ビルドは、AntならばParallelタスクを使うと良いらしい。

　Jenkinsでは、分散ビルドをマスター・スレーブ方式で実現している。
　
第3回　Hudsonによるチーム間の連携：Hudsonを使ったアジャイルな開発入門｜gihyo.jp … 技術評論社

Jenkinsによる継続的インテグレーションのススメ(3) ~Jenkinsで分散ビルド~

【3】ビルドブレークとソフトウェアあんどん、XFD

ビルドブレークとは、不衛生なソースがコミットされてビルドが壊れる事象。
ビルドブレークが起きるということは、出荷可能な最終成果物が作れなくなったと言う意味であり、早急に直さなくてはならない。
でも、いつもすぐに分かればよいが、すぐに検知できない時もある。

トヨタ生産方式のように、自動車の製造ラインが止まった時に使われるパトランプ(あんどん)を光らせて、すぐに検知できるような仕組みが良い。
ソフトウェア開発に適用した場合、ソフトウェアあんどんやXFDの例がある。
実際にXFDを使うと、結構目立ってしまい、他の開発者の作業を中断させてしまうので、全員で直すだけでなく、再現しないように気を付けるようになるようだ。

第4回　プラグインを使う：Hudsonを使ったアジャイルな開発入門｜gihyo.jp … 技術評論社

あるいは、ビルドエラーを検知したら、メールで全員に配信するだけでなく、JenkinsからRedmineへ検知メールを発行して、チケット自動登録する仕組みを作っても良いだろう。

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

【4】ビルド手順

ビルドには、複数の構成があり、構成ごとにビルド手順が違う。
例えば、JavaのWebシステムであっても、JDKのバージョンやRDBのバージョン、アプリケーションWebサーバのバージョンという構成内容によって、ビルド方法は微妙に変わる。
だから、複数のバージョンの組合せによるビルドモジュールを作り、それらの回帰テストが必要になってくる。
Windowsアプリならば、OSのバージョンやVisualStudioのバージョンによって、複数の組み合わせによるビルドが発生するため、ビルドや回帰テストがより一層大変になるはずだ。

Jenkinsでは、マルチ構成プロジェクトという機能を使えば、JDKやOSのバージョンの組み合わせの設定を作れば、同じビルド手順でビルドしてテストできる。
この方法を使えば、特定のOSやJDKのバージョンに依存するバグを見つけ出すこともできる。

第5回　高度なプロジェクトタイプ：Hudsonを使ったアジャイルな開発入門｜gihyo.jp … 技術評論社

【5】継続的インテグレーション(CI)の種類

継続的インテグレーションの意義とその効果については以前書いた。

継続的インテグレーションを再考: プログラマの思索

継続的インテグレーションにも幾つかの種類がある。

(1)コミットビルド、軽量ビルド
　継続的にビルドする。
　普通はコミットするたびにビルドする。

(2)2次ビルド、重量ビルド
　時間がかかるビルド。
　フルビルドないしインクリメンタルビルド。

(3)段階的ビルド
　コミットビルドが通過したら2次ビルドを実行する。

2012/07/29 Jenkins ユーザ・カンファレンス 2012 東京 satta-4 : 複雑な多段階ビルドに対処する: 事例紹介 #juc2012 #juc2012_satta - Togetter

CIでは、ビルドの頻度があまりにも多いので、ビルド時間を短縮するために、並行ビルドや分散ビルドの仕掛けが必須だろう。
Jenkinsの分散ビルドの機能を使いこなすのは、CIの運用で必須になってくるだろう。

また、並行ビルドや分散ビルドの仕組みは、ビルド処理がバッチのジョブ処理に似ている性質を意味している。
つまり、複数のビルド処理を時系列につなげることで、ジョブフロー図として扱うことができる。

Jenkinsをジョブ管理ツールとして使うアイデア: プログラマの思索

Jenkinsをバッチ監視ツールとして運用する事例: プログラマの思索

Jenkinsの場合、Build Pipeline Pluginを使うと良いだろう。

Build Pipeline Plugin - Jenkins - Jenkins Wiki

kakakikikekeのブログ: 【Jenkins】Build Pipeline Pluginを使ってみた

Jenkinsでビルド・パイプラインを構築する - プログラマになりたい

この発想は、ビルドの時刻表を列車の時刻表に見立てて、ビルドを定期的かつ定刻にリリースする運用につながる。
これを「実践 反復型ソフトウェア開発」では、リリーストレインという概念で説明している。
つまり、ジョブフロー図の運用と同じだ。

【6】バディビルドの自動化

CIでビルドエラーのフィードバックが早く検知できるのは良いことだが、本来は、コミット前に教えてほしいものだ。
そのために、コミット前にサンドボックス上で事前にビルドするバディビルドが必要になる。
丁度、バディビルドがコミットビルドに相当するだろう。

最近はGitのような優れたバージョン管理が普及したので、サブブランチ上で事前にバディビルドするのがトレンドだろう。
つまり、ホットフィックスブランチやフィーチャブランチ、トピックブランチ上で修正してビルドが通過するまで開発者が責任を持つように開発プロセスを回す。

実際のビルド処理の流れとしては、ビルドマシンが下記を自動実行するイメージ。
下記のフローの利点は、マージ作業そのものも全てが自動化されるので、大変楽になること。

開発者がサブブランチへコミット
→ビルドマシンがコミットを検知して、バディビルドと自動テストを実施
→ビルドもテストもOKなら、ビルドマシンがサブブランチから親ブランチへポートしてコミットする

JiraとBamboo、Bitbucketを持つAttlasian製品では、ブランチ上に開発者がコミットしたら、後はビルドマシンが自動実行してくれるようだ。

GreenHopper を使用した Bamboo と Bitbucket の自動化

Atlassian製品による「No Ticket, No fork!」: プログラマの思索

Jenkinsで上記の処理を実現したい場合、コミットフック処理のスクリプト内で、サブブランチのバディビルドと自動テストを実施し、結果OKなら親ブランチへポートする処理を書けばよいだろう。

この発想は、チケット単位にトピックブランチを作って作業し、最終コミット時にtrunkへマージしてチケットをCloseする運用につながる。
つまり、チケット駆動開発ならば「No Ticket, No Fork」の運用ルールに相当するだろう。

チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法: プログラマの思索

GitHubならば、全てが自動化されているわけではないが、PullRequestという処理が上記の処理に似ている。

PullRequestは分散バージョン管理の利点を生かしたパッチ取り込み: プログラマの思索

【7】ビルドの品質

ビルドモジュールを区別するために、MD5チェックサムを計算する運用もある。
Jenkinsならば、ファイル指紋の機能に相当するだろう。

第3回　Hudsonによるチーム間の連携：Hudsonを使ったアジャイルな開発入門～ファイル指紋｜gihyo.jp … 技術評論社

Fingerprint - 日本語 - Jenkins Wiki

ファイル指紋を使う状況は例えば、ビルドモジュールを手作業で本番環境にデプロイする場合、持参したモジュールが本当に正しいモジュールなのかチェックする時に使える。

CIビルドは頻繁に実施するので、どのビルドがテストに耐えうるのか、分かりづらい。
そこで、CIビルドの中でより多くのテストにパスしたビルドを昇進させて色付けするやり方が、ビルドのプロモーション。
つまり、テストチームが受入テストを実施できる品質のビルドにラベルを付ける。
Jenkinsならば、Promoted Builds Pluginを使って、上流ビルド・下流ビルドを作る運用があるだろう。

第4回　プラグインを使う：Hudsonを使ったアジャイルな開発入門～ビルドプロモーション｜gihyo.jp … 技術評論社

Promoted Builds Plugin - Jenkins - Jenkins Wiki

Promoted Builds Plugin - おこらない日記