2つのクラウドサーバ、1つのdev、1つのprod;良い展開プロセスは何ですか？

Question

現在、ウェブアプリケーションにLAMPスタックを使用しています。私のdevとprodは同じクラウドインスタンスにあります。今、私は新しいインスタンスを取得しており、dev/test環境を新しいインスタンスに移動してprod環境から分離したいと考えています。

これは、私のvhost.confが指し示すprodディレクトリへのSVNエクスポートを行うシンプルなPhingスクリプトでした。どのように環境を分離して良いビルドプロセスを作るのですか？ devのサーバーにSVNリポジトリを転送して、sshの+のsvnプッシュをしているの

思考は（これはPhingので可能でしょうか？）

セットアップのこのタイプのための最良の/一般的な方法は何ですか？

詳細：

私は現在、MVCフレームワークのためにCodeIgniterのを使用していPhingのを自動化するためには、ローカルホストの展開のために構築します。 Webアプリケーションは、Javaで書かれたいくつかのCRONスクリプトでもサポートされています。

更新：

のPhing +ジェンキンスを使用して終了。これまではうまくいっています！

Answer 1

Phingを使用して、説明したのと同様の展開を行います。私たちはまた、Symfonyフレームワークをプロジェクトに使用しています（これはそれほど重要ではありませんが、Symfonyは異なる環境の概念をサポートしていますので、それはプラスです）。

我々はまだデータベースの異なるコンフィギュレーションファイルを生成する必要があるしかし、フロントコントローラなど

だから我々は、異なる環境の設定を定義するbuild.propertiesとフォルダを持つことになった（と異なるクライアントのためにも、私たちの場合私たちは製品を出荷します）。このフォルダは、svn externalsを使用してファイル構造にリンクされています（再度は必要ありません）。

Phing build.xmlファイルは、コマンドラインでパラメータとしてプロパティファイルを受け取り、そこから値を取得し、必要な設定ファイル、コントローラ、およびその他の環境固有のファイルを生成します。 設定をテンプレートファイルに保存し、Phingのコピー/フィルタ機能を使用してテンプレートのプレースホルダを特定の値に置き換えます。

そして、このようなもののような単純なことができ、与えられた環境を設定するタスク全体：

phing configure-environment -DpropertyFile=./build_properties/build.properties.prod 

ビルドファイルにプロパティファイルを指定しpropertyFileプロパティが定義されているかどうかをチェックして、ファイルをロードします<property file="./build_properties/build.properties.prod" override="true" />を使用してください。それから、必要なだけの値で魔法を実行します。

あなたのsvn checkout/updateを使用して、結果として得られるすべての設定ファイルをsvn ignoreに入れることができます（これらはphingで生成されます）。私たちは実際にPhingの追加ステップを使用します。これらの手順は、Linuxシェルインストール自己展開パッケージを生成します。これはJenkinsで自動的に生成されます。その後、クライアントにパッケージを送信するか、サポートチームがJenkinsからパッケージを取得し、実行するだけで（プロダクションサーバーへの手動展開を好む）、またはJenkinsが自動的に展開することができます（たとえば、サーバー）。

必要に応じてさらに詳しい情報を記入していただきます。

Answer 2

Capistrano（サイトを移動して以来ドキュメントを更新していないようです）と展開を行う場合は​​を使用することをお勧めします。最終的には、おそらく多くのアプリケーションボックスを追加し、展開の一部として他のタスクを実行する必要があるため、これをサポートするフレームワークを選択すると、将来的に多くの時間を節約できます。私は2つのPHP配備（1つは小さく、もう1つは大規模）にcapistranoを使用しましたが、完全ではないものの、うまく機能します。また、すべてのコードのチェックアウト/アップデート、シンボリックリンクの場所への移動、何かがうまくいかない場合のロールバックを処理します。

cap dev deploy 
cap prod deploy 

私はこれを行うために探求してきた別のオプションfabricです：あなたは、Capistranoの設定が完了したら

は、すべてあなたがしなければならないようなものがあります。私はそれを使用していませんが、私は複雑なアプリケーションを再度展開しなければならないと考えていました。インターフェイスは簡単で簡単です。

第3の選択肢は、まだ開発の初期段階でまだ考えているかもしれないと思うかもしれないgantry（自己宣伝を赦免）です。これは、カピストラノを使用して多くの動く部分がある環境にPHPアプリケーションを配置するという不満から取り組んできたものです。 Capistranoは優れていて、PHP以外のアプリケーションのデプロイメントでもうまく機能しますが、何が起こっているのかを理解し、ニーズに合わせて微調整する必要があります。これは、私がファブリックに見栄えを与えることを提案する理由です。

Answer 3

私は現在同様の設定を使用しています。 Lamp + SVN + codeigniter + prdとdevサーバ。

私はdevのsvn reposを実行します。私はreposをdevドメインのルートフォルダにチェックアウトします。次に、コミット後のフックを使用して、開発者がコミットするたびにルートフォルダを更新します。

私たちが幸せになり、コードを完全にテストしたら、私はprdサーバーにsshを実行し、devルートをprdルートにrsyncします。

私の解決策はさまざまな設定です。ルートフォルダの外にconfig.iniファイルがあります。私は私のcodeigniter constants.phpスクリプトでファイルを解析します。これは、prdとdevサーバがリポジトリ内にいなくても別々の設定を持つことができることを意味します。

投稿コミットの助けが必要な場合は、rsyncとiniコードでお知らせします。