PHPパッケージ管理あり/なしComposer
多くの（大きな）PHPアプリケーションが依存関係の管理にComposerを使用していることに気付きました。現在、Composerに切り替える必要があるかどうかを調べています（現時点では、依存関係を単純にvendor /というフォルダーに保持しています-自動的に更新することはできません）。
私はこの方法を好みます：
私はソースコードを入手するためにサードパーティのWebサイト/リポジトリに依存していません（これもセキュリティ上の問題であると思います）。また、何らかの理由でリポジトリの1つがダウンした場合はどうなりますか？アプリケーションを更新/インストールできなくなりますか？
（ローカルマシン/本番マシンに）Composerをインストールする必要はありません。これは小さな問題です。
より高速です。明らかに、更新が単一のソースからのものである場合は、更新を本番環境にすばやくプッシュできます すべてのベンダーパッケージを含む）バンドルを更新して、変更内容を本番環境にプッシュ/プルするだけで十分です。
Composerを認識しない多くのコンポーネントを使用しています（スタンドアロンライブラリ、composer.jsonファイルのないGitHubリポジトリ、多くのJS/CSSアセット、孤立した単一のPHPクラスも私はサードパーティのライブラリなどと考えたいと思います）;私がComposerを使用する場合、これらを管理するためにSatisのようなツールを使用する必要があります（そして、実際の利点なしに、物事はより複雑になります）。
私は自分のアプリケーションをいくつかのドメイン（約25）にデプロイしており、この方法で維持する方が簡単です（すべての変更が[自動的に]プッシュされ、後でバンドル自体を本番にプッシュできる単一のバンドル）。
多くの変更と更新があり（メインアプリケーションパッケージへの毎日の少数のコミット）、Composerが確認できるように各コミットのタグを設定するよりも、これらのコミットを本番環境にプッシュする方が簡単だと思います違いと新しいバージョンへの更新。
一方、私のアプローチにはいくつかの問題があります：
まず、コードベース/ビルドにすべてのベンダーパッケージを含めます。私はこれが良い習慣ではないことを知っており、私はこれの背後にある議論を理解しています（これは避けたいと思います）。
1つのリポジトリ（gitを使用）でアプリケーションに対するすべてのソースコード変更を追跡できるのは良いことかもしれません。明らかに、すべてのベンダーの変更はバンドルリポジトリに反映されます。しかし、一方では冗長性もあります-依存ベンダーパッケージの一部にも自分で取り組んでいるので、そこで変更をコミットし、関連するメッセージをCOMMITに追加してから同じ変更を行うことはあまり意味がありませんバンドルパッケージにもコミットされています。
その他のバンドル：メインアプリケーションの拡張であるいくつかのアプリケーションがあります。それらは独自のビジネスロジックや追加のコントローラーなどを提供します。これらについては、すべてのベンダーパッケージを再び含む個別のバンドルを作成する必要があります。そのため、ベンダーパッケージが更新を取得するたびに、これらの変更を追加のバンドルにも伝播する必要があります。
チームで作業するのはそれほど簡単ではありません。どのようにプロセスを進めればよいでしょうか。各メンバーはコアアプリケーションパッケージを更新してから、バンドル自体を更新する必要がありますか？その後、他のメンバーはバンドルとコアアプリケーションの両方をダウンロードしますか？繰り返しますが、それはどういうわけか冗長です。
私のアプローチはこれまでのところ機能しましたが、この開発/デプロイメントプロセス全体で何かが足りない可能性があると思います。依存関係やデプロイを管理するのではなく、開発に集中することを心がけているので、デプロイプロセスはできるだけスムーズで透過的であることが望ましいです。また、このアプローチでは、各サーバーでの更新に約30秒かかります。composerを使用すると、さらに時間がかかります（Composerでの更新は、すべてのサードパーティのリポジトリに接続する必要があるため） 。
したがって、要約として：
私の現在のやり方には冗長性があると思います。
これを処理するためのより良い方法があるかどうか知りたい（25のドメインすべてへの簡単な導入プロセス-そのうちの約20は同じコードベースを共有している;ソースコードの冗長性がない;チームは友好的）;
ソースコードには毎日多くの更新があるため、更新/展開プロセスは面倒ではありません。
私は開発のためのモジュラーアプローチが本当に好きです。同じアプリケーションを少しだけ変更する必要がある場合は、既存のロジックの一部を変更する追加のモジュールを追加します。モジュールで構成されたバンドルをビルドして、バンドルをインストールすることなく、この方法を維持したいと思います。
改善のためのアイデアはありますか？
編集：このトピックに関連する2つの記事で非常に興味深いものを見つけました：---（http://www.redotheweb.com/2013/09/12/should-you-commit-dependencies.html および- http://addyosmani.com/blog/checking-in-front-end-dependencies/ 。彼らが主に言っていることは「それは依存する」ということだと私は信じています。したがって、少なくとも私にとっては、依存関係をチェックインした方がよいと思います。
Composerの問題のほとんどは軽減できます：
- 依存関係のコピーを自分でホストします。スケジュールされたgit pullを使用して、自動的に更新することもできます。大規模なプロジェクトや企業環境の場合、これは良いステップです。
- すぐにアップロードできる本番環境対応バンドルを作成するビルドシステムまたは継続的インテグレーションサーバーを使用します。これは、単一のシェルスクリプトと同じくらい簡単です。 （手動のFTPアップロードではなく）適切なデプロイシステムを使用している場合、これは簡単に接続できます。
これら2つのことにより、ほとんどの懸念が軽減されます。すでに導入システムを使用しているかどうかは示さなかった。そうでない場合、これは実際にはあなたの最大の問題かもしれません。自動化されたデプロイメントでは、ビルドステップは必要に応じて複雑になる可能性があります。すべてをスクリプト化できる場合は、それほど重要ではありません。
について：
私はComposerを認識しない多くのコンポーネントを使用しています。 Composerを使用する場合、これらを管理するにはSatisなどのツールを使用する必要があります。
あなたは自分のcomposer.json内に不足しているcomposer.jsonファイルのインライン定義を単に書くことができることを知っていますか？ほとんどの場合、これにより問題なくComposerサポートを改良できます。
多くの変更と更新があり、Composerが違いを確認して新しいバージョンに更新できるように、各コミットにタグを設定するよりも、これらのコミットを本番環境にプッシュする方が簡単だと思います。
個別のタグを作成する必要はありません。 git commitの数値も使用できます。
Composerは、依存関係の解決だけに役立ちます。ますます多くのパッケージがますます複雑になり、手動で依存関係を追跡することはかなり面倒な作業になる可能性があります。ときどきバージョンの競合が発生することは言うまでもありません。手動で検出するのは難しく、通常、依存関係マネージャーを使用しない場合は、実行時に不明瞭なバグとして現れるだけです。
適切な開発、依存関係管理、ビルド、テスト、デプロイワークフローの設定は、事前に時間がかかる可能性があることの1つですが、十分に複雑なプロジェクトで長期的に無数の時間を節約できます。
composerの主な問題は速度のようです。非常に多くのコードがプロジェクト間で共有されているため、共有ベンダーのサブフォルダーにシンボリックリンクを設定できるため、プロジェクトの1つだけを更新する必要があります。その後、rsyncを使用してすべてのサーバーにデプロイできます。
各プロジェクトにビルドバージョンを含むファイルを用意して、デプロイメントスクリプトでそれを使用してcss/jsの縮小ファイル名を更新し、キャッシュを無効化できるようにします。すべてのプロジェクトのビルドバージョンのグローバルキャッシュを含む一時ファイルを設定して、デプロイ時に比較し、更新されたものだけをプッシュすることもできます。