PR

 難関1で示したCIの流れは、あくまでツールの処理である。CIではさらに、開発者が行うプログラミングなどを含めたプロセスやルールが必要になる。これが、二つ目の難関である。

 もともとCIは、アジャイル型の方法論の一つである「XP(eXtreme Programming)」で提唱されたプラクティスである。このため短い期間で開発・テスト・実装を繰り返すアジャイル型の開発プロセスと相性がよい。というより、アジャイルではCIの導入はほぼ必須だ。とはいえ、ウォーターフォール型の開発プロセスには適用できないかといえば、そんなことはない。ウォーターフォール型でも導入は可能で、同様のメリットを得られる。

 基本的に、アジャイル型とウォーターフォール型でCIのプロセスやルールに違いはない。ただしデリバリーまで含めたCD(Continuous Delivery:継続的デリバリー)と呼ぶ手法を実践する場合はアジャイル型の採用が基本となる(60ページの別掲記事を参照)。

 図1にCIのプロセスを挙げた。CIにチケット発行のプロセス(チケット駆動開発)を組み合わせた例である。インテックの内野 了氏(ネットワーク&アウトソーシング事業本部 ネットワークソリューション部 IDマネジメント課)はCIマスターとして、この一連のプロセスを現場で推進している1人だ。

図1●CIとチケット発行を組み合わせた開発のプロセス
図1●CIとチケット発行を組み合わせた開発のプロセス
CIにチケット(タスク)発行のプロセスを組み合わせると、バグ修正の抜け・漏れを防ぎやすい。インテックの内野 了氏は「CIマスター」として、こうした一連のプロセスが回ることを現場で推進している
[画像のクリックで拡大表示]

 開発者はまず、ソースコードの修正作業を「チケット」として発行。これをRedmineやTracなどのチケット管理ツールに登録する。次に、チケットに基づいて該当のソースコードをソースコード管理ツールからチェックアウトする。ソースコードを修正してテストを実施したら、ソースコード管理ツールにチェックインし、修正が終わったことをチケット管理ツールに登録する。チケット発行のプロセスを組み合わせることで、「バグ修正の抜け・漏れを防ぎやすい」(内野氏)という。

チェックインのルール作りが必要