難関1で示したCIの流れは、あくまでツールの処理である。CIではさらに、開発者が行うプログラミングなどを含めたプロセスやルールが必要になる。これが、二つ目の難関である。
もともとCIは、アジャイル型の方法論の一つである「XP（eXtreme Programming）」で提唱されたプラクティスである。このため短い期間で開発・テスト・実装を繰り返すアジャイル型の開発プロセスと相性がよい。というより、アジャイルではCIの導入はほぼ必須だ。とはいえ、ウォーターフォール型の開発プロセスには適用できないかといえば、そんなことはない。ウォーターフォール型でも導入は可能で、同様のメリットを得られる。
基本的に、アジャイル型とウォーターフォール型でCIのプロセスやルールに違いはない。ただしデリバリーまで含めたCD（Continuous Delivery：継続的デリバリー）と呼ぶ手法を実践する場合はアジャイル型の採用が基本となる（60ページの別掲記事を参照）。
図1にCIのプロセスを挙げた。CIにチケット発行のプロセス（チケット駆動開発）を組み合わせた例である。インテックの内野 了氏（ネットワーク＆アウトソーシング事業本部 ネットワークソリューション部 IDマネジメント課）はCIマスターとして、この一連のプロセスを現場で推進している1人だ。
開発者はまず、ソースコードの修正作業を「チケット」として発行。これをRedmineやTracなどのチケット管理ツールに登録する。次に、チケットに基づいて該当のソースコードをソースコード管理ツールからチェックアウトする。ソースコードを修正してテストを実施したら、ソースコード管理ツールにチェックインし、修正が終わったことをチケット管理ツールに登録する。チケット発行のプロセスを組み合わせることで、「バグ修正の抜け・漏れを防ぎやすい」（内野氏）という。
