SVNリポジトリの管理方法
かおるんさんの記事のコメントで、誤った意見を書いてしまったので修正しておく。
【元ネタ】
Subversion のフォルダ構成 - かおるんダイアリー
Subversionのフォルダ構成 | Ryuzee.com
Subversionで簡単・確実にファイルを構成管理 - @IT自分戦略研究所
【問題】
SVN直下のディレクトリは、branch/tag/trunkになっている。
ソースやドキュメントはどこに配置すべきか?
【結論】
管理したい一つのまとまり(プロジェクト)単位で、trunk/branch/tag を作った方がブランチを管理しやすいと思っていた。
最初はtrunkの中にソースやら仕様書を配置して、管理方法がよく分からなかった。
でも、さかばさんと議論してみて、ryuzeeさんのやり方が良いと思う。
思い出してみたら、下記の方法で僕も運用していた。
root.
├─branches
│ ├─1.0
│ │ └─src
│
├─tags
│ ├─1.0
│ │ ├─doc
│ │ ├─src
│ │ └─tools
│ ├─1.1
│ │ └─src
│ ├─2.0
│ │ ├─doc
│ │ ├─src
│ │ └─tools
│
├─trunk
│ ├─doc
│ ├─src
│ └─tools
基本的な考え方は「InfoQ: 複数のアジャイルチームでのバージョン管理」に従えばいい。
【方針】
1・基本は、trunkにソースやドキュメント、ツールなどのフォルダを作り、それぞれを管理する。
PGやPLは、ソース修正やドキュメント修正は、trunkへコミットして、常に最新の状態にする。
2・新規開発中のtrunkからリリースする場合、trunkからtagを作り、tagにはリリースするバージョン(例:1.0, 2.0)を命名する。
この時、ソースだけでなくドキュメントもtagのバージョンに入れる。
更に、trunkからbranchにリリースバージョン(例:1.0, 2.0)を作り、本番運用中のソースは別管理とする。
ドキュメントは最新版だけあればよいプロジェクトだったから、branchには入れない。
3・本番運用中のbranchからリリースする場合、branchからtagを作り、tagにはリリースするバージョン(例:1.1)を命名する。
【注意点】
一つは、基本は、tagにはtrunkにある全ディレクトリにバージョンを付けること。
理由は、tagのバージョンがtrunkのスナップショットだから。
実際、リリース時はソースだけでなくドキュメントも一括納品しているからだ。
もう一つは、branchには派生開発する対象のディレクトリをtrunkから分岐させること。
このやり方はいわゆるメインラインモデル。
trunkは新規開発、branchは本番運用に分けて管理する手法。
僕の場合、ドキュメントは最新版だけあればよかったからbranchに入れないが、SWプロダクトラインのように製品ファミリー単位でドキュメントも管理する必要がある場合、branchに入れた方がいいかもしれない。
branchを作ると、必ずbranch→trunkへマージ作業が発生する。
ソースというテキストファイルなら作業しやすいが、ExcelやWordは正直作業しづらい。
但し、TortoiseSVNならOfficeの差分比較ができるので、マージ作業の難易度は下がっている。
つまり、trunkに成果物を全て配置するやり方がよいと思う。
その理由は、「Subversionのフォルダ構成 | Ryuzee.com」で詳しく書かれている。
実際、trunk/tag/branchに含まれないフォルダは、最新版なのか古いのか分からないからだ。
「Subversionで簡単・確実にファイルを構成管理 - @IT自分戦略研究所」の記事も読み合わせると、ドキュメントもソースと同じライフサイクルで管理した方が良いと思う。
理由は、ドキュメントをリリースするタイミングはソースをリリースするタイミングと同じだからだ。
普通は、システム納品と同時にマニュアルや設計書というドキュメントも納品しているはずだ。
つまり、trunk直下にドキュメントとソースを配置した方がライフサイクルを管理しやすい。
SVNだけでなく他のバージョン管理でも同様の発想をすればいいだろうと思う。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説(2021.01.26)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
「ソフトウェア」カテゴリの記事
- マインドマップをFreeplaneに乗り換えた(2020.11.21)
- ソフトウェアの政治的影響力とは何だろうか(2020.07.07)
- DevOpsがアジャイル開発を促進する(2020.06.11)
- AzureクラウドデザインパターンとAWSクラウドデザインパターンのリンク(2020.06.09)
- Ruby技術者認定試験の感想(2020.05.08)
「ソフトウェア工学」カテゴリの記事
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
「Git・構成管理」カテゴリの記事
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
- 第16回東京Redmine勉強会の感想 #redmineT(2019.05.19)
- 第19回Redmine大阪の見所 #redmineosaka(2019.01.26)
コメント