Composer＆GITのcomposer.lockとマージの競合

Question

これが私たちの状況です：

3つの異なるLaravelプロジェクトがあり、3つのプロジェクトすべてがコアプロジェクトに依存しています。このコアプロジェクトは、プライベートリポジトリでホストされる個別のLaravelパッケージであり、使用されます他のプロジェクトの依存関係として。

以前は、コアプロジェクトで何かが変更されるたびに、composer各プロジェクトのサーバーでourvendor/ourcorepackageを更新して、コアの変更をプルします。ただし、最近はcomposer 512 MBのRAMを搭載したDigitalOceanステージング環境で更新を実行しようとすると、深刻なメモリの問題が発生するようです。参照： https://github.com/composer/composer/issues/1898

私がいつも出くわす解決策は、常にcomposer installを本番サーバーにインストールする必要がある」という人たちです。新しいサーバーに更新すると危険な場合があるため、セキュリティの観点からこれに関連することができます。コードを壊す可能性のあるサードパーティパッケージのバージョン。ただし、この場合は独自のコアパッケージのみを更新するため、何をしているのかがわかりますが、このメモリの問題により、composer =メモリをあまり必要としないため、インストール方法。

つまり、基本的にこれが現在のワークフローです。

1. コアパッケージで何かが変更された場合、composer各プロジェクトでourvendor/ourpackageをローカルに更新する必要があります。これによりcomposer.lockファイルが生成されます。

2. リポジトリにcomposer.lockファイルをコミットします

3. 各プロジェクトのサーバーで、gitpullを実行してcomposer installを実行します。これにより、コアパッケージが更新されるだけで、実行速度が大幅に向上し、メモリの問題は発生しませんvs composer更新

ただし、このソリューションでは2つの問題が発生します。

1. 同じプロジェクトで複数の開発者と作業しているため、変更をローカルにプルすると、composer.lockファイルのマージの競合が発生することがあります。
2. サーバーでgitpullを実行すると、エラーが発生します。次のファイルへのローカル変更は、マージによって上書きされます。composer.lockマージする前に、変更をコミットするか、隠してください。

だから私はここで何をすべきですか？サーバーをプルする前に、composer.lockファイルを削除しますか？ composer.lockファイルのマージの競合をどのように処理する必要がありますか？

composer updateは、その方法がはるかに論理的であるように見えるため、メモリの問題に悩まされているのは残念です。必要なパッケージを更新するだけで、composer.lockファイルに煩わされることはありません。

GITとcomposerの場合の正しいワークフローと、上記の競合を解決する方法を教えてください。

ご意見ありがとうございます

Answer 1

開発者が自分でこの手順を実行しない場合、コア更新（または更新されるその他の依存関係）がそれを使用するプロジェクトで問題を起こさないことをどのようにテストできますか？

そのため、通常のワークフローでは、十分なRAM（つまり、PHPのメモリ制限として1GB以上が設定されている）の開発マシンでcomposer updateが実行されることを想定しており、更新は次のようになります。開発者によって手動でトリガーされます（継続的インテグレーションビルドによって自動的にトリガーされる場合、メモリ要件はこのマシンにも適用されます）。

このメモリ要件を回避する方法はありません。 512 MB RAMがインストールされているWebサーバーは、同時ユーザーがほとんど存在しないステージングサーバーとして機能できる可能性がありますが、Composer依存関係。

個人的には、composer.lockのマージの競合を非常に簡単なシステムで修正します。ロックファイルを削除して、composer updateを実行します。これにより、すべての依存関係がバージョン要件を満たす最新バージョンに更新され、マージ中にコミットされる新しい作業用composer.lockファイルが作成されます。

期待どおりに機能するか、テストでエラーがすぐに検出されるため、すべてを更新する可能性があることを恐れていません。

慎重に使用するサードパーティのパッケージを選択します。

• できればセマンティックバージョニングを使用して、バージョンにタグを付ける必要があります。
• リリースバージョンにはブランチを使用していません（開発中に誰かがブランチを使用することはめったにありませんでした）
• 後方互換性のない変更を行う場合は、新しいメジャーバージョンを出荷する必要があります
• ローカルで開発されたパッケージもこれらの要件に従います

これは、ローカルのSatisインスタンスによって提供される約270個のパッケージで機能します（おそらく、メモリフットプリントを削減しようとするときに考慮すべき要素です。Composerであることがわかっているパッケージのみがメモリに格納されます：10個を比較してください） packagist.orgで270個のローカルパッケージとともに利用できる可能性のある1000個のパッケージ）270個の60個のパッケージが20人の開発者によってローカルで開発され、新しいバージョンがランダムにリリースされています。過去2年間の更新の失敗は非常にまれであり、他のパッケージと同様に処理する必要があります。バグ：タグ付けされたバージョンに互換性がないことが検出された場合、変更を元に戻すバグ修正リリースをリリースし、互換性のない変更が必要な場合は、元の変更に新しいメジャーリリースのタグを付けます。

したがって、要求するワークフローはおそらく次のようになります。

• いつでも、開発者はローカルマシンでcomposer updateを実行できるはずです。
• 彼らは、これが彼らのローカルマシンで物事を壊すかどうかを検出できるはずです。
• 何も壊れていない場合は、composer.lockファイルを含む変更をGitにコミットします
• ステージングサーバーはcomposer installのみを実行し、開発者が自分のマシンで使用したバージョンを正確に使用します。
• ステージングで何も壊れていない場合、そのバージョンは本番環境で使用する準備ができています。

すでにコミットされているバージョンを別の開発者のマシンにマージすると、composer.lockとのマージの競合が表示される可能性があります。

• 他のすべてのファイルの競合を解決します。
• composer.lockファイルを削除する必要があります。
• ここから、ワークフローは上記のようになります。
• 開発者は、ローカルマシンでcomposer updateを実行できる必要があります。
• 彼らは、これが彼のローカルマシンで物事を壊すかどうかを検出できるはずです。
• 何も壊れていない場合...など。

Answer 2

別のアプローチ（composer updateを実行せずに）：

1. 新しい（および削除された）行をcomposer.jsonから別のテキストファイルにコピーします。
2. リモートのcomposer.jsonファイルとcomposer.lockファイル全体を使用します。
3. マージ競合モードでは、次のようにします。
   • composer install
   • 手順1で書き留めた新しいパッケージごとに、composer require vendor/package:versionを実行します。
   • 手順1で書き留めたパッケージを削除するたびに、composer remove vendor/packageを実行します。
4. テスト！、コミット、完了！

このメソッドは、リモートブランチ（おそらくmasterまたはdevelopブランチ）からのロックを保持し、新しいパッケージのみを更新します。