ウェブサイトの作成/展開/管理方法を学ぶにはどうすればよいですか？

Question

私はC＃.NETでデスクトップアプリケーションを書くのに慣れています。どこにバージョン管理下にある素敵な小さなソリューションフォルダがありますか？だからいつでも、どんなコンピュータであれ、私のソフトウェアのどのバージョンをコンパイルしたいのかチェックして、私のプログラムの作業コピーを持っています。

私は、ファイルとデータがより分散しているウェブサイトの開発を検討しています。私はASP.NETを使用していますが、実際は私の質問はより一般的で、どのWebサイトのフレームワークにも適用できます。

私は自分のウェブサイト、バージョン管理サーバー、そしてユーザーが見る実際のライブウェブサイトの開発の間の適切なワークフローを理解しようとしています。明らかに、これはウェブサイトのタイプと規模に応じて大きく変わることがありますが、私はかなり単純なサイトだけを考えています。私はちょうどこのもので始めることになっています。

下の図は私の現在のアイデアです。サイトのすべてのソースファイルは、ローカルコンピュータにチェックアウトするSubversionサーバーに保存されます。私のローカルコンピュータには、サイトの開発に使用するローカルデータベースがあります。次に、別のテストデータベースを指す、ホステッドサーバー上のテストバージョンに公開します。このテストデータベースは、定期的にライブデータベースのコピーに置き換えられます。

すべてうまくいけば、ライブデータを指し示すサイトのベータ版に公開します。ユーザーはベータ版をチェックアウトしてフィードバックを提供することができます。最後に問題がなければ、ライブサイトのソースファイルが更新されます。

これは理にかなっていますか？これがどのように改善できるかについて誰かからコメントがありますか？このような種類のワークフローを開発する際に、良い本やオンラインチュートリアルはありますか？

また、実際にはわからないことの1つは、データベースの実際のスキーマの変更を管理する方法です。私は、ホスト上のTestとLiveのデータベースを更新するために使用できるSQLスクリプトを生成することができる各バージョンについて説明します。しかし、すべてのバージョンのすべての更新SQLスクリプトを目的のバージョンまで実行しなくても、自分のサイトの任意のバージョンの新しいデータベースを簡単にセットアップできるようにしたいと思います。 NHibernateやSubsonicのようなORMを使用する最良のソリューションは私のコードから直接私のデータベーススキーマを生成することができますか？

Answer 1

私は現在、これに非常に類似したワークフローを使用しています。それは完璧ではないが、大部分はうまくいく。重要な部品が分かっているようです。

私が働いているところには、強力なWebサーバーがあります。私たちのSubversionリポジトリもこのサーバ上に存在します。 LAMPの開発者としては、現地のLinuxマシン（またはVM）上で、ローカルの作業コピー上で動作するローカルのMySQLデータベースを使用して自分自身の開発をすべて行います。

私は、アプリケーションの2つの主要ブランチ、つまりDevブランチ（トランク）とLiveブランチ（現行のプロダクションバージョンを反映）を維持しています。ライブ（または製造）、ベータ、およびデベロッパー：私たちはソフトウェアの3つの別々のインスタンスを維持するWebサーバー上

/repo/trunk/  [My current active development version] 
/repo/archive/  [All other versions not in active development live here] 
/repo/archive/2010.12/ [This happens to be the current production version] 

：私のレポはこのようになります。以下は、これらのバージョンの使用方法を説明するものです。

• Dev - 常に、開発バージョンを `/ repo/trunk 'に指定します。非vesioned設定ファイルを使用して開発データベースを指定します。しかし、ここで物理的な開発は行われません。代わりに作業用のコピーがトランクを指すローカルマシンで作業し、ローカルマシン上ですべての開発テストを行います。しかし、複数の開発者からのコミットが数回行われた後は、Devサーバーでテストを行い、適切な軌道に乗っていることを確認し、他の人の変更を破っている人はいません。

• ライブ - 常に最新の安定したプロダクションバージョンを示します。この場合は、/repo/archive/2010.12/を指しています。このバージョンは世界中からアクセス可能です。

• ベータ版 - ほとんどの場合、ベータ版はLive上のwhatsのミラーになり、私たちのリポジトリ（/repo/archive/2010.12）の同じプロダクションバージョンを指します。 Liveでバグ修正が必要なときはいつでも、ここで作成してテストした後、&を最新版にアップデートします。 （必要に応じて、我々はまた、トランクにマージし。）

トランク内のバージョンが完了し、テストのための準備とみなされた場合、私は今後の新しいリリース（すなわち2011.01）のためのリポジトリに新しいアーカイブのブランチを作成します既存のプロダクションブランチを作成してください。私はTrunkのバージョンを新しいブランチにマージしてコミットするので、Devに現在あるものを反映するバージョンがあります。もちろん、今度はBeta上でこの新しいアーカイブ版をテストしながら、次のリリースの開発を進めることができます。ベータテストが完了すると、修正内容をコミットし、Liveを新しいバージョン（/repo/archive/2011.01）に切り替えます。

これで、データベースのマージがややこしいことが分かりました。私たちはMySQLを使用しています。私の知る限り、MySQLのバージョン管理システムはありません。したがって、各マイグレーション（VMからDevへ、DevからBeta、Beta to Liveへ）では、まず現在のデータベースのバックアップを作成し、必要な変更を行います。個人的に私はSQLYogの商用バージョンを使用して、データベースのスキーマ（超便利）を同期させることができます。