継続的インテグレーションを再考

「継続的インテグレーション入門」を読んでみて、もっと早く読んでおけば良かったと後悔した。
内容がとても素晴らしかったので、理解できたことをラフなメモ書き。

【元ネタ】
Togetter - 「SIerは自動化する対象が違っているのでは？」

Continuous Deliveryをポチッた - watawata日記

Continuous Delivery - haru01のめも

アジャイルなインフラのつくり方とデータマネジメント - メソッド屋の日記

インフラやデータ移行の自動化～アジャイル開発の最後の問題: プログラマの思索

Continuous Delivery～TDDとCIの次に現れた自動化の概念: プログラマの思索

【1】「はじめに」に、キーボードに「Integrate」というボタンが貼られていて「こんなに簡単ならいいのに」という雑誌の広告から始まる。
この挿話は、ビルド＆デプロイの作業はワンクリックで自動化すべきだ、という主張につながっている。

2011年にもなったソフトウェア業界でも未だに、Excelのリリース管理台帳を見ながらソースを1個ずつ取り出してはビルドするという手作業が残っている。

例えば、HudsonやJenkinsのような優れたビルド管理ツールがあるのに、Eclipseで手動でwarファイルを作っているチームすらもある。
特に、バージョン管理ツールがCVSやVSSのような古いツールを使っているチームは、構成管理やビルド管理に大きな問題点を孕んでいる時が多い。
そのアンチパターンは下記に書いた。

構成管理のアンチパターン～TiDD初心者が陥りやすい罠 #tidd: プログラマの思索

【2】「ソフトウェア資産を集中化する」節では、リポジトリパターンを説明している。
リポジトリパターンとは「パターンによるソフトウェア構成管理」で提唱された概念で、バージョン管理リポジトリをソフトウェア開発の作業に関する全てのファイルの置き場所にしてしまうこと。

ソフトウェア資産という概念は、ITILの構成管理プロセスにおけるCI(構成アイテム)につながるだろう。
例えば、ソースだけでなく設計書やビルドスクリプト、jar・DLLのようなコンポーネント、DDLや初期データなどがソフトウェア資産に相当する。

これらのファイルを全て構成管理の配下に置くことで、修正履歴が全て残り、環境依存のリスクが減る。
「魔法のマシン」というコラムがあるけれど、ビルド可能なマシンが古いPC1台しかないという悲劇は結構存在していないだろうか？

【3】継続的インテグレーション入門で面白いのは、自動化の対象がビルド作業だけでなくインスペクションやデプロイ、フィードバックにも広げていること。
「コードの複雑度を下げる」節では、サイクロマチック複雑度(CCN)とテストケース数に相関関係があるという指摘がある。
複雑度と単体テストケース数はほぼ同じという経験的事実は、下記で既に書いた。

複雑度と単体テストケース数の相関関係: プログラマの思索

「コード網羅率を評価する」節では、命令網羅率(C0)や分岐網羅率(C1)をレポート出力する件について書かれている。
上記の記事でも書いたが、複雑度と分岐網羅は密接な関係がある。

JUnitでテスト駆動開発を実践しているなら、命令網羅率の100％通過はもちろん、分岐網羅率の100％通過も課すべきだろう。
そうでなければ、IF文の分岐を全てテストした事にならず、未テストのロジックから必ずバグが出る。

実際にJUnitを書いてみれば分かるが、命令網羅率を100％にすることすら難しい。
特にExceptionのような例外処理に複雑な処理を入れていると、そう簡単にはテストしづらい。
また、1メソッドの行数が100行、1000行も書かれていれば、殆ど不可能に近い。

複雑度が30以上のプログラムは、リファクタリングするよりも書き直した方が修正コストも少ないし、バグが少なくなるという矛盾がある。
だから、継続的インテグレーション入門でも推奨しているように、複雑度を下げる最も効果的な方法は「メソッドの抽出」で複雑さを扱い易いメソッドへ分散させるリファクタリング作業があるだろう。

Eclipseリファクタリング・メモ: プログラマの思索

CobolやVBのコーディングルールに固執しているチームほど、メソッドの行数は長くなりがちで複雑度は大きくなりがち。
古い言語に固執していると、最新のベストプラクティスを反映しづらいので、開発の生産性も上がらない事実を示しているように思う。

【4】「継続的なデザインレビューの実施」の節では、求心性結合度、遠心性結合度、不安定性というメトリクスを使って、ライブラリの安定性を測定しようとしている。
これらの概念は、「プログラマのためのJava設計ベストプラクティス」や「アジャイルソフトウェア開発の奥義」で既に説明されている。

HudsonやJenkinsだけでなく、Sonarのようなメトリクス収集ツールを使えば、自動化できるだけでなく、いつでも誰にでも公開できるので、運用するとよいだろうと思う。
開発者は、StatSVNやSonarのようなツールで自分が書いたソースがどのように測定評価されているのか、結構気にしているし、もっと綺麗に書くというモチベーションアップにつながる。

メトリクスでソフトウェア品質を見える化する: プログラマの思索

Sonarでソースの品質をチェックする: プログラマの思索

品質管理ツールSonarの記事: プログラマの思索

【5】「継続的フィードバック」の章では、アンビエントオーブやX10機器のように、ビルドエラーの検知を通報する機器を紹介している。
このアイデアは、プロジェクトファシリテーションならば、ソフトウェアあんどんに相当する。

「見える化」でソフトウェア開発！ ～オブジェクト指向実践者の集い(第 3 弾) 参加レポート～

ソフトウェアあんどんの意義は、開発チームに即座にビルドエラーの検知を通報することによって、製品化の遅れを即座に修正する点にある。
コードラインが常時リリース可能という意味は、いつでも顧客に最新機能のシステムを納品するというアジャイル開発の根本目的につながる。

駄目なチームは、ビルドエラーを放置したまま開発してしまうために、新たなバグが発覚したときに、そのバグの原因が以前のビルドエラーにあるのか、それとも新しい機能追加にあるのか、を判別しづらくなる。
バグ修正では、10回のうち2～3回は別のバグを埋め込んでしまうという経験則もあるので、下手に手を入れるほど、システムの品質はどんどん劣化していく。

ソフトウェアあんどんのアイデアは、ビルド管理システムのエラー監視の自動化というアイデアにつながる。
@haru_iidaさんはHudsonがビルドエラーを検知したら、即座にメールを発行してRedmineにチケット登録するという手法を公開されていた。

RedmineとHudsonやTestLinkを連携させるプラグイン: プログラマの思索

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

このアイデアは、業務システムやWebサーバーのエラー監視ツールが障害を検知したら、即座にメールを発行すると同時にRedmineへチケット登録して、ITILの運用保守のプロセスで管理していく発想につながる。
問合せや障害検知を含むインシデント管理におけるチケット登録の自動化は、もっと機能強化されるべきものだと思う。

【6】「継続的デプロイ」の節では、常時リリース可能にするために、リポジトリの資産にラベルづけするプラクティスを紹介している。
これはリリースタグを振ってリリースブランチを作る運用そのものだ。

リポジトリの資産にラベルづけすることは、規律を持ったソフトウェア開発で最も重要な作業だ。
その理由は2つある。
一つは、ラベル付けは単なるスナップショットではなく、ベースラインを設定することによって、顧客へ納品する基準にもなり、最悪のケースはロールバックする基準にもなりうる。
もう一つは、ラベル付け後、リリースブランチを派生させることによって、複数のブランチを併存させる並行開発が可能になること。

前者から、ラベルがリリースタグであり、ベースラインであることから、厳格な変更管理が可能になる。
後者から、複数のブランチを併存することによって、複数の製品ラインを常時保守する並行開発をサポートする。
これは、組込製品やパッケージ製品のように、似たような仕様だが細部は異なる製品群の開発、つまりソフトウェアプロダクトラインの開発をサポートする方向になるだろう。

そして、継続的デプロイのアイデアは、Continuous Deliveryのように、受入テストや本番環境構築、データ移行、リリース作業の自動化の方向へ進化している。

牛尾さんの記事「アジャイルなインフラのつくり方とデータマネジメント - メソッド屋の日記」では、Rubyのツールveewee やVagrantが紹介されている。
また、@agilekawabataさんはUltimate Agile Stories Iteration1にて、CucumberというRubyの受入テスト補完ツールを紹介されている。

これらContinuous Deliveryのアイデアを実現しようと試されているツールの殆どがRubyで作られている事実にも注目したい。
今の開発トレンドを見ると、技術革新が活発に行われているプログラミング言語は、JavaからRubyへ完全に移っているように思える。

継続的インテグレーションやContinuous Deliveryのアイデアは、もちろんチケット駆動開発にも適用できるし、相性も良い。
チケット駆動開発から発展したアイデアにはCIツールが含まれているし、CIツールとSCMやITSが密接に関連することで、ソフトウェアの開発インフラはもっと進化する余地があるように思う。