[Sitecore][Environment]開発環境とその流れ

よく新人に開発環境とそれぞれの環境へのコードのデプロイメントに関して聞かれたことがある。もともとオープンソースの開発だったため、サブバージョンを使って、開発→QA→リリースとそれぞれの環境設定ファイルを読み込んで製品をリリースしていました。ASP.NETの世界に入ってから初めてわかったことはそれぞれのお客さんの既存環境にいろいろと制限があり、特にセキュリティに関してその規制が一層複雑でコマンドラインでBuildだけでは行かないものです。これまでに私が使ったまた理解している開発環境、そして、それぞれの環境へのコードとデータベースのデプロイメントに関して書いてみたい思います。

一般的な開発環境との流れ

20121023_01

ソース管理およびデプロイメントツールについて

私が知っている限りでは、どのサイトコアを開発する会社にもサブバージョンまた、なんらかのデプロイメントツールを使っています。私がこれまでに実際に使ってきたツールを下記のように書き留めます。これ以外にほかのツールも沢山あると思います。このリストの比較はただ私自身が感じたものです。

1. TFS(Team Foundation Server ) これを最初に書くというのは私はTFSに関してそれほど経験がないです。お客さんのプロジェクトで約三ヶ月間使っていましたが、ほかのサブバージョンと比べてそれほど優れていると感じていなかった。自分で設定をしたことがないので何もいえないですが、客先でこのTFSを運営するチームまでいたということは気楽に設定して運営できるものでないと思います。”それはちょっと面倒だなぁ”と思ったこは、コードを編集する際に一々チェックアウトをしないといけない。それに編集はVSで行わないといけない。20,30のプロジェクトを含むソリューションを5分も待って開いてWeb.Configで一行の編集を行うのはあまり好きではない。

2.Teamcity CI(Continuous Integration) これは私のお気に入りのツールです。特に小さいなチームでの共同開発で効率をアップします。セットアップも簡単。私はTeamcityをダウンロードして、Development、QA、Stagingの三つの環境をセットアップするには一日もかからなかった。三つのサーバはすべて社内のサーバだったのでそれぞれのサーバへリモートして設定を簡単に変更ができたこともありますが、一つの環境が設定が出来てその設定を流用することができます。また、GoogleでTeamcityに関してのページが沢山あることも参考になれます。 基本的にソリューションファイルをもとに、それぞれの環境設定ファイルを基づいてコンパイルし、ターゲットの環境へコードをデブロイします。Teamcityを導入するまで、もし誰かがエラーを含むコードをチェックインし、他のメーバーがチェックアウトしたらみんなコンパイルができずいらいらしていました。SVNでその”犯人”を探そうとしたものです。Teamcityは誰からチェックインしてから、設定によってすぐにコンパイルをします。もしコンパイルが失敗すれば、すべてのメーバーにメールなりSMSなり、最新バージョンのコードに問題があるので、チェックアウトしないようにと知らせます。これは案外時間を節約します。それに、それぞれの環境へのデブロイメントをスケジュールで設定し、ネットワークの空いている夜で行ったりすることもできます。

3.Team Development for Sitecore (TDS) Teamcityを使用しサイトコアを開発する際にみんなそれぞれの環境において、データベースを共有することを前提としています。時にはすべての開発メーバーが同じデータベースへのアクセスがない場合があります。例えばデータベースサーバが社内のアクセスのみと設定され、いざ自宅で作業をしようと思ったら、その日に行ったサイトコアの変更は社内で他のメンバーの変更と同期をとれなくなります。サイトコアの変更を書き出して、サイトコアのパーケージを作るか、データベースの同期ツールを走らせるかで同期を取ります。TDSを使えばサイトコアの変更をサブバージョンで管理ができるので、サブバージョンへのアクセスさえあればみんなの変更の同期を取れるわけです。TDSを半年ぐらい使用してきて、私にとってこれはサイトコアの共同開発で一番便利なツールだと思っています。後ほど、私が日々使っている環境設定を書きます。

環境別のデプロイメントについて

基本的にローカル→ディヴェロップメント→品質保証までは社内向けでオートデブロイメントを使用する場合が多い。TDSを使ってすべての変更がサブバージョンで管理されているので、ターゲットの環境でチェックアウトをし、デブロイメントをすればいいです。品質保証からステージングまたブロダクションへのデブロイメントは手動で行う場合がほとんどです。特に品質保証からステージングへは、ブロダクションへのデブロイメントを想定し、できるだけ同じ手順でデブロイメントをします。また、多くの場合はお客さんがすでにステージングにてコンテントを入力されているわけで、それを上書きされないようにとの考慮をしなければなりません。次回はTDSを使ったそれぞれの環境へのデブロイメントを書きたいと思います。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です