 |
||||||||||||||||
|
||||||||||||||||
| 1 2 3 次のページ | ||||||||||||||||
|
||||||||||||||||
| はじめに | ||||||||||||||||
|
前回は、Subversionの概要と使い方について紹介しました。今回は、ウノウにおけるSubversionの導入事例とウノウで提供している写真・動画共有サービス「フォト蔵」を例に、具体的なSubversionの運用事例を紹介します。 |
||||||||||||||||
| Subversionの導入事例 | ||||||||||||||||
|
本連載の「第1回：PHP開発の手法とは」でも紹介した通り、ウノウではソースコードの管理システムとしてSubversionを導入しています。 Subversionでは、ウノウで提供しているサービスやウノウラボ（blog）で公開しているものまで、すべてのサービスのソースコードを1台の開発用サーバで管理しています。 今日現在では、1つのリポジトリに約15個のモジュールが管理されています。管理しているソースコードは、主に次のようなものです。
表1：管理しているファイル ウノウでは表1の通り、サービスに使われているプログラムはもちろん、その他の必要なプロジェクトファイルなども例外なく、すべてSubversionでバージョン管理しています。 Subversionでは、テキスト形式のファイルだけではなく、その他のバイナリ形式のファイルもまとめて管理することが可能です。ただしバイナリ形式のファイルの場合は、変更内容（差分）を参照することはできません。またワード（拡張子がdoc）やエクセル（拡張子がxls）のファイルは、バイナリ形式のファイルとなります。 |
||||||||||||||||
| 共通の開発環境と個人の開発環境 | ||||||||||||||||
|
筆者の会社では、エンジニアが開発サーバにログインしてサービスの開発を行っています。開発サーバには、SubversionとWebサーバがインストールされており、「共通の開発環境」と「個人の開発環境」の2つがまったく別の環境になるように構築しています。 両方の環境とも、Subversionのリポジトリからチェックアウトしたリポジトリのコピーの上で動くように構築されています。そのため、共通の開発環境をすぐに更新することが可能です。 「共通の開発環境」は、テスターが試験する環境となっています。また共通の開発環境は、本番環境へアップロードする直前の環境です。本番環境へのアップロードは、必ずエンジニアではなく「テスター」が更新する体制をとっています。 「個人の開発環境」とは、エンジニア個人ごとに完全に分かれている開発環境です。個人の開発環境は、どんな変更をしても共通の開発環境には影響を与えないようになっています。個人の開発環境で機能追加などの変更をした後は、Subversionでコミットすることで、自動的に「共通の開発環境」に反映されるような仕組みを構築しています。 この仕組みは、Subversionの「hook」という機能を使って実現しています。この「hook」とは、リポジトリに変更がある直前や直後に特定のプログラムを実行させる仕組みのことです。 ウノウでは個人の開発環境からのコミット直後の「hook」に「共通の開発環境を更新する」、つまり「svn update」コマンドを実行するように設定しています。こうすることで、先ほど述べたように自動的に「共通の開発環境」に反映されるのです。 |
||||||||||||||||
|
1 2 3 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
