eyecatch
Tue, Feb 9, 2016

継続的インテグレーションは死んだ

このエントリでは、Yegor Bugayenkoによる記事、Continuous Integration is Deadを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 (adsbygoogle = window.adsbygoogle || []).push({}); 数日前、「なぜ継続的インテグレーションは機能しないのか」という私の記事がDevOps.comに公開された。 それとほぼ同じ日に、Twitterで非常に否定的な批評が送られてきた。 継続的インテグレーションが機能しないとはどういうことだ。この人気なすばらしいアイデアが。 その求めてもない質問への返事をここに書く。 私はこの分野に関して多少の経験があるが、それに基いた論拠は挙げない。 代わりにロジックだけを頼りにする。 ところで、私には50以上のオープンソースや営利プロジェクトで5年間Apache Continuum、Hudson、CruiseControl、Jenkinsを利用した経験がある。 さらに、数年前fazend.com(2013年にrultor.comに改名)というホスト型継続的インテグレーションサービスを開発した。 現在TravisとAppVeyorのアクティブユーザでもある。 継続的インテグレーションはどう機能すべきか 考え方はシンプルで明確だ。 masterブランチ(Subversionなら/trunk)に新しくコミットをする度に、継続的インテグレーションサーバ(またはサービス)はプロダクト全体のビルドを試みる。 「ビルド」というのはコンパイル、ユニットテスト、統合テスト、品質解析などを意味する。 その結果は「成功」か「失敗」だ。 もし成功だったら「ビルドがクリーン」であると言う。 もし失敗だったら、「ビルドが壊れている」と言う。 通常、ビルドが壊れるのは、以前通っていたユニットテストを通らなくするような新しいコードをだれかがコミットしたからだ。 これは問題の技術的な面だ。 この部分はいつも上手くいく。 まあ、依存が直書きされてるとか、ビルド環境が十分分離されていないとか、ビルドの並列性が完全じゃないとか、そういう問題はあるかもしれないが、この記事はそれらについてではない。 アプリケーションが上手く書かれていてユニットテストが安定しているなら、継続的インテグレーションは簡単だ。 技術的には。 組織的な面を見てみよう。 継続的インテグレーションというのは、ビルドを実行するサーバだけを指すのではなく、上手く機能すべき管理的/組織的プロセスだ。 プロセスが上手く機能するとは、Jez Humbleが「継続的デリバリー: ビルド、テスト、デプロイの自動化による確実なソフトウェアリリース」の55ページで言っていることそのものを意味する。 もしビルドが失敗したら、開発チームは何をやっていたとしてもそれを中断して、そのビルドの問題を速やかに直す。これが重要だ。 これが上手くいかず、上手くできないことだ。 誰がこれを必要としているのか 既に述べた通り、継続的インテグレーションとは、開発チーム全体を止めて壊れたビルドを修正させることだ。 繰り返すが、ビルドが壊れたら直ちに、それを修正し、ビルドを安定した状態に戻すコミットを入れることに全員が集中すべきだ。 ここでひとつ疑問が生じる。誰が、活動中のチーム内の誰がこれを必要としているのだろうか? 一刻も早く新しい機能をリリースしたいプロダクトオーナ? または、締め切りに責任を持つプロジェクトマネージャかもしれない。 もしくは、他の誰かが作りこんだバグをプレッシャーを受けながら修正すること嫌うプログラマかもしれない。 誰がこの継続的インテグレーションを好み、誰が必要としているのか? 誰でもない。 実際に何が起こるのか 教えよう。 私は何度も見たことがある。 シナリオはいつも同じだ。 継続的インテグレーションのビルドステータスは単に無視されるようになる。 ビルドがクリーンか壊れているかにかかわらず。 そして以前のやり方が継続される。 Jez Humbleが推奨するように開発を止めて問題に対応したりしない。 代わりに、継続的インテグレーションサーバから来る情報を無視する。 しばらくして、次の日かもしれないし月曜日かもしれないが、空いた時間を探してビルドの修正に取り組む。 これは単に、ダッシュボードの赤いボタンが嫌で緑に変えたいからだ。 規律についてはどうか そう、これには別の見方もある。 チームに規律を徹底させることもできる。 ビルドは常にクリーンで、壊した人は何らかの罰を受けるという厳格なルールを設けることができる。 これを試すとなると、恐怖駆動型開発を実施することになる。 プログラマは、ビルドを失敗させたら少なくとも謝罪しなければならなくなるため、リポジトリへのコミットを恐れるようになる。 この場合の厳格な規律(私は大好きだが)は、単に状況を悪化させる。 開発プロセス全体が遅くなり、プログラマはビルドを壊さないように自身のコードをできるだけ長い間手元に保持する。 いざコミットするとなった時、変更は巨大になっていて、マージは非常に難しいか、時に不可能になる。 結果、プログラマが書いた多くのコードがコミットされること無く捨てられる。 あの恐怖因子のせいだ。 OK。解決策は?