構成管理

拝見しているかくたにさんのところで、やっと邦訳が出たのを知った。ありがとうございます。

パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

以前偉そうに書いたが、うちは結構製品や改変リリースの回数が多いうえ、開発サイトが離れがちなので、これを一人で勉強してポリシーや用語をもらった運用を作ってやっている。でも、英語だとほかの誰も読んでくれないんだよね(苦笑)。ほんと助かるわー。これ。意外にね、会社だと、最後の各ツールの対応表が役に立つよ。SCM関係ないオヤジが「くりあけーす」とか言ってくるでしょう、金ないのに。そういうときとか、あとはアレ、会社や国によって「やっぱすたーちーむ」「しなじーっしょ」なんて言われた時。ツールにだけはやたらクチ挟むやつに有効。svnユーザはCVSんとこ見せれば、ツールはどっちでもまず文句を言いません(笑)から大丈夫。
ツール話だけじゃあれだから、職場ローカルなパターン実装の実例を挙げておきます。完全オヤジなネタ。

• Codeline Policy(12)は計画書として書く。せめてチームのWikiには明記。絶対いつでも見える所に置き厳守する。
• Mainline(4)、ADL(5)は従来の案件から見て、同じもの(trunk)に統合する。
• 同様に製品リリースの作業を見て、Release-Prep Code Line(18)だけ使い、Release Line(17)は紹介せず、RPCL(18)を代わりに「リリースライン」と言う。
• Private Workspace(6)は「ワークスペース(svn coしたもの)」、Repository(7)は「リポジトリ」、Third Party Codeline(10)は「ベンダーブランチ」と言う。
• Private System Build(8)、Integration Build(9)は「ビルド」で統一し、ビルド時間がかかるなら分ける。分けたことないけどね。デベロッパが分けるのを嫌がる事もある。
• Somke Test(13)、Unit Test(14)、Regression Test(15)は、うちは組み込みなのもあって、全部まとめて「実機(基板)テスト/それ以外」の2つだけに分割。みんな自動テストにすれば書くし、実機じゃ本気のCPU例外投げることもあって'F'すら表示できないからな。
• Private Versions(16)、Task Branch(19)は原則禁止。あまり支障が無いのもあるが、ブランチ避け(ローカルルール)もある
• Task Level Commit(11)は「コミッタ(デベロッパ)が守るべきこと」と、コツとして説明。大体、あとで泣くのはコミットした本人だから。「なんでA直すとBつぶれんだよこのカス」と俺に責められるし。

あとはローカルルール。

• バージョン番号ルールも(以前書いたように)計画書なりに明記。厳守。じゃないとスクリプトが書けない。
• ブランチを切っていいのは、そのブランチが本線から切ってあり、以下のいずれかを満たした時だけ。
  • そのブランチはある具体条件を満たしたら捨てられる
  • そのブランチはある具体条件を満たしたらtrunkにマージされる
  • そのブランチはある具体条件を満たしたらtrunkになる

最後のルールは今、あらゆるブランチに適用している。あんまりまずい事もないんだけど、パターンには無い。もちろん、うちだけだとは思ってるんだけど、なんかまずい事例ってあるのかな。Release(-Prep) Codelineもこれに含まれると思うんだけどな。根拠は、経験です。「おれブランチ」や「階段ブランチ(よくあるブランチの悪い例)」排除。
あとはまあ、もちろん、裏ルールに

• Codeline Policy(12)に沿わないものはいくら動くと言われても、営業がどうほざこうが拒否し、チーム外にはNamed Stable Buildsしか見せない
• Private System Build(8)、Integration Build(9)の結果とバイナリは、決してチーム外に見せない

あたりもあるがね(笑)。
まあそういう背景で開発ルールを書いていて、これだとCodeline Policy(12)にバージョン番号も入れておかねえと結構面倒臭いだろうな、と思って書いたのがその以前書いたエントリなんだが、意外に参照してくださる方が多かった。こういう所に日記を書いている本人にとって、見られるのはとてもうれしかったのだが、今回の邦訳で背景にある事が見えてもっと役に立つなら、本当にうれしいですわ。まだここ読んでる人が居るかという話もあるがな(笑)。本と酒とライブの話ばっかりだから。