継続的デリバリー読書会２ 参加してきた #CDStudy
2012年5月20日に行われた、 継続的デリバリー読書会２に参加してきました。
以前行われた 第１回と同じように、みんなで輪読して、章毎にテーブル単位で話し合う形で行われました。今回の範囲は、 第３章 継続的インテグレーション、 第４章 テスト戦略を実装するでした。
第３章 継続的インテグレーション
この章は 継続的インテグレーションについて学ぶ章でした。継続的インテグレーション*1は、継続的デリバリーの中核をなす部分といっても過言ではないでしょう。 Jenkinsに代表される強力なオープンソースのツールがありますし、それらを使って最終的に客先に届けるまでのプロセスで何度も繰り返すプロセスといえます。大まかな内容は以下のようになります。
- 導入
- 継続的インテグレーションを実現する
- 継続的インテグレーションの前提情景
- 継続的インテグレーションソフトウェアを使用する
- 基本的なプラクティス
- やったほうがいいプラクティス
- 分散したチーム
- 分散バージョン管理システム
- まとめ
私が参考になった点を以下に列挙します。
- 開発者は自らのビルドに責任を持て！ これは、単純に考えると「継続的デリバリー」、「継続的インテグレーション」どちらにも関係なく必要な事のように思えます。この書籍の中では、まず 「コードのコミットからキックされる、テスト、ビルドを数分で終わるようにする！」とはっきり明言されています。そうでないと、ビルドにかかる時間をぼーと待つ事になる上に、 「他のメンバーがビルドを行っていたら、そのビルドが正常に終了するまで待つ！」という原則から、他のメンバーの進捗に悪影響を与えます。そのうえで、 「自分のビルドが正常に終了するまで帰宅してはならない！」と言っています。ビルドで問題を残したままにすることは、その間他のメンバーの作業を止めてしまうからです。この書籍では、例としてオフショア開発のケースを上げて、アメリカでエラーを起こしたままにすると、インドで作業ができないというような例を説明してくれています。このお話から、書籍にも記述がありましたが、 「金曜日の夜にコミットするのはダメ！」「ノーコミットフライデー！」という名言めいた言葉がどこからともなく聞こえてきました。
- 常に以前のリビジョンに戻れるようにすること！ 前の項目を満たしていたとしても、ビルドが失敗することはあり得ることです。その際、対処に係る時間を計測し、対処にかかる時間が１０分以上であれば、以前のリビジョンに戻しましょう、とお話されています。この書籍の考え方では、以前のリビジョンは必ず正しく稼働していたはずです。ここでビルドに失敗した状態で時間をかけると、他のメンバーからのコミットを妨げるだけでなく、他のメンバーからの事故で問題がより深刻化するおそれもあるからです。素早いリバートを心がける必要があるようです。
- 分散バージョン管理システムをうまく使う！ 分散バージョン管理システムなら、コードのコミットを行う際に、自分のローカルに中央リポジトリのコードを取得して、競合の管理ができます。こんな所にも分散バージョン管理の利点が生きてくるわけですね。
第４章 テスト戦略を実装する
この章では、「継続デリバリー」において意識すべきテスト戦略について書かれていました。私自身「元製造業」の人間です。「品質こそ企業の命」と常に聞いて社会人をやっていましたから、どんな職種であっても品質との縁は切ることができないというのが持論です。この章は以下のような説明がされていました。- 導入
- テストの種類
- 実際に起こり得る上京と戦略
- プロセス
- まとめ
私が参考になった点を以下に列挙します。
- 受け入れテストを自動化する事！ 私の中では受け入れテストを自動化するのは
- すべてのテストを自動化できるわけではない！ 上記のように自動化できるところは自動化するべきですが、書籍の中にも、どの程度まで自動化するべきかは、検討するべきだとあります。やはり、人がやるテストは柔軟なんですね。
- 振る舞い駆動開発のパターンを利用する！ 振る舞い駆動開発パターンを利用すれば、
- 非機能要件に関するテストは事前準備する。 一般的に必要な非機能要件に関するテストは予測可能という観点から、事前に準備しておきべきという事が書かれていました。これはチームとしての経験値が物を言う内容ですね。とても大事な事だと思います。
一番難しいという印象がありました。特に想定されるのWebシステムであり、やはり無難に各入力フォームに対しテストコードを打つスクリプトを地味に作る発想しか私自身できていません。書籍にも記述がありましたが、フォームの名前等に依存するテストになってしまうのがよくあるケースだそうです。ただ、受け入れテストまで自動化されて、常に顧客要求を満たすことが確認できるビルドができるのであれば、これほど
心強い事はありませんね。
設計者が作る設計書＝テストコードとなり得る。これを使わない手はない。
まとめ
今回もとても勉強になりました。次回までにまた該当の章を読んでおいて、知識を深めたいと思っています。@kyon_mmさん、会場準備等ありがとうございました。Twitterのまとめ
*余談ですが、当記事はGroovyのMarkupBuilderを使ってHTMLを作成して書きました。いずれまた記事にします。
*1:以下、CIと表記する。
