マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発（後編）。Agile Conference tokyo 2011
アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。
前編に続いて、ファウラー氏の基調講演の様子を紹介しましょう。
（本記事は「マーチン・ファウラー氏が語る、、21世紀のソフトウェアデザインとしてのアジャイル開発（前編）。Agile Conference tokyo 2011」の続きです）
継続的インテグレーション
アジャイル開発の中で重要な「継続的インテグレーション」と「継続的デリバリ」について話そう。まずは継続的インテグレーション。
複数のプログラマが集まって開発しているソフトウェアでは、それぞれのプログラマのコードをマージする作業に苦労する現場を多く見てきた。
あるソフトウェアプロダクトに二人のプログラマがいたとすると、コードを2つに分岐し、その分岐をそれぞれのプログラマが開発を進めていく。しかしコードをマージしようとするときには大変な作業になる。同じ個所を変更していてバッティングする可能性もある。
マージのためのツールを使えば作業は容易にはなるが、コードの見かけはマージできても、意味として本当に問題なくマージされているかどうかはテストして確認するしかない。
しかし、「マージは難しい」とあまり信じ込むのもよくない
マージは分岐から時間がたつほどに難しくなる、であれば、難しくなる前に、頻繁にマージをすればいい。これを「Continuous Integration」（継続的インテグレーション）と呼んでいる。
継続的インテグレーションでは、どんな小さな変更もメインラインに反映するため、小さい規模のマージがひんぱんに発生する。すると、最後に賭けのように、さあどうだ、という大規模なマージをする必要がなくなる。そこに継続的インテグレーションの意味がある。
継続的インテグレーションのもうひとつのアドバンテージは、例えば二人のプログラマがそれぞれ開発しているコードのどこかに非互換性があったとする、そこに両者がいつ気がつくか？ 継続的インテグレーションによって両者がひんぱんにマージをし、コミュニケーションをしていれば早期に発見できるだろう。そうでなければ、最後の方になって発見することになるかもしれない。
もう1つメリットがある。コードのリファクタリングをしようというとき、何かを変更するとマージのとき大変だからと慎重になってしまえば、コードの品質を高める機会が減る。何か問題があればすぐにそれを検知できる、という継続的インテグレーションの環境は、品質面でのメリットもある。
継続的デリバリ
継続的インテグレーションだけでなく、継続的デリバリの話もしよう。
継続的インテグレーションは、開発の途中での問題の早期発見、早期治療の手段といえる。しかしなら、そのコードが実際の運用環境で動作するとは限らない。開発環境と運用環境は違うことがあるからだ。
コードが運用環境に対応しているか（プロダクションレディか）を確認するにはテストが必要だ。テストを行えば、コードに問題がないという自信や安心が得られる。しかしテストには時間がかかるため、テストをするほど完成とデリバリが遅れる。そこにはバランスをとる必要がある。
そこで、シーケンスを作り、コンパイルとユニットテストからプロダクションまでをいくつかに分割して、デプロイメントパイプライン（Deployment Pipeline）を作るのはどうだろう。
そして、パイプラインのテストは可能な限り自動化すべきだ。いつでもテストができるように完璧に自動テスト化する事をおすすめする。
| Tweet |
|
|  Follow Me
|  RSS
|
次の記事
日本のアジャイルムーブメントに、何が起きていたのか、何が起きているのか
前の記事
マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発（前編）。Agile Conference tokyo 2011
Junichi Niino（jniino）
