В последнее время, данная тулза активно выбивается в тренды, однако рентабельность её использования до меня до сих пор не доходит. Для больших проектов с автодеплоем, масштабированием и тд он прекрасен. Запустилась нода, выгружаем код, запускаем композер, все заработало, но в чем кардинальная разница от билд серверов и тд, которые так или иначе разворачивают код на продакшене. Был бы очень благодарен за реальные кейсы использования сего.
Проще всего сравнивать Composer c Bundler'ом.
Composer не является средством для деплоя или миграций типа Capistrano\Сapifony, его основной задачей является менеджмент зависимостей. Когда в либах находят дыры или правят баги и нужно быстренько обновить зависимости - лучше средства нет.
Обычно это дело сразу правится в репозитории, и деплой сервер вытаскивает и раскидывает по серверам уже пофиксеный код. Зачем еще один инструмент? Хотелось бы посмотреть именно реальный кейс разработка-деплой-етк с использованием композера например
В сам репозиторий проекта можно запихнуть зависимости выкачанные Composer'ом, и обновлять по мере необходимости меняя 2-3 цифры. Либо обновлять зависимости на целевой машине если их слишком много и раздувать репозиторий не целесообразно.
Реальный кейс: в git репозитории хранится только папка application с вашими классами (контроллерами, моделями и т.п.). Все остальные библиотеки (включая сам фреймворк) другие разработчики и сервер получают сами - через composer update (install). Такой подход, во-первых, ускоряет автозагрузку классов, а во-вторых, позволяет одной строкой добавить новую библиотеку и сразу начать ее использовать.
Не является он средством деплоя. Разумнее было бы его сравнивать с apt. И как раз в большом проекте, имхо, его польза под вопросом. Потому как в большом проекте автодеплой.
