Subversion で保守フェーズの構成管理をしてみた
以前TFSで構成管理していましたが、今のプロジェクトでは Subversion 使ってます。
Subversion はTFSと同じセントラルリポジトリ形式ですが、案件の背景に合わせて違う運用したのでメモ。
背景
- 保守フェーズ
- 運用後、要望、不具合が1日1件程度発生している状況。
- 規模
- 6人チーム
目的
構成管理台帳をなくしたい
短期間で不具合、要望に対応するためプログラマー増員。1名から4名に。しかし本番運用中。うっかり開発中のコードが混入する事態は防ぎたい。でも構成管理台帳で受払申請をするのは負荷が高い、というかそもそも意味を感じない。なので、変更はブランチで行い検証後メインラインにマージするという方法を取りました。
対応中のバージョン管理をしたい
git を使い始めてから自分用のバージョン管理できないのがストレスに。個人でバージョン管理できるということはうっかりミスしても戻せる訳で開発効率が上がります。でも、Subversion はローカルリポジトリはないので、ブランチでバージョン管理をする事に。
管理単位イメージ
main (trunk)
メインラインは常にリリースできる綺麗な状態にするため、マージのみで更新します。
topic branch (branches)
機能追加、不具合修正の管理番号でブランチを切ります。単体テスト完了後、ブランチをマージします。
release (tags)
リリースしたらタグを切っておきます。今回の案件ではリリースサイクルが短かった事、緊急対応は発生しなかったためこのラインに変更を加える事はありませんでした。
無視した事
- ハードディスク容量
ブランチを切りまくる=Subversionサーバのディスク容量消費。今回はソースコードの量が多くない事から問題ないと判断しました。
- ブランチについてのメンバーの知識不足
ブランチってなんですか?という人がいましたが手順書作成の上、習うより慣れろで使ってもらいました。
目的の達成度
2つの目標を綺麗に達成できました。メインラインの履歴が綺麗なのは追跡しやすく癖になりますね。思わぬ効果として、予定していた変更が優先度変更により実施しなくなった場合にブランチを削除するだけでメインラインを汚さずに住みました。
課題
- マージ経験者なし
ブランチを知らないという事はマージ未経験。私がやる事にしました。手順書を作成したとして、マージでコンフリクトしたらどうするかなど教える時間がなかったため、自分でやってしまいました。
最後に
Git導入しておけば早い気がするので、次の案件ではGit を使いますw日本語使えるようになったみたいだし。