豚吐露@wiki

svn運用ルール

最終更新:

Bot(ページ名リンク)

- view
管理者のみ編集可

SubVersion運用ルール(案)


■環境
以下の環境を前提とする。
Windows OS
◆TortoiseSVN
  http://tortoisesvn.net/
  SVNクライアントツール。
◆WinMerge 日本語版
  http://winmerge.org/
  diffツール。


■SVN運用概要
SVNを用いてVersion管理を行うにあたり、以下のようの運用する。
本件ではSVNを用いて全てのドキュメントのVersion管理を行う。
※全てのドキュメントとは『ソースファイル』『仕様書』など電子fileで管理される全てのものを指す。
全てのドキュメントはSVNのリポジトリに格納される。この時、リポジトリは1projectに対して1リポジトリとする。
リポジトリはバックアップ環境では無いことを認識する。
リポジトリへの操作は、リポジトリが全メンバで共有する環境であることを認識し、他のメンバへの影響を常に考えること。
バイナリファイル(Word、Excelファイル等を含む)を編集する場合、差分のマージができないためロック後編集すること。

【作業手順】
作業は基本的に以下のような手順で行う。

 work作成(trunkからソースをsvn co)
  ↓
 work修正
  ↓
 変更箇所が所望の変更のみか確認(svn diff)
  ↓
 評価
  ↓
 変更箇所が所望の変更のみか確認(svn diff)
  ここで修正したら再評価
  ↓
 修正内容をコミット(svn ci)
  ↓
 修正logの確認(svn log)
  コミット漏れが無いか?所望の変更のみコミットされているか?想定外の変更がコミットされていないか?
  変更とか加えて無い別workをupdateして、buildできるか?とか確認した方が良い。

この作業の際、以下のルールを遵守すること。
◇build出来る環境をciする
◇1対応 1work、1対応 1ciを心がける
 『過去の不要なコメント削除』『インデント変更』『スペース削除・タブ化』『改行変更』『リファクタリング』などを修正対応と同時に行わない。
◇ciの際、コメントに対応内容の概要を記述する
 ※Add:機能追加,Imp:機能改善,Fix:バグ修正,Chg:仕様変更,Ref:リファクタリング などのキーワードを用いる方が望ましい。
 ※チケット駆動開発の場合、チケット番号を先頭に記述する
◇対応途中の中途半端な状況でciしない
◇無駄にci回数を増やさない(無駄にRevを進ませない。1file毎にCheckInしたりしないように。)

【ユーザ管理】
リポジトリを操作するuser idは各個人毎に作成すること。
LDAPサーバーを保有してあるのであれば、LDAPサーバーと連携させることも可能。

※当該ドキュメントは、Windows OS上からTortoiseSVNを用いてリポジトリ操作を行う場合について書いているが、他環境からであっても、上記ルールを遵守すること。

【リポジトリ構成】
ISMSの観点からリポジトリは1project毎に作成。
これは、業務終了後はリポジトリを破棄しなければならない場合が多く、1つのリポジトリに複数projectの情報を格納してしまうと破棄が難しくなるため。

リポジトリは『trunk』『branches』『tags』の3つのdirをbase dirとして管理する。
それぞれのdirの意味は以下の通り。
repos
 │ 
 ├ trunk
 │   開発のメインライン/ベースライン。基本的に各メンバはtrunkからworkを作成して作業する。
 │   project内で複数のmoduleがある場合、trunk以下でdir分けを行う。
 ├ tags
 │   releaseタイミングで任意のbranchから作成し、release情報を格納するdir。
 │   tagsはrelease情報を格納するためのdirであるため、一度作成したら修正を行ってはならない。
 │   ※tags以下へciを行うのは、tags作成後のrelease情報を作成しciする1回のみ。それ以外のciは認めない。
 └ branches
      trunkのsnapshot。任意のタイミングでrelease用の(tagを生成する用の)安定版を保持する。
      releaseは任意のbranchからtagを作り行う。release後に不具合が発生したらtagを作成したbranchを修正する。
      ※brancheへのciはbug fixなど軽微なもののみとする。
      修正したbranchから再びreleaseする場合は新たにtagを生成する。
      branches以下へはrelease後の不具合発生時のみ修正を行う。
      また、branches以下へ行った修正は速やかにtrunkへ反映させること。
      ※branches以下へのciはtrunkへのciとはルールが異なるため、注意!

project内に複数のmoduleがある場合、base dir以下にmodule毎の固有dirを作成し、管理する。
また、固有dirを作成する場合は『trunk』『branches』『tags』の下にそれぞれ作成すること。
※後で複数のmoduleを管理する可能性がある場合、あらかじめdirを切っておくこと。

e.g.)module calcの場合
repos
 ├ trunk
 │  └ calc
 │      └ calc.c
 ├ tags
 │  └ calc
 │      └ 1.0.x
 │          └ calc.c
 └ branches
     └ calc
         └ 1.0.0
             └ calc.c

【リリース手順】
リリースを行う場合、必ずtagを作成し、tagからリリースモジュールを作成すること。
tagを作成するためには、brancheが必要となるため、必然的にbrancheも作成することとなる。
基本的に作成したtagへの修正ciは、tags作成後のrelease情報を作成しciする1回のみとする。
それ以外のciは認めない。
e.g.)
tags作成(svn cp) → tags co → release情報作成(build結果含む) → release情報ci → release情報co → release

またbrancheへはbag fixなど軽微な修正のみciを許容する。
ただし、brancheへのciルールは、trunkと異なる事に注意!(後述)
brancheへ修正を行った後、再度リリースする場合、新たにtagを作成すること。
また、brancheへ行った修正は速やかにtrunkへ反映させること。
※機能追加など、大きな修正を行う場合はtrunkに対して行ない、新たにbrancheを作成すること。

branchを作成する場合、『MajorVersion』と『MinorVersion』と『x』を『.』でつなぎVersionを表現する。

e.g.)Branche Version定義
1.0.x
││└ PatchVersion: branch作成時は『x』固定とする。
│└─ MinorVersion: branch作成時決定する。0から始まり、前のbranchの『MinorVersion+1』とする。
└── MajorVersion: Project開始時決定する。

tagを作成する場合、『MajorVersion』と『MinorVersion』と『PatchVersion』を『.』でつなぎVersionを表現する。

e.g.)Tag Version定義
1.0.x
││└ PatchVersion: branch作成時決定する。0から始まり、前のtagの『PatchVersion+1』とする。
│└─ MinorVersion: tag作成元のbranchのMinorVersionに準じる。
└── MajorVersion: tag作成元のbranchのMajorVersionに準じる。

e.g.)
Release要求 → branches/calc/1.0.x作成 → tags/calc/1.0.0作成 → Release1.0.0
Release1.0.0で不具合発生 → Release元branches/calc/1.0.xを修正 → 新たにtags/calc/1.0.1作成 → Release1.0.1 → 修正内容をtags/calc/1.0.1からtrunkへ反映
新たなRelease要求 → 前回Releaseからtrunkが大幅に変わっているため新たにbranches/calc/1.1.x作成 → tags/calc/1.1.0作成 → Release1.1.0
Release1.1.0で不具合発生 → Release元branches/calc/1.1.xを修正 → 新たにtags/calc/1.1.1作成 → Release1.1.1 → 修正内容をtags/calc/1.1.1からtrunkへ反映
Release1.1.1で不具合発生 → Release元branches/calc/1.1.xを修正 → 新たにtags/calc/1.1.2作成 → Release1.1.2 → 修正内容をtags/calc/1.1.2からtrunkへ反映

【ci】





更新日: 2013年01月17日 (木) 10時10分22秒

  • 課題: 複数チームでの開発に耐えられるルールか? -- (s1n) 2010-11-16 20:49:57
  • 課題: TrunkへのciとBrancheへのciルールを明確にする必要がある。 -- (s1n) 2010-11-16 20:50:38
名前:
コメント:

すべてのコメントを見る
記事メニュー
ウィキ募集バナー