現在、基本的なLAMP構成を実行している開発サーバーがあります。本番サーバーはslicehostです。しかし、code/dbのインスタンスをステージdev>ステージ>本番にプッシュするための最良の方法は何でしょうか。ステージの作成方法と関係がありますか?
サイトをダウンさせずにどうやってそれをしますか?負荷分散を行わなくても可能ですか?
私はこれがいくぶん一般的であることを知っています、私はちょうど正しい方向に向けられることを探しています。
現在、基本的なLAMP構成を実行している開発サーバーがあります。本番サーバーはslicehostです。しかし、code/dbのインスタンスをステージdev>ステージ>本番にプッシュするための最良の方法は何でしょうか。ステージの作成方法と関係がありますか?
サイトをダウンさせずにどうやってそれをしますか?負荷分散を行わなくても可能ですか?
私はこれがいくぶん一般的であることを知っています、私はちょうど正しい方向に向けられることを探しています。
.htaccessを使用して、更新中に自分のIPのみがメインサイトを表示できる「メンテナンスモード」jiffyを作成します。他の誰もが短いメッセージを見ることができるので、数ティックですべてがオンラインに戻るはずです。
その後私は:
それは当然のことですが、ライブサーバーにプッシュする前に、ローカルでできる限り多くのことをテストする必要があります。一部の人々は、2つのライブサーバー(実稼働サーバー上の不可解な名前のサブドメインなど)を使用して、ライブタイム更新のテスト領域として機能します。これにより、メインサイトの実際のダウンタイムを減らすことができます。
更新中にサイトを使用しようとすると、恐ろしいエラーメッセージが表示され、ロックされる可能性があるため、事前にシャットダウンせずにライブサーバーに更新をプッシュしないことが重要であることを強調する必要があります(特にASPNETのバイナリを使用している場合)。ファイル。
各環境のリリースをパッケージ化して準備するスクリプトがある、ランプ用の自動化された「ビルド」スタイルの環境を調べます。
PHPの実際のビルドはないことは認識していますが、自動化をセットアップして構成やセットアップの問題を変更し、実装の準備ができているフォルダーにすべてを保存することができます。
負荷分散/Webファームスタイルの環境がなければ、ダウンタイムを完全になくすことができるとは思いません。しかし、私の本でそれを減らす最も簡単な方法は、一貫したコード準備プロセスを確立し、プロセスを複数回テストすることです。自動化はそこで役立ちます。
実際にファイルをコピーするという行為については、FTPなどの便利なものを使用する以外によくわかりません。たぶん、読み込みメッセージを表示します。繰り返しますが、これはすべてスクリプト化できます。
最後に、PHPは構築されていないため、現在のファイルと変更したファイルの違いを追跡し、それらのファイルのみを移動することが適切に機能する可能性があることに注意してください。ただし、それによって不要な複雑さが追加される場合があります。
これが良いアイデアかどうかはわかりませんが、ソース管理システムからの自動チェックアウトはどうでしょうか? おそらく、開発のブランチがいくつかあります-最先端のテスト、メンテナンス/小さな改善のための開発、および本番コードの本番。開発が安定したら、それをプロダクション ブランチにマージし、プロダクション マシンによって定期的に自動的にチェックアウトされます。
コア構成には、サイトへのアクセスを許可するオプション、またはすべてのユーザーをリダイレクトできるプリセット URL のリストを許可するオプションがあります (そして、適切な http コードで API トラフィックを停止します)。
これらの URL は、何が起こっているかをユーザーに説明する静的な html ファイルへのリンクです。
これが有効になっている場合、すべてのリクエストが HTML ファイルに送信されるため、データベースやファイルへのリクエストはありません。
ファイルをすべての Web サーバーにプッシュする限り、古き良き robocopy がうまくいくことがわかりました。もちろん、私の開発/ステージ/本番環境はすべて同じです。サイトがすぐに戻ることをユーザーに知らせる一時的なページを作成するだけです。
svn と ftp のタスクを備えた apache ant が私の代償です。ANTでdbとかやっている人もいますが、個人的には見たい派です。すべての場所に ftp 用のクリーン プッシュ ビルドを作成すると、それがいかに簡単であるかに驚かれることでしょう。
現在、一連のシェル スクリプトを構成ファイルと共に使用して、変更されたファイルを tar し、それらをクラスター内の各サーバーに scp し、そこにあると untar します。この方法にはもちろん欠点があり、各サーバー メンバーに svn クライアントをインストールし、新しいリリースにタグを付けると、運用サーバーの作業コピーをその新しいタグに切り替える方法を検討しています。もちろん、現在はメンテナンス時間中にリリースを行っているため、ユーザーに対して特別なことをする必要はありません (とにかくメンテナンス ページが表示されます)。