私はウェブサイトを展開するいくつかの方法を知っています:
- FTP
- ソース管理からエクスポート
- ソース管理チェックアウトに基づいてサイトを構築する
それぞれの良い面と悪い面があります。新しいサイトまたはサイトの変更を展開する最も効果的な方法についてコンセンサスはありますか?
私はウェブサイトを展開するいくつかの方法を知っています:
それぞれの良い面と悪い面があります。新しいサイトまたはサイトの変更を展開する最も効果的な方法についてコンセンサスはありますか?
回答:
Stack Overflow(およびJoel Testのポイント2を満たしています)で私たちにとって最も効果的だったのは、継続的な統合ソリューションであり、本番サイトのワンクリックビルドと、新しいコードチェックイン時に開発者層の自動ビルドが可能です。 。
私たちは、エキサイティングな名前でCruiseControlの.NETフレーバーを使用しています。CruiseControl.NET :)
- さまざまなソース管理システムとの統合
- NAntやVisual Studioなどの他の外部ツールとの統合
- 1台のサーバーで複数のプロジェクトを構築できます
- リモート管理とレポート
私たちはこのオープンソースソフトウェアに非常に満足しており、ビルドプロセスを合理化したいすべてのチームにお勧めします。
私は自動化された繰り返し可能なデプロイを好みます。ソース管理タグから始めて、デプロイした内容を正確に把握し、いつでも再デプロイできるようにすることをお勧めします。次に、スクリプトを使用して、それをサーバー、カピストラーノに沿ったもの、または自家製のbashスクリプトなどにプッシュします。
コンパイルされたコードを使用するサイトの場合、テストサーバーが運用サーバーと一致する場合は、コードを1回コンパイルし、テストされたら同じコンパイルバージョンを運用環境にプッシュするのがおそらく最善です。
カスタムスクリプトを使用しています。静的な(HTMLベースの)Webサイトの場合、新しいバージョンとインストールされたバージョンの2つのディレクトリを使用し、スクリプトdiff
は新しいバージョンとインストールされたバージョンで再帰的に実行し、変更されたファイルのみをアップロードします。
デプロイには、カスタマイズされたフックをいくつか使用してgitを使用します。これには、dev / test / beta / productionサイトに対して複数のブランチを実行し、CIを実行できるという利点もあります。緊急パッチの場合、gitは常に特定のコミットをあるブランチから次のブランチにチェリーピックすることを許可します。