php - 50を超えるインストールをPHP5.3にアップグレードします

Question

Webデザイナーとして、2011年は50を超える（異なる）cmsとその他のphp5.2駆動のアプリケーションで良い年を過ごしました。一部にはコアへのカスタマイズもありました。誰かがそのような量のアプリをphp5.3にアップグレードするにはどうすればよいですか？

phpの開発者はそれについて考えたことがありますか？多くの（人気のある）関数は減価償却され、私たちのような人々に多くの作業を引き起こします。

どうすればいいのか本当にわからない

score 11 · Accepted Answer

短い答え

場合によります。

移行の戦略は、ソース自体の品質とコンテンツ、およびアーキテクチャとワークフローの影響を受けます。それを機能させるための「特効薬」はありません。

長い答え

それがどのように行われるべきか

すべてのステージングサイトを自動的にアップグレードし、すべての単体テストを実行し、それらがすべて合格した場合は、受け入れテストを実行します。すべてのテストに合格するまでに発生する問題を修正します。次に、QA担当者に、すべてが本当に100％OKであることを確認させます。このプロセス全体は、ほとんどの場合、継続的インテグレーションシステム/フレームワークによって実行されます。

すべてがステージング環境で機能するようになったら、メンテナンスのために各サイトを停止し、更新されたコードを運用環境に展開し、サーバーのソフトウェアをアップグレードして、サイトを復旧します。

どのように（おそらく）それをしなければならないか

どのソフトウェアにもユニット/アクセプタンステスト、最新の仕様、または継続的インテグレーションシステムの概念がないため、難しい方法で行う必要があります。

'step 1' take a survey of different servers setups on which your projects 
         are deployed (if you have all project on single box with 
         virtual-hosts, you can skip this bit )
'step 2' find somewhere a computer, which can temporary act as local server
<foreach setup>

    'step 3' install/configure this temporary server to be exactly like 
             the "setup"
    <foreach project on that setup>

        'step 4' BACKUP ALL THE STUFF
        'step 5' copy the latest source and DB from the production server
        'step 6' upgrade the software
        'step 7' see what has *blown* up and fix what you can find    
        'step 8' pass to the QA team 
        'step 9' store the source

    </endforeach project>
    'step 10' take the server with this configuration down for maintenance
    'step 11' upgrade software on the server
    'step 12' deploy all the projects from this server 
    'step 13' prayer (optional)

<endforeach setup>

これはちょっと「簡単な」バージョンです。基本的に、サーバーごとに移動し、ローカルでクローンを作成してから、プロジェクトをアップグレードしてパッチを適用する必要があります。次に、各サーバーをアップグレードし、パッチを適用したバージョンを適用します。そして希望。

アップグレードする必要がありますか？

_{クライアントはこれにお金を払わないでしょう。}

約50の異なるプロジェクトがあるので、時間とお金の価値さえあるかどうかを調査する必要があります。このような分析の結果、企業がほとんどのプロジェクトを「レガシー」としてマークし、サーバーを最新の5.2.xにアップグレードする方が理にかなっていることに気付くかもしれません。その後、そのままにしておきます。

もちろん、ほとんどのプロジェクトをアップグレードしないことにした場合でも、それを必要とするプロジェクトもあります。特に継続的な契約を伴うプロジェクトは、会社に安定した収入の流れを生み出します。

とにかくアップグレードする必要があるので、これらのキャッシュカウプロジェクトのアップグレードを開始することをお勧めします。そして、この経験から、残りの「ポートフォリオ」のコストを計算できます。

次回はどうですか？

PHP 5.4がリリースされました（最後の編集の時点で、5.5はすでにリリースされています）。今年の終わりまでにほとんどの企業は、「5.4の使用を開始する時期ですか？」という質問に直面するでしょう。。少し早く、少し遅れて。使用するフレームワークとCMSも、更新を取得する傾向があります。

結論：あなたの会社は全体として、このプロセスを合理化する方法を調査し始める必要があります。

また、PHP 5.5にアップグレードして、mysql_*関数がE_DEPRECATE警告を表示し始めたらどうでしょうか。ドキュメントの赤いボックスを参照してください。mysql_affected_rows()これは一度限りのことではありません。

より良い展開戦略（単体テストと継続的インテグレーションを含むもの）の実装に投資するのが賢明かもしれません。

_<rant>

_{phpの開発者はそれについて考えたことはありますか？多くの（人気のある）機能は減価償却されたばかりで、私たちのような人々に多くの仕事を引き起こしています。}

_{非推奨になっている機能と機能は、古くからドキュメントでそのようにマークされています。たとえば、ereg()PHPを学び始めてから、オブジェクトを参照して渡すことは使用しないという通知がありました。非推奨の警告は主にPHP4コードベースに影響します（この場合、あなたの質問は少し不誠実です）。}

_{何年にもわたってコミュニティで受け入れられてきた強制的な慣行が、どのように「多くの仕事を引き起こしている」のかわかりません。}

_</rant>

score 3 · Accepted Answer

まず、依存関係情報が正しく設定されたパッケージ管理システム（yum、apt-getなど）を介してプログラムをパッケージ（RPM、DEBなど）に保存することによって。

次に、依存関係をアップグレードするときにコードが壊れるかどうかをテストする統合ステップを備えた適切なリリースチェーンを用意します。JenkinsなどのCIサーバーは、自動テストを実行し、パッケージをビルドできます。

問題がある場合、それらはすぐに現れ、あなたはそれらを修正することに取り掛かることができます。バグの優先順位付けと修正には通常の内部プロセスを使用します（特定のパッケージの依存関係のアップグレードによって発生するすべてのバグにバッチとして焦点を当てる価値があり、12のプログラムを並行して作業することで作業を分割しないことに注意してください）。

score 3 · Accepted Answer

明らかに、推奨されるアップグレード方法に従う必要があります。他の答えがそれらを提供しています。

実行するプロセスと手順のステップがあります。そこには具体的な提案はありません。実際、tereškoの答えはかなり良いです。

ただし、コードベース自体を変更する必要がある場合は、次の選択肢があります。

あなたはそれをすべて手作業で行うことができます（それは暗黙の仮定のようです）。これは驚くべきアドバイスではありません。
変更の適用を自動化できる場合があります。

純粋に手動のアプローチでは、すべてのタイプの非互換性（言語の変更、フレームワークの変更、インフラストラクチャの交換など）を発見し、それらを一般的に修正する方法を理解し、必要に応じて各修正タイプを適用する必要があります。この最後の部分は、コードのすべての行を調べて、間違っている場合は修正する必要があるため、非常にコストがかかります。

自動化された変更は、問題の発見や一般的な解決策の解決には役立ちません。しかし、問題を解決する方法を理解したら、必要なすべての場所にその解決策を適用するのに役立つ可能性があります。

それぞれの問題に必要なのは、一種の「コードにこれが表示されている場合は、それに変更する」ことです。その非公式なアイデアは、プログラム変換、コードを変更するための正式なルールとしてパッケージ化できます。

私の会社は、プログラム変換エンジンであるツール、DMS SoftwareReengineeringToolkitを提供しています。言語固有のフロントエンドを使用して、さまざまな種類のコンピューターソースコードを分析および変換できます。このタスクに適したPHPフロントエンド（パーサー/プリティプリンター）があります。DMSはこの種のタスクのために設計されたため、その名前の一部は「ソフトウェアリエンジニアリングツールキット」です。私たちはこれを多くの厄介なリエンジニアリングタスクに使用してきました。

したがって、アイデアは、必要な変更をプログラム変換としてパッケージ化し、DMSなどのツールを使用してそれらを適用することです。コードの問題を修正するルールを作成するのは手間がかかりますが、一度実行すると、DMSはそれらのルールを確実に適用できます。したがって、最初のいくつかのシステムに投資して（ルールを調整および検証するために）、最後の48個の奇数を効率的に更新します。

これは万能薬ではありません。必要なものの変換を常に簡単に記述できるとは限りません。ただし、変更を加える必要が多く、コード全体に変更を加えたい場合は、ツールを使用してできる限り多くの変更を行う方が、すべてを手動で行うよりもはるかに優れています。

score 2 · Accepted Answer

私はこのリストを推測します：http：//php.net/manual/en/migration53.incompatible.phpはあなたが心配しなければならないすべてです。

score 2 · Accepted Answer

続行するための最良の方法は、PHP 5.3移行ガイド（そしてPHP 5.4）に従うことです。

score 0 · Accepted Answer

チェロキーのような代替Webサーバーを使用している場合は、PHPの並列インストールを使用できます。OSのインストール制限のためにこれを行うことができない場合は、いつでもchrootされた環境を使用して、phpインタープリターのポートを変更できます。

PHPバージョンを更新する必要がある場合は、新しいphpバージョンを使用するupdated.domain.comなどの2番目のドメインをページに追加します。通常のユーザーには違いはありません。ただし、残念ながら、これは、相対パスを使用し、ファイルにハードコードされたドメインがない場合にのみ機能します。