4

Phing を使用して自動化しようとしています:

  • 実行中のテスト
  • 各開発者マシンで DB 移行を実行する [dbdeply を使用]
  • 必要に応じて本番環境にデプロイ

プロジェクトにビルド フォルダーを追加し、すべてのビルド構成ファイルと db デルタをそのフォルダーに配置することは理にかなっていると思います。そのすべてを SVN リポジトリにコミットします。そのため、すべての開発者は、svn からチェックアウトするときに更新されたビルド ファイルを取得します。ビルドを実行して、新しい変更で DB を更新できます。

実稼働サーバー上:そこに別のビルド ファイルを追加して、svn で最新のタグ付きバージョンを取得し、CSS および JS 圧縮を実行することを計画していました。

PHPUnderControl を使用して継続的な統合を実装することも計画していたので、各ビルドの結果を追跡し、ビルドが失敗するたびに通知を受け取ることができます。

それで、これはすべて理にかなっていると思いますか、それとも他にもっと良い提案がありますか?

4

1 に答える 1

10

あなたの言うことは理にかなっています：それは私がよく使うものにかなり近いです（時にはantで、時にはphingで、そして時にはいくつかのシェルスクリプトで）。

ディレクトリには、次のbuildようなものがあります。

build/
    testing/
    development/
    staging/
    production/
    common/

build.xml各サブディレクトリに1 つのファイルがbuild.xmlあり、そのディレクトリにある別のファイルをすべて含みますcommon。この考えは、「共通」ファイルにできるだけ多くの「共通」コードを配置し、build.xml環境ごとに固有のファイルを用意することです。できるだけ少ない xml コードを含めます。

importこれは、phingの最後のバージョンに存在するタスクで実行できます（安定バージョンにあるかどうかはわかりません-現在取り組んでいるプロジェクトのために、phingのSVNチェックアウトを使用しています） .


ただし、1 つ言えることは、本番サーバーから本番環境にデプロイしたいということです。むしろ、代わりに：

  • 「開発」サーバー上：
    • SVN からのエクスポート
    • JS/CSS などを圧縮する
    • tar.gz アーカイブを作成する
  • そのアーカイブを本番サーバーにアップロードします
  • 「本番」サーバー上：
    • アップロードされたアーカイブを解凍します
    • ソースの新しいバージョンを使用するようにいくつかのシンボリックリンクを変更します（詳細については、ここで提供した回答を参照してください）
    • DBで何をしなければならないかを更新する

アイデアは次のとおりです。

  • 本番サーバーでできる限り少ないことを行う
    • 万が一何かあった時のために
    • ある日、実稼働サーバーが SVN サーバーにアクセスできなくなった場合に備えて
  • 複数の実稼働サーバーに展開できる物理アーカイブを用意する


ああ、補足として、「本番環境へのデプロイ方法」のドキュメントを段階的に作成する必要があります。

これは、あなたが休暇中で、緊急のバグ修正のために他の誰かが本番環境にデプロイする必要がある場合に非常に役立ちます ;-)

于 2010-01-04T10:47:46.390 に答える