保守とTrunkと継続的インテグレーション

システムの保守の現場では、保守案件(機能追加や障害対応)ごとにBranchを作成するいわゆるFeature Branchを活用した運用をよく見かけます。

しかし、継続的インテグレーションのことを考えると、この運用は好ましくありません。

継続的インテグレーションとは、複数の開発者が作成・変更したソースコードを頻繁に統合してビルドすることです。これにより、統合時の問題(主に、開発者間のコミュニケーション不足による手戻り)を早期に発見できたり、大規模なマージ作業を避けることができます。

さきほどの図の場合だと、AのブランチとBのブランチのソースコードは、それぞれが完成するまで統合されないので継続的インテグレーションが出来ません。

では、どうすればいいかというと、保守案件が複数あっても、Branchを作成せずに、原則としてTrunkだけで開発すればよいのです。

そして、Trunkのソースを頻繁にビルドすれば、継続的インテグレーションが実現できます。

このとき問題となるのが、Aの案件をリリースするときに、開発中のBの案件のソースコードが混じってしまうことです。そうなると、開発中の画面がユーザに表示されてしまったり、バグのある処理が実行される危険性があります。

この危険性を防ぐため、開発中のソースコードの機能が実行されないような工夫が必要となります。工夫の仕方はいろいろあると思いますが、良いと思うのは、開発中のソースコードの機能を設定ファイルでON/OFFすることです。設定ファイルのON/OFFで、画面のメニューの表示/非表示を切り替えたり、プログラム内にフラグを持たせてロジックを切り替えたりします(この辺りの話は、こちらのサイトが参考になります)。こうすれば、リリース時は開発中のソースコードの機能を隠すことができるし、テスト時には設定ファイルを書き換えるだけで開発中のソースコードの機能をテストできます。

さいごに

どんな保守案件もtrunkを使って開発すべきとは言いませんが、trunkで開発できる保守案件(機能のON/OFFが容易にできる案件)は多いと思います。継続的インテグレーションのメリットを考えれば、原則としてtrunkを使って開発し、継続的インテグレーションを導入するのが良いと思います。