継続的インテグレーション（CI)とは毎日ビルドすることではない
ソース管理を利用する場合どのようにブランチを作成していくか決めなくてはいけません。ブランチの切り方として大きくリリース都合単位に切る方法と開発機能都合単位に切る方法があるようで、それぞれのブランチをリリースブランチと機能ブランチなどと呼ばれたりします。使い方は前者のリリースブランチはバグフィックス用で、後者の機能ブランチは追加開発用とすることが多いようです。したがって、もとのブランチ（これをメインブランチと呼ぶ）とあわせて３種類のブランチをどのように組み合わせて利用していくかを考えなくてはなりません。
機能（フィーチャー）ブランチ
この３つのブランチの中で機能ブランチの使い方がどうもしっくりしてきませんでした。機能ブランチを利用する目的のひとつにリリース時にどの機能を組み込むかを選択*1できる点があがります。しかし、ブランチを増やせば開発者にとってはマージなどの手間が増え整合性の確保も難しくなります。これをどのように両立すれば良いか悩んできました。
そんな中、尊敬するＭａｒｔｉｎ Ｆｏｌｗｅｒ氏のフィーチャーブランチという記事を見つけました*2。さすがＦｏｌｗｅｒです。私の疑問に対して大きな指針を与えてくれてくれました。機能ブランチを利用する場合のマージは大変であり、これを避けるために機能の有効無効をソフトウエアで切り替える仕組みを導入するアイデアです。当たり前のようなアイデアですが、作成途中のコードを含めてリリース行為は何か事故が起こりそうで嫌な面があります。しかし、あらかじめ枠組みを作成して想定の作業・仕組みにしていれば勇気をもってできそうです。
継続的インテグレーション（CI)
また、先ほどの記事には以下のように機能ブランチを毎日ビルドすることが継続的インテグレーション（CI)と同じでないとも書かれています。
重要なので明記しておくと、大体の場合、この様なフィーチャーブランチはCIとは異なるアプローチである。CIの原則の1つは誰もが毎日メインラインにコミットすることである。なので、フィーチャーブランチが1日以上続かないという場合を除いたら、フィーチャーブランチの施行はCIとは全く異なるものになる。私はかつて、全てのブランチの毎回のコミットに対して(おそらくCIサーバを使用して)ビルドを実行しているので、これはCIをしているんだと言うのを聞いたことがある。それは継続的ビルドであり、望ましいことではあるが、インテグレーションが全くないので、それはCIではない。
改めて継続的インテグレーション（ＣＩ）に対する気付きを与えてくれる内容で、ビルドできているからＯＫではなく、すべてを統合することを目指す必要があるということを感じました。この考えはラスト１マイル問題（最後の最後で重要な問題が発生する）とも戦う上で大きな武器になるとも感じました。
