8

現在、Web アプリに LAMP スタックを使用しています。私の開発と製品は同じクラウド インスタンスにあります。現在、新しいインスタンスを取得しており、開発/テスト環境を新しいインスタンスに移動して、本番環境から分離したいと考えています。

以前は、SVN を prod ディレクトリ (私の vhost.conf が指す) にエクスポートする単純な Phing スクリプトでした。環境が分離された状態で、適切なビルド プロセスを作成するにはどうすればよいですか?

SVN リポジトリを開発サーバーに転送してから ssh+svn プッシュを行うことを考えています (これは Phing で可能ですか?)

このタイプのセットアップのベスト/一般的な方法は何ですか?

より詳しい情報：

私は現在、MVC フレームワークにCodeIgniterを使用しており、localhost デプロイメントの自動ビルドにはPhingを使用しています。Web アプリは、 Javaで記述されたいくつかの CRON スクリプトでもサポートされています。

アップデート：

Phing + Jenkinsを使用することになりました。これまでのところうまくいきます！

4

3 に答える 3

3

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

ただし、データベース、フロント コントローラーなどのさまざまな構成ファイルを作成する必要があります。

そのため、さまざまな環境の構成を定義する build.properties を含むフォルダーを作成することになりました (この場合、製品を出荷するさまざまなクライアントの構成も定義します)。このフォルダは、svn externals を使用してファイル構造にリンクされています (これも必要ありません)。

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

特定の環境を構成するタスク全体は、次のように簡単になります。

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

ビルド ファイルpropertyFileで、プロパティ ファイルを指定するプロパティが定義されているかどうかを確認し、.xml を使用してファイルをロードします<property file="./build_properties/build.properties.prod" override="true" />。次に、必要に応じて値を使用して魔法を実行します。

svn checkout/update を引き続き使用して、結果のすべての構成ファイルを svn ignore に入れることができます (これらは phing によって生成されます)。Phing では、実際に追加の手順を使用します。最終的にこれらの手順により、Linux シェル インストールの自己展開パッケージが生成されます。これは Jenkins で自動的に生成されます。次に、パッケージをクライアントに送信するか、サポート チームが Jenkins からパッケージを取得して、パッケージを実行するだけで展開全体を行うことができます (実稼働サーバーへの手動展開を引き続き好みます)、または Jenkins が自動的に展開することができます (たとえば、テストなど)。サーバー）。

必要に応じて、さらに情報を書いていきます。

于 2011-07-12T22:21:51.413 に答える
1

Capistrano（サイトを移動してからドキュメントを更新していないようです）とrailsless-deployを使用してデプロイすることをお勧めします。最終的には、デプロイの一部としてアプリボックスを追加し、他のタスクを実行する必要があるため、これをサポートするフレームワークを選択すると、将来的に多くの時間を節約できます。私は2つのPHPデプロイメント（1つは小さいものと1つは大きいもの）にcapistranoを使用しましたが、完璧ではありませんが、うまく機能します。また、すべてのコードのチェックアウト/更新、シンボリックリンクの所定の位置への移動、および問題が発生した場合のロールバックも処理します。

capistranoを構成したら、次のようにするだけです。

cap dev deploy 
cap prod deploy

これを行うために私が検討したもう1つのオプションは、ファブリックです。使ったことはありませんが、複雑なアプリを再度デプロイする必要がある場合は検討します。インターフェースはシンプルでわかりやすいです。

開発の初期段階にあると思われる3番目のオプションは、ガントリーです（自己宣伝はご容赦ください）。これは、capistranoを使用してPHPアプリケーションを多くの可動部分がある環境にデプロイすることへの不満から、私が取り組んできたものです。Capistranoは素晴らしく、PHP以外のアプリケーションのデプロイメントに適していますが、何が起こっているのかを理解し、ニーズに合わせてコードを微調整するために、コードをいじくり回す必要があります。これが、生地の見栄えを良くすることをお勧めする理由でもあります。

于 2011-07-12T22:38:23.900 に答える
0

私は今、同様の設定を使用しています。ランプ+SVN+ codeigniter+prdおよびdevサーバー。

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

満足してコードを完全にテストしたら、prdサーバーにSSHで接続し、devルートをprdルートにrsyncします。

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

post-commit、rsync、およびiniコードについてサポートが必要な場合は、お知らせください。

于 2011-07-28T20:18:50.827 に答える