2

Web サイト開発用にいくつかのサーバーをセットアップしています。かなり標準的な方法で整理したいと思います。それぞれに固有のコードが少しずつある比較的小規模な Web サイトを開発するために、サーバーをどのように編成しますか?

私が懸念しているいくつかの詳細には、次のものが含まれます（ただし、これらに限定されません）：

  1. 開発プロセスに関して、どのようなサーバーが存在しますか? 彼らの目的は何ですか？

  2. マスター ソース リポジトリはどこにありますか?

  3. 開発作業はどこで行われますか?

  4. テストはどこで行われますか?

4

3 に答える 3

1

1）開発プロセスに関してどのような別個のサーバーが存在しますか？彼らの目的は何ですか？

私の経験では、重要な唯一の概念/アイデアは、すべての環境（サーバー=>開発、ステージング、本番）は、OS、Webサーバーのバージョン、サービスパック、パッチ、ホットフィックスに関して、まったく同じではないにしても、同じでなければならないということです。 、など。現在、少なくとも3つ（またはそれ以上）の異なる環境を用意することは可能かもしれないし、不可能かもしれませんが、これは私の経験からの標準である傾向があります。ハードウェアに関しては、それらが非常に類似または同一である限り、将来的に問題が発生することはありません。

2）マスターソースリポジトリはどこにありますか？

インターネットアクセスから隔離され、厳重に保護されています。アクセスを取得しようとする望ましくない試みからファイアウォールを保護するためのファイアウォールルールがたくさんあります。社内の開発者のみがリポジトリにアクセスできる必要があります。

3）開発作業はどこで行われますか？

大規模なプロジェクトや組織では、開発はプログラマーのコンピューター上でローカルに行われるか、ソースリポジトリー（SVN、CVS、VSSなど）を使用してローカルで行われる傾向があります。

4）テストはどこで行われますか？

「開発」環境でテストする人もいれば、「ステージング」でテストする人もいます。これは私にとってもう少し理にかなっています。2つのうちの1つを選び、それを使い続けます。個人的には、ステージングは​​、開発者が開発に変更を加えている場合にバージョンの変更を回避するためにテストする場所だと思います。

それぞれが少しずつ固有のコードを持つ比較的小さなWebサイトを開発するために、サーバーをどのように編成しますか？

基本的に、Webショップは環境を次のように編成します：development => dev、staging => stage、production=>prod。開発者は自分のマシンでローカルに作業し、追加/変更が完了すると、変更をソースリポジトリにコミットします。特定のショップはCI（継続的インテグレーション）と呼ばれるものを実行するため、開発者がコミットするたびに、CIサーバーは自動的にサイトに再構築されます。これは、開発者/テスターが開発者の変更から何かが壊れたかどうかを確認するのに役立ちます。

通常、これらの変更は、すべての開発者が作業できるように開発環境に公開されます。開発者が特定のマイルストーン/チェックポイントに到達し、テストを開始したい場合、開発者が開発で作業を続けることができる間、テスターが打ちのめすために、サイトのバージョンをステージング環境に「プロモート」します。

ステージングのすべてに満足したら、ステージングのバージョンをprodにプロモートします。変更は一方向にのみ流れる必要があります：dev->stage->prod。本番環境に変更を加える場合は、開発から開始し、ステージングでテストしてから、本番環境にプロモートします。それは苦痛ですが、物事の一貫性を保ち、多くの頭痛を防ぎます。多くの企業が本番環境に変更を加えただけで、数か月/数年後には、プロトコルに従うだけで多くの苦痛を軽減できたのに、環境の同期に問題が発生していることに驚かれることでしょう。

動的ページやデータベース呼び出しを超えて、単純または複雑ではないもののように作業を「小さい」と呼んでいる場合は、3つの環境を試してみてください。ただし、おそらく2つの環境を「回避」することができます（ステージングおよび生産）。自分のコンピュータをいわゆる開発環境にすることができます。

于 2009-09-25T21:40:53.733 に答える
1

開発プロセスに関して、どのようなサーバーが存在しますか? 彼らの目的は何ですか？

  • SVN、Git、CVS などのSCM サーバー- 中央ソース リポジトリ、通常は内部アクセスのみ。
  • CI サーバー ( CruiseControl、Hudson など) - 自動化されたビルド/テスト用の継続的統合サーバー。
  • Samba などのFileServer、共有 Windows ディレクトリ - ビルドされた成果物を保存し、開発チーム間でダウンロードを共有するため
  • テスト/ステージング/本番サーバー - 実際のアプリケーションを実行するためのハード/ソフトウェアと同じ仕様で構築されたマシン。

マスター ソース リポジトリはどこにありますか?

通常は内部アクセスのみで、このマシンを別の目的 (CI など) と共有できます。

開発作業はどこで行われますか?

各開発者では、ローカル マシンが最適であり、SCM と CI を介して変更を統合します。

テストはどこで行われますか?

通常、テスト用に取っておいたサーバー上。通常、一連の環境があり、ビルドはテストに合格するたびに各段階で昇格されます。

  • テスト マシン - ビルドをチェックアウトするため、通常は開発者のマシンのセットアップをミラーリングします。
  • ステージング マシン - 基本的なテストに合格したビルドの場合、このサーバーはライブ プロダクション システムのミラーのようなものになります。
  • Pre-live - サーバーが完全に稼働する前にテストするためにビジネス ユーザーに提供されるオプションのサーバー。
  • ライブ/プロダクション - ビルドは、テスターとビジネスによって受け入れられると、このサーバーに昇格されます。
于 2009-09-25T21:26:31.457 に答える
1

職場では、同じサイトで 2 人が作業することがあるため、次のようになります。

  • すべてのサイトはソース管理 (Microsoft Source Safe) にあり、ほとんどの場合、自分のコンピューターでローカル コピーを使用してテストしています。幸いなことに、Visual Studio 2008 では、組み込みの Web サーバーを使用してこれを簡単に行うことができます。

  • 複数のユーザーで社内でテストしたい場合は、社内開発サーバーにデプロイします。(本番環境にデプロイする前に、常にこれを行います。)

  • 本番に移行する前に外部のコンサルタントにサイトをレビューしてもらいたい場合は、本番サーバーにデプロイしますが、ステージング.yourdomain.com など、ライブ サイトから分離する特別なホスト ヘッダーを使用します (このステップはしばしばスキップされます)。

  • 最後のステップとして、データ センターの運用サーバーに展開します。

私は何年にもわたってこれのバリエーションを試してきました。しかし、この方法で必要なのは、2 台の物理サーバーと開発者のワークステーションだけです。それでも、それは私たちにとって信頼できるプロセスであるほど十分に構造化されています.

于 2009-09-25T21:27:26.587 に答える