私は PHP で新しいプロジェクトを開始しています。他の開発者から、PHP の展開に適した戦略についてフィードバックをもらいたいと思っています。変更がコミットされると、開発サーバーまたは運用サーバーにすばやく移行できるように、物事を少し自動化したいと考えています。
Ruby で Capistrano を使用したデプロイと、いくつかの基本的なシェル スクリプトの経験があります。
私が自分で最初に頭を悩ませる前に、他の人がプロジェクトでこれにどのように取り組んでいるかを聞くことは素晴らしいことです.
現在、開発者はサイトのローカル インストールに取り組んでおり、subversion リポジトリに変更をコミットしています。初期展開は、svn からタグ付きリリースをエクスポートし、それをサーバーにアップロードすることによって行われます。
通常、追加の変更は、変更されたファイルを手動でアップロードすることにより、断片的に行われます。
PHP の場合、Phingビルド スクリプトを使用した SVN が最適です。Phing はANTに似ていますが、PHP で記述されているため、PHP 開発者がニーズに合わせて変更するのがはるかに簡単になります。
展開ルーチンは次のとおりです。
継続的インテグレーション サーバーであるphpUnderControlもあります。正直に言うと、Web プロジェクトにとってあまり役に立ちませんでした。
私は現在、Gitを使用してPHPをデプロイしています。シンプルなgitpushプロダクションは、Gitからの最新のコピーでプロダクションサーバーを更新するために必要なすべてです。Gitは、プロジェクト全体ではなく、差分を送信するだけで十分に賢いので、簡単で高速です。また、私の側でハードウェア障害が発生した場合に備えて、リポジトリの冗長コピーをWebサーバーに保持するのにも役立ちます（ただし、安全のためにGitHubにプッシュします）。
Capistrano の Web フロントエンドであるWebistranoを使用しており、非常に満足しています。
Webistrano は、SVN、GIT などからのマルチステージ、マルチ環境展開を可能にします。組み込みのロールバック サポート、web、db、app などの個別のサーバー ロールのサポートがあり、並行してデプロイされます。ステージごとなど、複数のレベルで構成パラメーターをオーバーライドし、すべてのデプロイの結果をログに記録し、オプションでメール送信することができます。
Capistrano と Webistrano は Ruby アプリケーションですが、デプロイメントの「レシピ」の構文は簡単で強力なので、PHP プログラマーなら誰でも理解できます。もともと Capistrano は Ruby on Rails プロジェクト用に構築されましたが、PHP プロジェクトにも簡単に対応できます。
設定が完了すると、ステージング バージョンをデプロイするテスターなど、プログラマー以外でも簡単に使用できます。
可能な限り迅速なデプロイを提供するために、 fast_remote_cacheメソッドをインストールしました。これは、リモート サーバー上の svn working-copy キャッシュを更新し、結果をハードリンクします。
Apache Antを使用して、さまざまなターゲット (開発、QA、およびライブ) にデプロイします。Ant は Java デプロイメントで機能するように設計されていますが、任意のファイルをデプロイするための非常に便利な一般的なソリューションを提供します。
build.xml ファイルの構文は非常に簡単に習得できます。コマンド ラインで ant プログラムを呼び出したときに実行されるさまざまなターゲットとその依存関係を定義します。
たとえば、dev、QA、および live のターゲットがあり、それぞれが cvsbuild ターゲットに依存しています。このターゲットは、CVS サーバーから最新のヘッド リビジョンをチェックアウトし、適切なファイルをビルド ディレクトリにコピーし (fileset タグを使用)、次にビルド ディレクトリを適切なサーバーに再同期します。学ぶべきいくつかの癖があり、学習曲線は完全に平坦ではありませんが、私はこの方法で何年も問題なくやっているので、あなたの状況に合わせてそれをお勧めします.このスレで見ます。
私は Git を使用して手動で作業を行います。開発用の 1 つのリポジトリはgit push --mirror、パブリック リポジトリに追加され、ライブ サーバーはそこからプルされた 3 番目のリポジトリです。この部分は、あなた自身のセットアップと同じだと思います。
大きな違いは、私が取り組んでいるほぼすべての変更にブランチを使用し (現在、約 5 つ持っています)、それらの間を行ったり来たりする傾向があることです。master ブランチは、他のブランチをマージする場合を除き、直接変更されません。
マスター ブランチからライブ サーバーを直接実行し、別のブランチを作成してマージする準備ができたら、サーバーをそのブランチに切り替えます。壊れた場合、マスターに戻すのに数秒かかります。機能する場合は、マスターにマージされ、ライブ コードが更新されます。SVN でのこれの類推は、2 つの作業コピーを持ち、シンボリック リンクを介してライブ コピーを指すことになると思います。
Phingが何度か言及されていることは知っていますが、 phpUnderControlで幸運を祈りました。私たちにとって私たちは
自家製の展開スクリプトに代わるものは、サービスとしてのプラットフォームに展開することです。これにより、多くの作業が抽象化されます。PaaS は通常、独自のコード展開ツール、スケーリング、フォールト トレランス (例: ハードウェアが故障しても停止しない) を提供し、通常は監視やログ チェックなどのための優れたツールキットを提供します。時間の経過とともに最新の状態に保たれる既知の適切な構成 (頭痛の種が 1 つ減ります)。
私がお勧めする PaaS はdotCloudです。PHPに加えて ( PHP クイックスタートを参照)、MySQL、MongoDB、およびその他のサービスを多数デプロイすることもできます。また、ゼロ ダウンタイムの展開、インスタント ロールバック、SSL と websocket の完全サポートなどの優れた機能もあります。また、常に優れた無料利用枠があります :)
もちろん、私はそこで働いているので、少し偏っています！dotCloud に加えてチェックアウトする価値のあるその他のオプションは、Pagodabox と Orchestra (現在は Engine Yard の一部) です。
お役に立てれば！
ソロモン
リポジトリから運用サーバーに変更を自動的かつやみくもに取得するのは危険に思えます。コミットしたコードにリグレッション バグが含まれているため、本番アプリケーションに問題が発生した場合はどうなるでしょうか?
しかし、PHP 用の継続的インテグレーション システムが必要な場合は、 Phingが PHP の最良の選択だと思います。ただし、scpなどの手動の方法を詰め込むため、自分でテストしていません。
私はパーティーにかなり遅れましたが、私たちの方法を共有したいと思いました. Phing とPhingistranoを使用します。これは、ビルド済みのビルド ファイルを介して Phing に Capistrano のような機能を提供します。とてもクールですが、現時点で Git を使用している場合にのみ機能します。
xml構成ファイルの苦痛に耐えられるのであれば、Phingがおそらく最善の策です。Symfonyフレームワークには独自のレーキ（pake）ポートがあり、これは非常にうまく機能しますが、Symfonyの他の部分とはかなり緊密に結合されています（おそらくそれらを分離することもできます）。
別のオプションは、Capistranoを使用することです。明らかに、RubyのようにPHPと統合することはできませんが、それでも多くのことに使用できます。
最後に、いつでもシェルスクリプトを書くことができます。これまでのところ、それは私がやったことです。
私の仕事では、私と私のチームは、capistranoのデプロイの代わりにPhing指向を開発しました。また、PHPUnitテスト、phpcs、PHPDocumentorなどのphingで利用できるいくつかの機能も組み込んでいます。gitのサブモジュールとしてプロジェクトに追加できるgitリポジトリを作成しました。これは非常にうまく機能します。私はそれを少数のプロジェクトに添付しましたが、モジュール式であるため、いくつかの環境（ステージング、テスト、本番など）のいずれかのプロジェクトで簡単に動作させることができます。
phingビルドスクリプトを使用すると、コマンドラインから手動で実行できます。また、Hudsonと現在のJenkinsciを使用してビルド/デプロイルーチンを自動化することにも成功しました。
リポジトリがまだ公開されていないため、現在リンクを投稿できませんが、間もなくオープンソースになるとのことですので、興味のある方やお持ちの方はお気軽にご連絡ください。 phingとgitを使用したデプロイメントの自動化に関する質問。
http://controltier.org/wiki/Main_Page
マルチサーバーの展開とメンテナンスに使用します。
1 年遅れですが... 私の場合、展開は自動ではありません。コードをデプロイしてデータベース移行スクリプトを自動的に実行するのは危険だと思います。
代わりに、subversion フックを使用して、テスト/ステージング サーバーにのみデプロイします。コードは、テストを実行して動作を確認した後、イテレーションの最後に本番環境にデプロイされます。デプロイ自体には、rsync を使用してファイルを転送するカスタムの Makefile を使用します。Makefile は、リモート サーバーで移行スクリプトを実行したり、Web サーバーやデータベース サーバーを一時停止/再開したりすることもできます。
サーバー上に SVN リリース ブランチの作業コピーがあります。サイトの更新 (スキーマの変更がない場合) は、SVN update コマンドを発行するのと同じくらい簡単です。サイトをオフラインにする必要さえありません。
SVN のデプロイ方法があまり良くないと思います。なぜなら：
全世界のSVNアクセスを開く必要があります
実動 Web サーバーに多数の .svn がある
ブランチを生成する Phing + すべての js/css を組み合わせる + ステージ構成を置き換える + すべての www サーバーへの ssh アップロードがより良い方法だと思います。
10wwwサーバーにsshしてsvnアップも面倒。