web-dev-qa-db-ja.com

一貫して更新されるWebサイトのための開発サーバーと本番サーバーのワークフロー

私たちは3人の開発者、1人のシステム管理者、そして1人のウェブサイト(フォーラム)で主に仕事をし、フォーラムの機能を一貫して開発するために(フォーラムで作業している他のプロジェクトもあります)います。システム管理者が最近参加したため、1台のサーバーの管理されたホスティングを削除し、2台の管理されていないサーバー(1つはテスト用、もう1つは運用用)を貸し出すことにしました。

古いサーバーでは、Gitを仲介者として使用し、統一されていない開発者チームからサーバーに更新を競合することなく更新をプッシュしました。他の開発者の更新をプルします。独自の更新をプッシュします。何かが壊れたら元に戻します。

現在2つのサーバーがあるので、更新を開発サーバーにプッシュし、どういうわけかそれを更新を運用サーバーにプッシュします。

開発者->開発サーバー(ベア)->本番サーバー

開発サーバーのリポジトリーと、実動サーバー(Webサーバー)のWebサイトの作業ツリーを保持します。開発サーバーから本番環境にプッシュせずにこれを行う効率的な方法はありますか?一般に、2つのサーバーに適したワークフローはありますか?

追伸開発チームは高校生のティーンエイジャーと、営利企業向けのチームで開発したことのない大学生で構成されています。

6
Gio Borje

おそらく最も簡単な方法は次のとおりです。

  • 開発サーバーでGitを使用し、現在のマスターに対応するバージョンを実行している(リポジトリからのチェックアウト)。誰もが変更をこのバージョンにマージでき、それが壊れると、開発サーバーが壊れ、アクションが必要であることは明らかです。
  • 本番サーバーは、開発サーバーからのリモートチェックアウトです。開発サーバーが安定した時点で(または新しいバージョンをリリースする準備ができて)いるときはいつでも、本番サーバーにログインしてgit pullを実行するだけです。

何か問題が発生した場合、単一のgit revertコマンドで本番サーバーを元に戻すことができるため、これは簡単です。

さらに、本番サーバーにフックを作成して、定義した内容に基づいて変更を自動的にプルすることで、これを自動化できます。特定の状況でこれがどのように機能するかは、実際のリリースプロセスがどのように機能するかによって異なります。個人的には、手動で更新するだけです(実際の運用サーバーにログインする必要がないため、簡単なスクリプトを作成することもできます)。これは、コマンドが1つだけなので、運用サーバーを更新するときは常にそこにいたいからです。 )

また、本番サーバーをセキュリティで保護して、リポジトリファイルがWebサーバーから提供されないようにしてください。これは簡単なことであり、システム管理者がこれを構成できます。

3
Deckard