12

Web開発でオフライン開発からライブWebサーバーへのデプロイを正しく実行する方法がよくわかりません。私は主に直感に頼っていますが、これは多かれ少なかれ今まで行ってきたことです。Python または php で Web アプリケーションを持っていて、それをライブ Web サーバーでホストしています。ソースがsvnの下にあるオフライン開発バージョンを使用しています。

今、オフライン バージョンを開発しているので、svn へのコミットを実行します。解放の時が来たら、次のいずれかを実行できます。

  1. オフライン サーバーからライブ Web サーバーの一時ディレクトリにコードをコピーし、古いコードベースを新しいコードベースと交換します (たとえば、リンクを使用)、または...
  2. ライブ Web サーバーをチェックアウト svn で動作させ、svn update を実行するだけです。

通常は 2 番目の手順を実行しますが、ライブ展開の前にデータベースをアップグレードする必要がある場合は、通常、アップグレード SQL スクリプトを作成し、最初にライブ データベースで実行してからチェックアウトします。

このタスクのベスト プラクティスは何ですか?

4

6 に答える 6

10

チェックアウトの代わりに SVN エクスポートを利用することをお勧めします。この方法では、SVN ファイルを外部に公開することはありません。また、一般に、よりクリーンなフォルダー構造が作成されます。

ステージと本番の間でファイルを移動するときに、以前に rsync を利用しました。

私の典型的な展開は次のように進みます。

  • バックアップ本番サイト
  • バックアップからステージ サーバーへの復元
  • すべての外部 IP アドレスからサーバーをロックダウンする
  • リポジトリから一時フォルダーにコードをエクスポートします (必要に応じて、小さな変更のために 2 つのフォルダーを比較します)。
  • temp フォルダーからステージ サーバー フォルダーへの rsyc ファイル
  • 変更されていると予想されるファイルのみが実際に変更されていることを検証します。
  • SQL スクリプトを DB に適用する
  • アップグレードをテストする
  • ウェブサーバーのロックを解除

ここで、本番環境にデプロイするために、これらの手順を早送りで再生します。スクリプトを使用すると、はるかに簡単になります。

于 2009-08-11T19:03:38.953 に答える
4

これらすべてを自動化するには、いくつかの展開スクリプトを検討する必要があります。間違いを防ぐのに役立ちます。SQL アップグレード スクリプトは日常的なものですが、実際のデータベースで実行する前に、常にライブ データベースのコピーでテストする必要があります。

あなたが考えているのはステージングサーバーです。ローカルで変更を行ってから、ステージング サーバーに svn チェックアウトし、そこでもアップグレード スクリプトを実行します。ステージング サーバーで受け入れテストを行います。すべてがうまくいったら、everhting をライブ サーバーにデプロイします。これは、いくつかのスクリプトを実行するのと同じくらい簡単です。つまり、update-staging.pl と update-prod.pl です。

データベースにバージョン テーブルを追加することで、SQL スクリプトの自動化を容易にすることができます。更新スクリプトを作成するときはいつでも、バージョンでタグ付けします。その後、展開スクリプトは更新スクリプトのバージョンとデータベースのバージョンを確認し、必要に応じて更新を適用できます。これにより、バックアップからの復元も実行可能になります。変更を加えてからバックアップに復元する場合は、アップグレード スクリプトを実行するだけで、db が現在のバージョンに更新されます。

于 2009-08-11T19:02:16.273 に答える
3

Capistranoを使用して、デプロイ プロセスのスクリプト作成と自動化を行っています。cap deployローカル ワークステーションから入ったときに何が起こるかの概要を次に示します。

カピストラーノでしょう。. .

  1. ウェブサーバーのタイムスタンプ付きディレクトリ (例: /var/http/mywebsite.com/releases/20090715014527) にあるソースの最新バージョンをチェックアウトし、必要に応じてローカル ワークステーションでパスワードを要求します。

  2. 前処理スクリプトの実行 (データベース スキーマの更新など)

  3. サイトをライブ ディレクトリにソフト リンクします。

    ln -sf /var/http/mywebsite.com/releases/20090715014527 /var/http/mywebsite.com/current

  4. 後処理スクリプトを実行します (たとえば、apache などを再起動する必要があるかもしれません)。

途中で問題が発生した場合、Capistrano は以前の作業リリースにロールバックします。

Capistrano は Ruby で書かれていますが、任意の言語/フレームワークで Web アプリケーションをデプロイできます。アイデアについては、チュートリアルの「レール以外のアプリのデプロイ」セクションを参照してください。railsless-deployは、Capistrano を使用して PHP および Python アプリのデプロイを管理する場合に特に便利です。

于 2009-08-11T19:07:32.987 に答える
1

理論的には、svn を Web サーバーの新しい領域にエクスポートします。次に、Web サーバーを再構成して新しい領域を使用し、再起動します。

于 2009-08-11T19:01:42.983 に答える
1

小規模な php ベースのシステムの場合、私たちが行っていたことは次のとおりです。

コードの変更には、ローカル (開発) システムとリモート (qa/prod/whatever) システムを比較する eclipse から実行される ant スクリプトを使用してから、変更されたすべてのファイルを圧縮し、zip をリモート システムに scp して解凍します。ターゲット。もちろん、自動バックアップなどがあります。これが興味深い場合は、数日中にサンプル スクリプトを投稿できます。

SQL の変更については、変更ごとにスクリプトを維持し (通常はバグ トラッカーで)、ターゲット システムで各変更を手動で実行します。

大規模なシステムでは、より堅牢なものを実際に使用する必要があります。

prodシステムがsvnから直接プルしている場合、適切にテストされていない可能性のある変更をデプロイしていることに注意してください（何かをコミットするのを忘れたり、ローカルシステムをテストしたりすると、prodですべてが壊れる可能性があります...）

于 2009-08-11T19:08:04.203 に答える
1

最初のオプションをお勧めします。コードのバージョンを配置し、リンクを変更してそれらを切り替えることができる構造がある場合は、svn チェックアウトだけの場合よりもロールバックがはるかに簡単です。svn を元に戻すには、以前のバージョンとマージする必要があります。

于 2009-08-11T19:09:17.570 に答える