サブバージョンを利用したバージョン管理をする際のサーバー構成について

Question

###前提・実現したいこと
自社で作成しているWebアプリケーションのバージョン管理を行う。

１．WEBサーバー１台で構成されている「アプリA」とWEB/DBサーバーそれぞれ１台ずつで構成されている「アプリB」のバージョン管理を行う

２．GIT導入も検討したが、開発規模（１、２人）を考えSubversionを導入することに

３．「アプリA」「アプリB」それぞれの/var/www以下のディレクトリをバージョン管理したい

###わからないこと

①リポジトリを設置する場所について、Subversion用のサーバーを立てるべきか？

→「アプリA」「アプリB」それぞれのサーバー内にsvnディレクトリを作成し
その中にtrunkを作成した場合問題があるか？

②Subversion用のサーバーを立てた場合

「アプリA」「アプリB」それぞれのディレクトリを作成し１台のサーバーに複数のリポジトリが存在しても問題ないか？

③本番環境へのリリースについて

変更内容をコミットし反映させたあと、
本番環境へのリリース作業のイメージがつかめておりません。

・上記①の場合
本番環境にリリースする際はSVN/trunk/var/www...以下のファイルを
vra/www...に「cp」でコピーするようなイメージでしょうか？

・上記②の場合
こちらもコミット後、本番環境へリリースする際の流れを把握したいです。

###補足情報(言語/FW/ツール等のバージョンなど)

前職では簡単なHTMLページで作業する際にSubversionを利用していたので、
チェックアウトからコミットまでは把握しているのですが、
本番サーバーへのアップ部分については、別サーバー担当が行っていたためよくわかっておりません。

サーバー情報などが必要な場合はご指摘頂ければ、
用意いたしますので、恐れ入りますが、ご教授頂けますようお願い致します。

Answer 1

①リポジトリを設置する場所について、Subversion用のサーバーを立てるべきか？

別でなければ行けません。
本番環境と開発用リポジトリを一緒にしてしまったら

• 本番機がマシンごと吹っ飛んだとき復旧の方法がありません
• 開発作業が本番サービスに負荷をかけることになります
• 本番公開前の検証環境がないということになるのでしょうか

「アプリA」「アプリB」それぞれのディレクトリを作成し１台のサーバーに複数のリポジトリが存在しても問題ないか？

問題ありません。svnserveでリポジトリルートを設定したら、その下にある各リポジトリが公開されます。

本番環境へリリースする際の流れを把握したいです。

svn exportコマンドを使うのがいいでしょう。
また、そのときのエクスポート先は本番ディレクトリに直接ではなく、リビジョン番号付きのディレクトリ（リリースディレクトリ）にまずエクスポートし、本番ディレクトリはリリースディレクトリへのシンボリックリンクという形にするのが事故が少ないかと思います。
リリースディレクトリへのエクスポート、そこへのシンボリックリンクの貼り替え、を一括で行うスクリプトを作ってそれを叩くようにすれば手軽かつ安全です。

Comments

[Takk0305]

ご回答頂きまして、ありがとうございます。

本番機がマシンごと吹っ飛んだとき復旧の方法がありません
開発作業が本番サービスに負荷をかけることになります
本番公開前の検証環境がないということになるのでしょうか

→こちらについて現状は小さなシステムですので検証環境は用意しておりません。
本番機がダウンしたときの復旧については、現状FTPを使ってバックアップを取っている状態になります。

追加で質問になってしまい恐縮ではございますが、
Subversionを利用して「etc」ディレクトリ等、ドキュメントルート以外（今回で言うとvar/www以外）のバージョン管理を行うことは出来るのでしょうか？

[yuba]

> Subversionを利用して「etc」ディレクトリ等、ドキュメントルート以外（今回で言うとvar/www以外）のバージョン管理を行うことは出来るのでしょうか？

できますが、それ用のetckeeperという便利なツールがsvnに対応していないんですよね。gitでやった方が。

[Takk0305]

ありがとうございます！学習コスト的にsvnを検討しておりましたが、
ツールが対応していないのであれば、gitも検討してみます。

Answer 2

私の経験則からの回答ですが…
①リポジトリを設置する場所について、Subversion用のサーバーを立てるべきか？
⇒どちらでも大丈夫かと思います。
ただ、リポジトリのバックアップを更に行いたいと考えた時には、1台のサーバの方が管理が容易かと思います。

②「アプリA」「アプリB」それぞれのディレクトリを作成し１台のサーバーに複数のリポジトリが存在しても問題ないか？
⇒システム的な問題は無いと思います。もし、別プロジェクトのソースが見えてしまうとマズい様なら、ユーザーに権限を適切に振ってあげましょう。

③本番環境へのリリースについて
⇒これは、ご自身で決めて良いのでは、と思います。
基本的に修正したソースのみを反映させるのであれば、手動でやるのが良い気がします。
または、ファイル同期ソフトを使ってリリース対象のサーバとSVNの最新のリポジトリを同期させるかですかね。

Answer 3

1. 仮に同一サーバ内にあると仮定した場合、サーバが死ぬとソースもろともやられてしまいますね。最悪の場合サーバを新しくしてソースから入れなおす、ということを考えると、svn サーバを別にしたほうが良いです。むろん、svnサーバが死んだときにも困りますから、バックアップは考えねばなりませんが。
2. 「アプリA」「アプリB」をそれぞれ別のプロジェクトととらえるだけですので問題ありません。SVN サーバ一つに複数のプロジェクトを管理させることが可能です。
3. 本番環境で一度 svn checkout しておいて、更新がかかった時に svn update すればよい話です。というか、下手に cp などしたら困ると思います。

本番環境にアップすることを決めた時点でタグをつけて、本番環境側ではそのタグまで update するようにすれば、仕掛中の作業の分まで誤って適用することを防げるでしょう。