Mad AnglerはAJAXな管理コンソールをもつCIツールです。
概要
次のような特徴があります。
ビルドツールに依存しません
ビルドは疑似端末をもったssh経由のリモートコマンドで実行します。ビルドの成功、失敗の判定はビルドログの最終行がOK
かどうかで決まります。したがって、ビルドに限らずリモートコマンドの内容次第で様々なことがテスト可能です。
バージョン管理システムに依存しません
リモートコマンドがリポジトリからソースコードをチェックアウトすることを想定しているため、バージョン管理システムに依存しません。バージョン管理システムに、コミットをフックしてスクリプトを実行できる機能と、リビジョンを指定してチェックアウトできる機能があれば、コミットをトリガとしてビルドを自動で確認することができるようになります。
ビルドの指示はREST形式のウェブAPIです
バージョン管理システムと連係させて使用する場合は、コミットをフックするスクリプトで「コミットされたリビジョン」をパラメータに含むURLをアクセスするように設定します。すると、コミットに連動してビルドが走り、そのログを保存するようになります。
1つのリビジョンを複数のプラットフォームでビルドして確認できます
ビルド結果はプラットフォーム毎に分けて記録されます。
管理コンソールはGWTで書かれたウェブアプリケーションです
ウェブブラウザでビルドのステータスやログを確認できます。また、プロジェクトの作成や設定もウェブブラウザから行えます。
ワークフロー
想定しているワークフローは次のような図になります。
開発チームのメンバーがリポジトリに変更をコミットすると、リポジトリはCGIリクエストを使用して、コミットされたリビジョンをMad Anglerに通知します。Mad Anglerはコミットされたリビジョンをデータベースに記録してCGIのセッションを終了し、バックグラウンドでSSHプロトコルを使用して、ビルド用ホストでビルドスクリプトをリモート実行します。リモート実行には疑似端末が割り当てられ、Mad Anglerはすべての出力をログに記録します。
ビルド用ホストでは、ビルドスクリプトが指定のリビジョンのソースコードをリポジトリからチェックアウトし、ソースコードをビルドします。ビルドが終了するとリモート実行は終了します。Mad Anglerはログの内容からビルド結果を決定し、データベースに記録します。同時に、開発チームのメーリングリストにビルド結果のレポートをメールで通知します。
加えて、メンバーはいつでもウェブブラウザで、Mad Anglerに記録されたプロジェクトのビルド状況を確認したり、Mad Anglerのプロジェクト設定を変更することができます。
ビルドするリビジョンの決定アルゴリズム
Mad Anglerは1つのプロジェクトにつき、同時にビルドするリビジョンを1つに制限しています。通常、Mad Anglerは時系列順にリビジョンをビルドしていきますが、Mad Anglerがビルド中にさらなるコミットが複数発生した場合は、できるだけ最新のリビジョンからビルドしようとします。
「次にビルドするリビジョン」を決定するアルゴリズム★1は、次のようになります。
ビルドが終了したリビジョンが最新ではない場合
リビジョンAのビルドが終了した時点で、最新のリビジョンがAでなかった場合は、次に最新のリビジョンをビルドします。リビジョンAをビルドしている間に、新しくリビジョンがコミットされると、この状況になります。
最新のリビジョンとリビジョンAの間のリビジョンはひとまずスキップされます。スキップされたリビジョンのビルド結果は不明になります。
ビルドが終了したリビジョンが最新だった場合
リビジョンAのビルドが終了した時点で、最新のリビジョンがAであった場合、「ビルド結果が成功である最新のリビジョン」を探索します。リビジョンAから順にリビジョンをさかのぼります。注目しているリビジョンのビルド結果に従い、次のように処理を分岐します。
結果 | 処理 |
---|---|
成功 | 探索を終了します。 |
失敗 | 注目しているリビジョンを次(1つ前)に進めます。 |
不明 | 注目しているリビジョンをビルドします。 |
★1 バージョン管理システムが分散型の場合はブランチを考慮する必要があるため、このアルゴリズムでは問題があります。次にビルドするべきリビジョンをうまく決定するには、プロジェクトで使用されているバージョン管理システムのことをMad Anglerがもっと知っている必要があります。とりあえず将来のリリースでは、時系列順にすべてのリビジョンをビルドするアルゴリズムも選択できるようなる予定です。