■ SubversionによるPHP開発環境バージョン管理話
これまでPHPでいくつかシステム開発を行ってきたワケですが、お恥ずかしい話ながら複数開発者がいるような環境でもこれまで特に「バージョン管理」ってのを行ってきませんでした。
や、まあヒトの手による記述程度のバージョン管理は行ってきましたが、あくまで当事者達の主観によるものでありそれらが共有される事はあまりなく、つまりはバージョンの意味合いが曖昧になりがちでした。
また、同じファイルを数人でいじる事もあったため、「声かけ」という初歩的な回避策しかとれない環境ではバックアップのタイミングやら戻しやらでのデグレも何度か発生し、且つソレの原因がどこにあるか判別付かないパターンが何度かありました。
なんとかしたいなあ、と思いつつも具体的な手法となると色々環境による制約がついてしまってイマイチ導入に踏み切れない。世の中的には「バージョン管理」というと「CVS」がほぼ代名詞になってるっぽいなあ、などと色々調べてるウチに、ひっかかったのが標題の「Subversion」。CVSを踏襲しつつ弱点を補う事を目的として作られたモノっぽい。色々情報見てるとよさげだが、一貫した情報が欲しかったので書籍を購入し、翌日には稼働開始させました。インストールやら初期導入やらは他に詳しいサイトさんが多いので割愛します。
さて、とりあえず導入したのは例によってLinuxのPHP+Smarty環境。ヒトが作ったシステムの改修なのですがどーもあまりPHPもSmartyも知らないヒトが作ったっぽく、テンプレートフォルダを堂々とDocumentRoot下に置くなんだかなぁ設計。
まあおかげでリポジトリは作りやすかったですが。とりあえずDocumentRoot下を丸々インポート。と同時にこのシステム、管理者用に仮想フォルダが一個あるんでそちらも別にインポート。
さて今回は開発環境はWindows端末を想定。今までならLinux上でvi使いやがれ、と言うのが基本方針なんですが(笑)、そうすると一般開発者のバージョン管理にSubversionのコマンド操作を強要する事になる。中にはPHPのコーディングも微妙なヒトがいたりするので(苦笑)余計な負担は極力減らした方がいい、と判断。 Windowsで簡単にSubversionをコントロールできる「TortoiseSVN」を導入しました。
そのTortiseSVNとの通信を行うために、Subversion付属の簡易サーバ「svnserve」を稼働。そもそものリポジトリ構成を
一般用: /repos/normal
管理用: /repos/admin
とした際に、svnserveの起動オプションを
svnserve --daemon --root /repos
と指定。こうすることでTortoise側でアクセスする際に
一般用: svn://[サーバ]/normal
管理用: svn://[サーバ]/admin
と分けて個別にアクセスすることができるようになります。
さて、PHPは当たり前ですがWebアプリケーション。特定のDocumentRoot下、要するに今回の場合インポート元フォルダの内容が更新されないと修正の結果がWeb上に表れません。
なのでDocumentRootもリポジトリからデータをチェックアウト→更新の流れにする必要があるわけですが、各個別の開発者が自分に関係するファイルをコミットする度にサーバ側で「svn update」をするのはメドい。各自のコミットが成功したら、DocumentRootは自動更新されるのが望ましいわけです。
それを実現するのがいわゆるフックファイル。各リポジトリディレクトリの「hooks」ディレクトリに置かれ、コミットの前後など特定のタイミングで稼働するシェルファイルです。
今回の場合、コミット後に稼働する「post-commit」に「/usr/bin/svn update [DocumentRoot]」みたいに記述することで、クライアントのコミットと同時に自動更新される環境が構築できます。
なんてな(笑)。
いや上記の方法で自動更新一応できるはできるんだけど、状況?環境?によって出来ない場合もあるっぽい。「post-commit」そのものはちゃんと動作するのだが、「svn update〜」がちゃんと動かない環境がある。
今回の場合、具体的には「一般」のDocumentRootは問題なく更新されるのだが、「管理」のDocumentRootの更新が行われない。
試しに1つのpost-commitに一般、管理双方を更新するコマンドを記述し、且つその結果をリダイレクトでファイルに書き出してみたんだけど、更新される一般側はその結果がファイルに残るのだが、更新されない管理側はなーんにも表示されない。フォルダが間違ってるとかのエラー系も出ない。
ところがpost-commitを直接コマンド叩くとどちらの更新も成功するのでワケわからん。シェル内に「whoami」書いて権限調べたりもしたのだが、コミット連動、コマンド直叩きどちらも当然のよーに「root」で動作してる。もーわけわからんナリよキテレツ!
で、コレの対処をどうしたかというと、「svn update /DocumentRoot/*」と言う風に、本来フォルダ指定だけでいけるところをわざわざワイルドカードで中身全指定したら一応は更新されるようになった。処理結果の吐き出し具合を見ると少し微妙ではあるのだが、サブフォルダに変更加えてソレをコミットしてもちゃんと更新されるので、とりあえず実用的には問題ないと判断してます。
ただこの状況がどーゆー理由で発生してるかがよく分からないので、今大丈夫な方もいずれダメになる可能性を否定できないのが怖い。とりあえずは様子見しながら使ってみます。
ま、更新だけの話なんで、マスターであるリポジトリに影響するような致命的な問題じゃないんでいいんだけどね。
追記:
Windows側(TortoiseSVN側)でファイルを追加→コミットした場合に、post-commitでのupdateで新規ファイルが出力されない状況も発生中。サーバにログインして「svn update」するとあっさり表れる。
つまるところSubversion純正のコマンド群はイマイチpost-commit(というかフックファイル)と相性悪いって事だろか。それともバージョン次第か。
や、まあヒトの手による記述程度のバージョン管理は行ってきましたが、あくまで当事者達の主観によるものでありそれらが共有される事はあまりなく、つまりはバージョンの意味合いが曖昧になりがちでした。
また、同じファイルを数人でいじる事もあったため、「声かけ」という初歩的な回避策しかとれない環境ではバックアップのタイミングやら戻しやらでのデグレも何度か発生し、且つソレの原因がどこにあるか判別付かないパターンが何度かありました。
なんとかしたいなあ、と思いつつも具体的な手法となると色々環境による制約がついてしまってイマイチ導入に踏み切れない。世の中的には「バージョン管理」というと「CVS」がほぼ代名詞になってるっぽいなあ、などと色々調べてるウチに、ひっかかったのが標題の「Subversion」。CVSを踏襲しつつ弱点を補う事を目的として作られたモノっぽい。色々情報見てるとよさげだが、一貫した情報が欲しかったので書籍を購入し、翌日には稼働開始させました。インストールやら初期導入やらは他に詳しいサイトさんが多いので割愛します。
さて、とりあえず導入したのは例によってLinuxのPHP+Smarty環境。ヒトが作ったシステムの改修なのですがどーもあまりPHPもSmartyも知らないヒトが作ったっぽく、テンプレートフォルダを堂々とDocumentRoot下に置くなんだかなぁ設計。
まあおかげでリポジトリは作りやすかったですが。とりあえずDocumentRoot下を丸々インポート。と同時にこのシステム、管理者用に仮想フォルダが一個あるんでそちらも別にインポート。
さて今回は開発環境はWindows端末を想定。今までならLinux上でvi使いやがれ、と言うのが基本方針なんですが(笑)、そうすると一般開発者のバージョン管理にSubversionのコマンド操作を強要する事になる。中にはPHPのコーディングも微妙なヒトがいたりするので(苦笑)余計な負担は極力減らした方がいい、と判断。 Windowsで簡単にSubversionをコントロールできる「TortoiseSVN」を導入しました。
そのTortiseSVNとの通信を行うために、Subversion付属の簡易サーバ「svnserve」を稼働。そもそものリポジトリ構成を
一般用: /repos/normal
管理用: /repos/admin
とした際に、svnserveの起動オプションを
svnserve --daemon --root /repos
と指定。こうすることでTortoise側でアクセスする際に
一般用: svn://[サーバ]/normal
管理用: svn://[サーバ]/admin
と分けて個別にアクセスすることができるようになります。
さて、PHPは当たり前ですがWebアプリケーション。特定のDocumentRoot下、要するに今回の場合インポート元フォルダの内容が更新されないと修正の結果がWeb上に表れません。
なのでDocumentRootもリポジトリからデータをチェックアウト→更新の流れにする必要があるわけですが、各個別の開発者が自分に関係するファイルをコミットする度にサーバ側で「svn update」をするのはメドい。各自のコミットが成功したら、DocumentRootは自動更新されるのが望ましいわけです。
それを実現するのがいわゆるフックファイル。各リポジトリディレクトリの「hooks」ディレクトリに置かれ、コミットの前後など特定のタイミングで稼働するシェルファイルです。
今回の場合、コミット後に稼働する「post-commit」に「/usr/bin/svn update [DocumentRoot]」みたいに記述することで、クライアントのコミットと同時に自動更新される環境が構築できます。
なんてな(笑)。
いや上記の方法で自動更新一応できるはできるんだけど、状況?環境?によって出来ない場合もあるっぽい。「post-commit」そのものはちゃんと動作するのだが、「svn update〜」がちゃんと動かない環境がある。
今回の場合、具体的には「一般」のDocumentRootは問題なく更新されるのだが、「管理」のDocumentRootの更新が行われない。
試しに1つのpost-commitに一般、管理双方を更新するコマンドを記述し、且つその結果をリダイレクトでファイルに書き出してみたんだけど、更新される一般側はその結果がファイルに残るのだが、更新されない管理側はなーんにも表示されない。フォルダが間違ってるとかのエラー系も出ない。
ところがpost-commitを直接コマンド叩くとどちらの更新も成功するのでワケわからん。シェル内に「whoami」書いて権限調べたりもしたのだが、コミット連動、コマンド直叩きどちらも当然のよーに「root」で動作してる。もーわけわからんナリよキテレツ!
で、コレの対処をどうしたかというと、「svn update /DocumentRoot/*」と言う風に、本来フォルダ指定だけでいけるところをわざわざワイルドカードで中身全指定したら一応は更新されるようになった。処理結果の吐き出し具合を見ると少し微妙ではあるのだが、サブフォルダに変更加えてソレをコミットしてもちゃんと更新されるので、とりあえず実用的には問題ないと判断してます。
ただこの状況がどーゆー理由で発生してるかがよく分からないので、今大丈夫な方もいずれダメになる可能性を否定できないのが怖い。とりあえずは様子見しながら使ってみます。
ま、更新だけの話なんで、マスターであるリポジトリに影響するような致命的な問題じゃないんでいいんだけどね。
追記:
Windows側(TortoiseSVN側)でファイルを追加→コミットした場合に、post-commitでのupdateで新規ファイルが出力されない状況も発生中。サーバにログインして「svn update」するとあっさり表れる。
つまるところSubversion純正のコマンド群はイマイチpost-commit(というかフックファイル)と相性悪いって事だろか。それともバージョン次第か。
関連タグ:PHP
Subversion
関連記事:
■Windows版ZendServerのhttpd.confを編集しても設定が反映されない場合
■PHP53においてtimezoneをAsia/Tokyo設定した場合話。
■Facebookが公開したPHP仮想マシン「HipHop VM」とは
■PHP開発チームが「PHP 5.3.7」の重大なバグを報告、「5.3.8を待つように」
■PhpMyAdmin等を狙った攻撃とか
■2011年1ヶ月経過後のサイト運営話。
■memcached+Zend_Cacheによるキャッシュ効果実験
■2010年急成長したプログラミング言語はPython、オランダTIOBE調べ
■Subversion関連サービスを提供する米WANDisco、Subversion改革計画を発表
■PHP,PostgreSQL
■PHP53においてtimezoneをAsia/Tokyo設定した場合話。
■Facebookが公開したPHP仮想マシン「HipHop VM」とは
■PHP開発チームが「PHP 5.3.7」の重大なバグを報告、「5.3.8を待つように」
■PhpMyAdmin等を狙った攻撃とか
■2011年1ヶ月経過後のサイト運営話。
■memcached+Zend_Cacheによるキャッシュ効果実験
■2010年急成長したプログラミング言語はPython、オランダTIOBE調べ
■Subversion関連サービスを提供する米WANDisco、Subversion改革計画を発表
■PHP,PostgreSQL
トラックバック:
※本記事へのトラックバックは登録されていません。
※トラックバック先URL:※現在メンテナンス中です。
※概要(excerpt)は255バイト付近でカットされます。
※概要(excerpt)は255バイト付近でカットされます。




