Webサーバーとワークフロー

サーバー、開発サーバー、ステージングサーバー、および運用サーバーのテスト

多くの人とページを管理している大規模なサイトで作業することで、さまざまなワークフローがWebデザインペーパープロトタイプから実際のページをインターネットに生かすことができます。 複雑なサイトのワークフローには、多くの個別のWebサーバーとサーバーの場所を含めることができます。 これらのサーバーはそれぞれ異なる目的を持っています。 この記事では、複雑なWebサイトの一般的なサーバーのいくつかとその使用方法について説明します。

プロダクションWebサーバ

これは、ほとんどのWebデザイナーがよく知っているWebサーバーのタイプです。 プロダクションサーバーとは、プロダクションの準備ができているWebページとコンテンツをホストするWebサーバーです。 つまり、プロダクションWebサーバーのコンテンツはインターネットに公開されているか、インターネットに配信される準備ができています。

小規模な会社では、プロダクションサーバーはすべてのWebページが存在する場所です。 設計者と開発者は、ローカルマシン上か、ライブサーバー上の隠れた場所やパスワードで保護された場所でページをテストします。 ページをライブで使用する準備ができたら、ローカルのハードドライブからFTPを使用するか、隠しディレクトリからライブディレクトリにファイルを移動して、プロダクションサーバー上の場所に移動するだけです。

ワークフローは次のようになります。

  1. デザイナーがローカルマシン上にサイトを構築する
  2. ローカルマシン上のDesignerテストサイト
  3. デザイナーは、より多くのテストのために、本番サーバーの隠しディレクトリにサイトをアップロードします
  4. 承認されたデザインは、ウェブサイトのライブ(隠されていない)エリアに移動されます

小規模なサイトでは、これは完全に容認できるワークフローです。 実際、小さなサイトでは、index2.htmlなどの名前のファイルや/ newなどの内部ディレクトリを調べることで、しばしば見ることができます。 そのようなパスワードで保護されていない領域が検索エンジンで見つかることを覚えている限り、プロダクションサーバにアップデートを投稿することは、余分なサーバを必要とせずに、ライブ環境で新しいデザインをテストする良い方法です。

テストサーバまたはQAサーバ

テストサーバーは、顧客(および競合他者)には見えないWebサーバー上の新しいページやデザインをテストする方法を提供するため、Webサイトのワークフローに役立ちます。 テストサーバーはライブサイトと同一に設定され、通常、何らかのバージョンコントロールをセットアップして、変更が記録されていることを確認します。 ほとんどのテストサーバーは社内のファイアウォールの背後に設定されているため、従業員だけがそれらを見ることができます。 しかし、ファイアウォールの外にパスワード保護を設定することもできます

テストサーバーは、多くの動的コンテンツ、プログラミング、またはCGIを使用するサイトに非常に便利です。 これは、ローカルコンピュータにサーバーとデータベースを設定していない限り、これらのページをオフラインでテストすることは非常に難しいためです。 テストサーバーを使用すると、変更内容をサイトに送信し、プログラム、スクリプト、またはデータベースが意図したとおりに機能するかどうかを確認できます。

テストサーバーを持つ企業は、通常、次のようにワークフローに追加します。

  1. Desginerはサイトをローカルで構築し、上記と同様にローカルでテストします
  2. デザイナーまたは開発者がテスト・サーバーに変更をアップロードして、動的要素(PHPや他のサーバー・サイド・スクリプト、CGI、Ajax)をテストします。
  3. 承認されたデザインは本番サーバーに移動されます。

開発サーバー

開発サーバーは、複雑なeコマースサイトやWebアプリケーションなど、大きな開発コンポーネントを持つサイトに非常に便利です。 開発サーバーは、Web開発チームがWebサイトのバックエンドのプログラミングに取り組むために使用されます。 ほとんどの場合、複数のチームメンバーが使用できるバージョンまたはソースコード管理システムがあり、新しいスクリプトやプログラムをテストするためのサーバー環境を提供します。

ほとんどの開発者が直接サーバー上で作業するため、開発サーバーはテストサーバーとは異なります。 このサーバーの目的は、通常、プログラムで新しいことを試みることです。 テストは開発サーバー上で行われますが、コードを特定の基準に照らしてテストするのではなく、機能させることを目的としています。 これにより、開発者はどのように見えるのか心配することなくウェブサイトのナットとボルトを心配することができます。

企業に開発サーバーがある場合、設計と開発に携わるチームが別々になることがよくあります。 このような場合、テストサーバーは、設計が開発されたスクリプトで満たされる場所であるため、さらに重要になります。 開発サーバーのワークフローは、通常、次のとおりです。

  1. 設計者はローカルマシン上の設計作業を行います
    1. 同時に、開発者は開発サーバー上のスクリプトとプログラムで作業します
  2. コードとデザインはテストのためにテストサーバーに統合されます
  3. 承認された設計とコードは実動サーバーに移動されます。

コンテンツサーバー

コンテンツの多いサイトの場合、 コンテンツ管理システムを収容する別のサーバーが存在する可能性があります。 これにより、コンテンツ開発者は、一緒に構築されているデザインやプログラムの影響を受けることなく、コンテンツを追加することができます。 コンテンツサーバーは、ライターやグラフィックアーティスト以外の開発サーバーによく似ています。

ステージングサーバー

ステージングサーバーは、ウェブサイトが運用される前の最後の停止場所となることがよくあります。 ステージングサーバーは、できるだけプロダクションと同じように設計されています。 したがって、ハードウェアとソフトウェアは、ステージングとプロダクションのWebサーバー用にしばしばミラーリングされます。 多くの企業ではステージングサーバーとしてテストサーバーを使用していますが、サイトが非常に複雑な場合、ステージングサーバーはデザイナーと開発者に提案された変更が設計どおりに機能しているかどうかを検証し、混乱の原因となるテストサーバーで他のテストを実行する必要はありません。

ステージングサーバーは、しばしばウェブサイトの変更のための「待機期間」の一形態として使用される。 一部の企業では、ステージングサーバーは自動的にそこに投稿された新しいコンテンツを展開し、他の企業は管理、マーケティング、影響を受けるグループなどのWebチーム外の人々の最終的なテストおよび承認領域としてサーバーを使用します。 ステージングサーバーは、通常次のようにワークフローに組み込まれます。

  1. 設計者は、ローカルマシンまたはテストサーバー上の設計作業を行います
    1. コンテンツ作成者がCMSにコンテンツを作成する
    2. 開発者は開発サーバーにコード書く
  2. テスト用のテストサーバーにデザインとコードがまとめられています(コンテンツはここに含まれていますが、設計ワークフローの外でCMSで検証されることがあります)
  3. コンテンツはステージングサーバー上のデザインとコードに追加されます
  4. 最終承認を受け取り、サイト全体を運用サーバーにプッシュします

あなたの会社のワークフローは異なる場合があります

私が学んだことの1つは、ある企業のワークフローが他の企業のワークフローとはまったく異なることです。 私は、Emacsとviを使ってプロダクションサーバー上でHTMLを直接書く Webサイトを構築しました。私が作業しているページの小さな部分だけにアクセスできなかったWebサイトを構築しました。 さまざまなサーバーの目的を理解することで、設計と開発作業をより効果的に行うことができます。