VSSからSubversionへの移行
社内のバージョン管理をVisual Source Safe（VSS)から、Subversion(svn）にした経緯・苦労した点を書く。技術的な内容については、あまり書いてないので、ぐぐってくださいな。
1.VSSの課題
- ユーザー毎にライセンス料がかかる
- Visual Studio,EclipseなどのIDEから使えない（つかいづらい）
- VSSのリポジトリがあちこちのサーバに点在してどこに何のリポジトリがあるかは担当者のみぞ知る
- サポートが切れてる（vss6。vss2005のメインストリームサポートは今年切れる）
うちの会社は、昔vb6でアプリを作りまくっていたようです。その経緯からVSSが使われていました。（vb6にVSS6が付属してた）今でもvb6の資産も残ってますが、最近は.netもJavaも、さらにCOBOLのシステムもあったりします。
でも、そもそもユーザーごとに金かかるって、ありえねぇ。社員分も足らなければ協力会社の人のライセンスはもちろん無いから、ライブラリアンみたいな人が必要だったり、はたまた得意のzipで日付付けてファイル管理なんてことにもなってきていました。
こりゃいかんだろと。
2.なぜGitじゃないのか
今から移行するなら流行としてGitじゃねーの？と思ったが、以下の理由でやめた。
- 担当者が使いこなせない
- できるだけシンプルな構成（中央型）
ユーザー系の企業なので、コーディングできる人も少ないです。そもそもVSSを使ったこと無い人もいるので、「バージョン管理？何それ？って人もいます。
そんな人にも使わせるには、機能は少ない方が良い。
gitは機能が多すぎてオーバースペックと感じた。
これだと、導入して、使えオラ！って、言っても誰も使ってくれない可能性が高いと感じたので、パス。
あとは、svnだと仕組みとしては、だいぶ枯れているので大幅な機能変更などが無いというのもうちとしてはメリットに感じました。
3.適用範囲
ターゲットとしては、ソースは勿論ですが、うちはドキュメントもプロジェクトによってどこにあるかわからんし、最新はどこ？って、感じだったので、ドキュメントもターゲットとすることにしました。
ドキュメントも入れていいよ。って言うと、ファイルサーバみたいに使われちゃうので、一応『バージョン管理が必要なドキュメント』を管理するということにしました。
具体的には、
- マニュアル
- パラメータシート
- DB設計、帳票設計、画面設計、ファイル設計、通信設計など（変更が起こりやすいもの）
など。ただ、方針としてはあるが、実際は案件に任せることに。
4.構成
Subversion用の仮想サーバを立ててそこにSubversionを立てて、みんながそこを見に行くという中央型。
ドキュメントも対象としたので、構成としては以下の通り
| 種類 | ソフト名 |
|---|---|
| サーバ | CollabNet Subversion Edge |
| クライアント | TortoiseSVN *1 |
| diffツール | WinMerge *2 |
| Visual Studio用アドオン | ankhsvn *3 |
| Eclipse用アドオン | Subversive |
初めての人でも操作できるように、クライアントにTortoiseSVN。
Office系のドキュメントの差分を表示するためにWinMergeという構成。（デフォルトの差分ツールは、Officeソフトの機能を使うので、すごくわかりづらい）
5.環境構築
仮想サーバがWindowsなので、Subversion Edgeのインストーラーを叩けば終わり。
ローカルも同様。WinMergeのアドオンは、コピペが発生しちゃいますが難しくないです。
WinMergeインストール時にTortoiseSVN側に差分ツールの設定までしてくれます。
ただ、TortoiseSVN側の差分ツールやマージツールの設定は好みに合わせて変更した方が良いかもです。TortoiseSVNの日本語マニュアルにそこらへんの記述がある。ココの外部プログラムの設定の項参照
6.社内調整
一番面倒だったのが、関係者および上司への説明。
関係者には、利便性を。
上司には、全員使った場合に、ライセンスの費用がこんだけ浮くよってとこを強調。
提案部分から、実際の構成やルール部分まであわせて合計100ページ以上のパワポを作りました。あーめんどくさかった。
余談ですが、うちでは、Visual Studio Proのライセンスがいくつかあり、そんな状況を知るMS好きな人が「Team Foundation Serverでいーじゃんかよー」という突っ込みがありましたが、「いやいや、全員Visual Studioのライセンス持ってねーし！同じ悲劇を繰り返さす気か！」と、戦って納得してもらいました。
あとは、「サポートなしで良いのか」というオープンソースには必須の突っ込みも貰いました。
それには、subversionがリリースから10年経つこと。2011年だけで、6回のバージョンアップ（うち一回はメジャーバージョンアップ）していて、メンテも大丈夫ということで通してもらいました。
有償のサポートはあるけど、金を引っ張るのにはもっと調整や時間が必要なので、金はかけない。というころはぶれずにやりました。
無事OKがでました。
7.ルール
ルールも整えた
- リポジトリの単位
- ユーザーの権限
- フォルダ構成
- バックアップ
7.1 リポジトリの単位
VSSではバラバラだったのですが、基本はシステム単位。案件単位。社内で使うツールやライブラリなど小さい規模のものもあったのですが、それらも一つのリポジトリを割り当てました。（フォルダ構成を揃えるため）
そのため、リポジトリの数は60くらいになってしまい、確実に増えましたが、そこは割切りです。
7.2 ユーザーの権限
管理職にアドミン権限、社員にユーザー作成の権限、協力会社の方には、接続権限という形でひとまず権限分けをおこないました。
ただ、結局管理者はオレがやってます。
7.3 フォルダ構成
色々検討した結果以下のように落ち着きました。
root--+--doc--+--trunk---[工程名]
| +--branches
| +--tags
|
+--src--+--trunk-----[アプリ種類]---[src本体]
+--branches
+--tags
ドキュメントとソースを別々のタイミングでtags/branchesを打てるようにした方が良いだろうということで、上記体型にしました。
[工程名]は、ウォーターフォールなので、要件定義とか、設計とかが入ります。
[アプリ種類]は、一案件でも、クライアントやサーバなど複数種類のアプリが存在するので、それごとにまたフォルダを切ってもらうことにしました。
なお、案件によっては、srcフォルダが無い（インフラ・運用系の案件）など、いくつかパターンがあります。
これらをテンプレート化してリポジトリ作成時に適用することにしました。
7.4 バックアップ
とりあえず、全てのリポジトリのフルバックアップをダンプで取って、別サーバにコピるという方法でやってます。保存期間は、2週間。
なお、Subversion EdgeはWebの管理画面があり、そこからユーザー登録や、リポジトリの作成/削除・バックアップのスケジューリング（zip化までしてくれる）、リポジトリ作成時にデフォルトのフォルダ構成を選べることができるので便利です。
8.教育
入れたのに使われないというのは避けたかったので、説明会を開くことにしました。
あわせて操作マニュアルも作成しました。（TortoiseSVNとankhSVNの基本的な操作方法をまとめた）
その際に、VSSを使ったことがある人が戸惑うであろうポイントを説明しました。
- ロックしない
- ロックの動作の違い
- ドキュメントのマージ処理はできない
8.1 ロックしない
VSSはチェックアウトするとデフォルトでロックがかかります。
svnはロックしません。これは、並行開発を便利にするためですが、VSS脳の人は自分が触ってるソースを他人が触ることには拒否反応します。
なので、その場合には、マージ処理があるから便利ですよ。ロックも機能としてはあるよ。でも、ケースによっては、コンフリクトがあって面倒だから、こまめに更新&コミットしようね。ということを説明しました。
（余談ですがｖｓｓの後継のTFSも、デフォルトではロックしません）
8.2 ロックの動作の違い
先ほど、ロックしないという話をしたが、その際に「じゃ、ロックすれば解決だね」と受け取る人がいますが、vssのロックとsvnのロックは動作が違います。
何が違うかと言うと、
- vssのロックは他人がチェックアウトできない
- svnのロックは他人がチェックアウトできるが、コミットができない
ということです。つまり、
vssは、チェックアウトする時点で、他人がこのソースを触ってると気付けますが、svnは気付けません。
なので、誰かが使ってるのを知りたかったら、リポジトリエクスプローラで、ロック状態を確認したりする必要があります。
この点知らないと、コミットするときに「何だよオレが思ってるロックじゃねぇ！」と言われる可能性があるので、注意
8.3 ドキュメントのマージ処理はできない
今回ドキュメントもバージョン管理の対象にしているので、ドキュメントもマージ処理使えると思う人がいるかもなので、バイナリファイルに対しては、マージ処理が使えないことを説明。
なので、ドキュメントは全然別の場所を変更していても100％コンフリクト。
ドキュメントの手でのマージって地味で面倒なので、複数人で修正しないようにするか、ロック使うかを状況で使い分けるよう推奨。
9.移行
ここで問題になったのは、VSSの変更履歴を持っていくかどうか。
vssからsvnに移行するツールは、あるようなのですが、検討した結果、今回は、過去の履歴は捨てることとしました。（と言ってもvssを残しといて参照できるようにはしておく）
理由は、現状のVSSのフォルダ構成が、新たに決めたsvnのフォルダ構成に合わないから。（既存のVSSのフォルダ構成はノールールで自由すぎて理解不能）
そのため、VSSの最新ソースを全部チェックアウトして、それをsvnのフォルダ構成に合わせて、インポートするということにしました。
実は個人的な思惑がもう一つあって、それは、今VSSで管理されている物って本当に全部バージョン管理する必要があるのかよ。ってやつ。
このプロジェクトめっちゃ昔から変更されてないやん。
何でもかんでもvssにつっこんでいて明らかにファイルサーバとして使ってるやん。
メモやメールなんかのゴミファイルが混ざりまくってるやん。
今回、上記のような移行プロセスを経ることで、そういったゴミがフィルタリングされることを狙いました。
現状事前に作成した60のリポジトリのうち４つしか移行できてないですが、やはり明らかにバージョン管理の必要性が高いもので、かつゴミファイルが無いという状況になっています。
10.結論
こういう今の仕組みを変える上での社内調整は超絶面倒くさい。（地味で見えにくい効果なのは特に）
ただ、協力会社の人とか、思ってはいても立場上変えることができず、結果不便な環境で仕事しなければならない人が結構いて、その人たちが喜んでくれたのは、やってよかったなと思いました。
次はjenkins入れたいっす。
