22

アプリケーションを開発から本番に正しくデプロイする方法と、複数のサイト構成に対処する方法。私の開発はすべて var/svn/myapp/trunk にある svn を介して行われ、実際の製品コードは /var/www/myapp にあります。

ローカル マシンの最新コードを「myapp_latest_svn」というディレクトリにチェックアウトします。H_PATH = ' http://myapp.com ' & db_host、db_user_name、および db_password の db config 設定を含むメインの settings.php に、サイトと場所固有のコードがあります。 /myapp.com は単なる Apache エイリアスです) & 本番 (ライブ サイトは myapp.com で実行されます) サーバー上。

また、.htaccess ファイルは運用サーバーのものとは異なります。つまり、開発と本番の間には多くの違いがあります。

私はすべての作業を SVN に保存しています。毎朝、最新のコードをローカルの svn リポジトリに更新する SVN Update を使用しています。ライブの準備ができたら、svn Commit でリリースをビルドします。

次に、リリースでは、適切な開発ファイルをすべて、対応する製品に変更することを忘れないでください。ここで、サイト固有の変更を反映するために、プロダクションの settings.php と .htaccess を手動で編集する必要がありました。

私は、バージョン管理と、エラーが発生しやすく、悪い習慣であるファイルの手動編集を必要とせずに、開発から本番に移行する自動化された方法を探しています。

1 つの方法は、ファイルの本番バージョンを読み取り専用 (0444) にすることです。そうすれば、svn エクスポートを行うときに、ファイルの開発バージョンによって上書きされることはなく、開発から運用に移動するたびにファイルを編集することを心配する必要はありません。しかし、それは継続的インテグレーションのようなことを行うには悪い方法です。

また、settings.php の複数のコピー (localhost、beta、および prod 用に 1 つ) を作成します。次に、svn からエクスポートするシェル スクリプトを使用し、エクスポートが完了すると、デプロイ先の場所に応じて、settings.php を正しい settings.php に置き換えます。そうすれば、すべてが自動化されます。しかし、これも不毛な方法です。

最後の方法は

if( eregi ("myapp.com$", $_SERVER['HTTP_HOST']) ){

    define('H_PATH', 'myapp.com');

} else {

    define('H_PATH', 'localmyapp.com');

}

これは、settings.php に関する限り問題ありません。しかし、.htaccess については、.htaccess で上記のようにチェックすることはできません。

設定を変更する必要があるサイトを展開するたびに、やりたくないことがあります。

私のDBスキーマはバージョン管理されていないので、dbは問題ではなく、settings.phpと.htaccessだけです。

また、サイト固有のディレクトリ (/log、/cache、/assets、/downloads) もあるため、svn に一部のディレクトリを更新しないように指示するにはどうすればよいですか。また、上記のファイルに対しても、apache ( www_data) 書き込みアクセスをそのまま保持する必要があります。

最後に、エクスポート時に空のトランク ディレクトリと .svn ファイルを運用サーバーにコピーしたくありません。

Phing またはシェル スクリプトを使用して、svn から運用サーバーに構築するときにこれらの問題を引き起こさずに統合するにはどうすればよいですか。

これは、世の中に出回っている多くの志望アプリ開発者にとって役立つ可能性があります。

前もって感謝します、

稼働時間

4

4 に答える 4

13

展開の問題については、 Capistranoを参照することをお勧めします。私はこれを使用して PHP システムをデプロイしましたが、説明したすべてのことを実行します (デプロイ レシピで少しスクリプトを使用します)。

リモートリポジトリに構成ファイルを保持していません-devでチェックアウトするときに、一度追加してから無視できるので、誤ってチェックすることはありません。デプロイに関しては、設定ファイルをデプロイされたバージョンに書き込むように私の cap deploy レシピをセットアップします。このようにして、重要なものをデプロイしたり見逃したりすることを心配する必要はありません。

Cap はまた、アップロードされたアセットを処理し (ディレクトリをシンボリック リンクして、デプロイごとに所定の位置に保持します)、デプロイ時にすべてのアセット ファイルとデータベースを Amazon S3 に自動的にバックアップします。かなり気の利いた、え?

于 2009-07-17T13:17:25.440 に答える
8

config と呼ばれる Phing タスクがあり、コードを構成する環境を尋ねられます。タスクは、ローカル、開発、ステージング、生産など、いくつかの可能な値を受け入れます。

環境を指定すると、適切な .properties ファイル (つまり、local.properties、production.properties など) が読み込まれます。

次のステップが鍵となります。構成ファイルと htaccess ファイルのTEMPLATESを保存し、それらに対して filterChain replaceTokens タスクを実行して、それらのトークンがプロパティ ファイルの値に置き換えられるようにします。

次のファイルを作成します。

共通/ビルド/テンプレート/settings.tpl

define('H_PATH','##H_PATH##');
define('ENVIRONMENT', '##ENVIRONMENT##');

ビルド/テンプレート/htaccess.tpl

http://##H_PATH##

ビルド/プロパティ/local.properties

site.H_PATH = localmyapp.com
site.ENVIRONMENT = local

ビルド/プロパティ/プロダクション.プロパティ

site.H_PATH = myapp.com
site.ENVIRONMENT = production

共通/ビルド/build.xml

<target name="config">
   <input propertyname="env" validargs="local,production">Enter environment name:</input>
   <property file="build/properties/${environment}.properties" />
   <copy file="build/templates/settings.tpl" 
     tofile="config/settings.php" overwrite="true"> 
     <filterchain>
      <replacetokens begintoken="##" endtoken="##">       
          <token key="H_PATH" value="${site.H_PATH}" />
          <token key="ENVIRONMENT" value="${site.ENVIRONMENT}" />
      </replacetokens>          
     </filterchain>
   </copy>      
   <copy file="build/templates/htaccess.tpl" 
     tofile="public/.htaccess" overwrite="true">    
     <filterchain>
      <replacetokens begintoken="##" endtoken="##">       
          <token key="H_PATH" value="${site.H_PATH}" />                                                           
      </replacetokens>          
     </filterchain>
   </copy>              
   <echo msg="Configured settings.php and .htaccess for ${environment}" />              
</target>                               

ローカルで実行するようにサイトを構成する場合は、次のように入力します。

phing config

次のように入力します。

local

リターンを押します。それでおしまい!これの大きな利点の 1 つは、コードにif/else ステートメントが不要になることです。さらに、$_SERVER 変数に依存しないため、コマンドラインで問題なく動作します。

于 2010-06-10T21:45:00.083 に答える
2

設定ファイルと .haccess を SVN にファイル名を変更して保存します (例: settings.php.example と .htaccess.example)。このようにして、新しいリリースを作成するときに、上書きについて心配する必要はありません。

于 2009-07-17T13:18:03.973 に答える