2008年

2008年となり、早くも2週間が経ってしまいましたが、今年最初の投稿です(汗)


今年は、開発マネジメントではなく、SEPGとして社内のプロセス改善していくのが主な仕事です。
開発は、S2などのオープンソースで、個人的な活動が中心になっていくことになります。


なので、投稿もプロセス関連の話題が多くなるかな。

構成管理ベストプラクティス

以前は高価なツールがないと構成管理*1ができませんでしたが、ここ数年で、オープンソースのバージョン管理ツール(CVSSubversion等)と変更管理ツール(Bugzilla/Trac/Scarab等)の普及により、開発現場でも大分利用されるようになってきています。


しかしながら、管理ルールが不明確なままだったり、単なるファイルサーバに近い状態で利用されていたり、有効に活用できていないケースも多いように思われます。


そこで、私の経験を基に、構成管理のベストプラクティスをまとめてみます。

  • そのプラクティスは適切ではない
  • もっとこうした方が良い

というのがあれば、ぜひ、意見を頂けるとうれしいです。

*1:ここでは、バージョン管理と変更管理を含めて構成管理と呼んでいます

構成管理ベストプラクティス 〜バージョン管理計画〜

計画、といっても、それほど大げさに考える必要はありません。
利用するために必要な、準備とルール決め程度です。また、一度決めてしまえば、類似のプロジェクトを行う場合にも、ほぼ同じものが適用できるようになります。

  1. 最初からツールを利用する
    • 構成管理を行う場合、何かしらのツールを導入することになると思いますが、最初から利用できるように準備しておくことが活用の第一歩です。開発途中からツールを導入しようと思っても、それまでの作業のやり方に流されてしまい、有効活用されないため、開発当初から利用を徹底しましょう。
  2. 構成管理責任者を決めておく
    • 構成管理の成功のためには秩序が必要です。皆、好きなように使っていては、成果物の構成を保つことができません。構成管理ルールの決定、およびそれらが実行されているかのチェックを行う責任者を決めておきましょう。
  3. ディレクトリ構成はあらかじめ用意しておく
    • 成果物をどのように登録するのか、ディレクトリは予め用意しておきます。
    • ドキュメント、ソースコード、設定ファイル、試験データ等、必要なデータを登録するディレクトリを作成します。
  4. マージ修正モデルかロックモデルかを決めておく
    • ツールによってポリシーが異なりますが、変更のモデルを決定します。
    • 他の作業者にブロックされずに編集可能な「マージ修正モデル」か、同時に編集させない「ロックモデル」かを利用します。前者は、オープンソースのツールが主に採用しており、後者は有償の製品が主に採用しています。どちらが優れている、ということではなく、開発スタイルに合わせて考える必要があります。
    • 厳密な管理を行う必要がある場合は「ロックモデル」が適していますが、ソースコードは「マージ修正モデル」、ドキュメントは「ロックモデル」のように組み合わせで利用しても良いでしょう。
  5. コメントのルールを決めておく
    • コメントには、主に以下の内容を含めるようにします。機能名は、変更履歴だけを見ても、何が修正されているのかが、すぐに分かるようにするためです。
      • 修正内容/修正が発生した理由/機能名/変更管理のチケットID
    • ツールによっては、チケットIDを書いておくと変更管理ツールと自動連携するものもあるので(SubversionTracなど)、事前にツールの機能を確認しておくと良いでしょう。
  6. メインラインを1つに保つ
    • バージョン管理ツールは、ブランチの機能を備えているものがほとんどですが、ブランチはできるだけ作成しないようこころがけましょう。ブランチは、構成管理が複雑化する原因となります。
  7. コードラインポリシーを決めておく
    • コードラインとは、ある基準に対するソースファイルの集合のことです。「開発用」「リリース用」「障害対応用」など、目的に応じて作成しますが、それに適したポリシーを決定しておきます。
    • 特に、コミット条件は必ず決定しておきます。「コンパイルできる状態」「xUnitテストがパスする状態」「結合テストがパスする状態」など、コードラインの目的に応じて決定します。
  8. タグ/ブランチのルールを決めておく
    • タイミング、名称、および、それを管理する責任者を決めておきます。
    • ブランチは、ブランチを作成する条件、およびメインラインにマージする条件を決定しておきましょう。
      • できるだけブランチは作成せず、作成する場合でも、目的を明確にし、ブランチからブランチを作成しないようにする。
      • ブランチを、メインラインにマージする期限を設ける。
    • タグは、少なくとも以下のタイミングでは作成するようにしましょう。
      • 要件FIX時/ビルド時/リリース時
  9. 個人ワークスペースを設ける
    • 大きな変更作業を加えるときなど、メインラインだけでは作業がしにくい場合があります。その場合は、開発者毎にワークスペースを設けましょう。個人ワークスペースとして、ブランチを利用するのも有効です。
  10. 必要なものは全てリポジトリに登録しておく
    • ソースコードだけでなく、ドキュメント、設定ファイル、テストデータ、ビルドスクリプト、開発環境等、開発作業に必要な成果物は、全て登録しておきます。
    • チェックアウトしたら、誰でもすぐに作業を行える状態にしておくことが必要です。