2012年06月14日

これから始めるSubversionの使い方

弊社では、未だにSubversion(svn)を利用してソースやドキュメントのバージョン管理をしています。
まだ、ドキュメントをバージョン管理している案件はましなのですが、未だに全部を共有ファイルサーバー上で管理して、編集前にバックアップフォルダに日付を付けて移動。。。ということをやっている方々も多いです。

Subversionですら、浸透するまでに4年近くかかりました。本当はMercurialかGitにしたいのですが、TortoiseSVNから離れられない人が多いのと、新しいことを覚えたくない人と、分散バージョン管理を理解できない人のいずれかが多く、Subversionでうまいこと競合等を管理する必要があると考えていました。

「うまいことやる」ということは、よろしくない状況が発生しているということです。
具体的には以下の様なことが多発しています。

・複数人で開発していると誰かがソースを上書きしてコミットしてしまう(確認不足)
・エラーが発生したままでソースをコミットし、全員がエラー発生状態になる
・そして、エラーが発生していても本人はなかなか修正しない。。。
・動かない設定や自分ローカルで勝手に変更した設定をコミットする
・コミットとバックアップを勘違いしている
・複数人がtrunkで開発するので、どうしても仕方なく構成を変更したい場合、全員一時的にコミットさせ、構成変更後に全員チェックアウト/更新しなおし
あとは個人的な話ですが。
・svn:needs-lockがかかっていると、ちょっと面倒臭い。。。
・svn:needs-lockをかけていると、たまに削除も何もできないファイルがリポジトリサーバに取り残させる。。。
・結局ロックは奪えてしまうので、誰でも変更できる

リポジトリの管理やユーザー管理については、Windows限定ですが、VisualSVNという素晴らしいソフトウェアが無料で提供されており、大変重宝しています。


すでに構築されてしまっているsvnは仕方なしとして、これから新規に始める案件で、svnも新規に作れる案件ではこうしようと考えています。


1. ディレクトリ構成
従来までは以下の様な構成でした。
-+branches
+tags
+trunk

これをこのように変更します。

-+branches
+tags
+releases
+trunk
+groups
+users

・branches
個別の仕様変更ごとにディレクトリ名をつけてtrunkの内容をコピーします。
フォルダ名は案件にもよりますが、通常は以下のいずれかようになると考えています。
1) 日付-内容
2) 案件管理番号-内容
3) 案件管理番号-日付-内容
4) 顧客名/日付-内容
5) 顧客名/案件管理番号-内容
6) 顧客名/案件管理番号-日付-内容
(/はディレクトリをさらに作ることを意味しています。)

・tags
プロジェクト内マイルストーン単位でディレクトリ名をつけてtrunkの内容をコピーします。
フォルダ名は案件にもよりますが、こちらも通常は以下のいずれかようになると考えています。
1) 日付-内容(理由)
2) マイルストーン名-内容(理由)
3) マイルストーン名-日付-内容(理由)

・releases
通常は顧客には複数の環境が用意されています。例えば、顧客検証用、顧客受入用、顧客内ベンダー開発機、リリース検証機、本番機、災対機(待機系)。さらには自社の開発環境、テスト環境(単体/結合/総合等)があります。
それぞれ、どのパッチをどこまで適用するか異なる場合があります。それが順次段階を経て適用されるのであれば良いのですが、これまで数回、緊急のためにすぐにリリース検証機で簡単な検証後、本番に適用し、数日後に他のサーバーに適用ということがありました。
そして、運が悪いことに顧客都合によってそのスケジュールが延びることもあります。これらをどこまで適用したか管理するためにExcel管理台帳とか、共有フォルダにおいていたりしましたが、これをsvnのreleasesにディレクトリ単位で管理したいと考えています。

同時に、パッケージやそのカスタマイズ結果など、複数の顧客を管理する必要がある場合にも利用します。

具体的には以下のディレクトリ構成を採用します。

releases/顧客名/No-環境名
Noは適用順序を示します。二桁で統一します。(1なら01とする)

・trunk
trunkはこれまで通りの利用方法に近いです。安定版の最新を入れる形になります。
が、こちらもディレクトリ構成を分ける方が良いでしょう。

1) trunk/stable
2) trunk/develop
3) trunk/チーム名/
4) trunk/顧客名/

などです。

・groups
こちらは用意するかどうかは案件の規模によります。
大きい場合はグループごとにディレクトリを分けます。

groups/グループ名/

このグループの下は、グループ単位で成果物を取りまとめる場合に利用します。
つまり、グループ管理者が一度ここにユーザーの成果物をとりまとめ、問題がなければtrunkにマージします。

・users
こちらは開発者単位でディレクトリを作成します。

users/ユーザー名/
ユーザーが自由にコミットしてよいディレクトリとなります。

groupがある場合はユーザーはgroupにのみマージできます。また、groupがない場合はtrunkのdevelopにのみ、ユーザーはソースをマージできます。


2. ユーザー
ユーザーとグループの管理をきっちりと行います。
一般ユーザーはusers/配下の自分のディレクトリにしかコミットできません。よって、チェックアウトもそこから行います。案件に参画したタイミングで、trunkの必要な情報を自分でコピーします。
また、場合によってはgroupsに自分のコミット分をマージできます。groupsがある場合は一度groupsにコミットし、trunkの反映はそのグループの管理者のみが行えます。逆にgroupsがない場合はユーザーはtrunk/developにマージできますが、trunk/stableへのマージは案件のライブラリ管理者がチェック後、行います。


3. ライブラリアンをたてる
ライブラリアンしか、ユーザーの管理、グループの管理が行えません。通常最大でも3名とします。
さらにグループ毎に1名をグループのサブライブラリアンとし、trunk/developにコミットする権限を有します。
ですが、trunk/developからtrunk/stableやbranches、tagsにはライブラリアンしか変更できません。


4. 個別要件(ブランチやタグ)の管理
ライブラリアンは案件上ブランチやタグに直接コミットできるユーザーを指定し、個別機能の修正を許可することができます。


5. needs-lockは使わない
ロック機能は使わないこととします。また、ライブラリアンも直接stableを変更せず、自分のユーザーディレクトリの中で変更後、trunk側にマージすることとします。


6. ライブラリアンはtrunk/stableを変更した場合、ユーザーは任意のタイミングでtrunk/stableをマージできる


7. できる限り、グループの管理者、ライブラリアンが修正結果の連絡を受け取りマージする。つまり、ユーザーには本体のtrunk等には変更権限を与えない


まだまだやり方や構成については検討の余地があると思います。それは管理がまだ面倒そうだというところです。
ですが、これでかなり管理者の自由度が上がるのではないかと考えています。
もう少しドキュメント化したり、実際にやってみてブラッシュアップしたいと考えています。
posted by Kiruahさん at 20:00| Comment(0) | TrackBack(0) | ノウハウ
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス: [必須入力]

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/56475631
※ブログオーナーが承認したトラックバックのみ表示されます。
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック