Отслеживание Git в файле composer.lock

Я использую, как всегда, composer в своих проектах.

Как всегда, я отслеживаю файл composer.lock в git. Во-первых, потому что так мне сказал бывший ведущий разработчик. Во-вторых, потому что это действительно практика — получать одинаковые зависимости. И установить их легко на производстве.

Во всяком случае, я использую некоторую библиотеку на самом деле. Для этого требуется symfony/process. Проблема в том, что на рабочем сервере из-за версии PHP (5.4.44) у меня может быть только версия 2.8.6 symfony/process.

Но у большинства разработчиков у нас есть PHP5.6 или PHP7. Так что мы могли бы использовать symfony/process v3.0.6 (последняя стабильная версия).

Итак, в composer.json я указал require symfony/process = 2.8.6.

Так что у всех нас есть эта версия. Это работает, любая проблема.

У меня все еще есть вопрос, который беспокоит меня все время. В некотором роде я бы поместил версию >= 2.8.6 в composer.json, поэтому для разработки у нас может быть версия 3.0.6, а в производстве — совместимая версия.

Но в этом случае у нас все время будет конфликт с файлом composer.lock (между разработчиками и продакшеном). Таким образом, мы не могли отслеживать его больше. Но все же, мне нравится получать самую последнюю стабильную версию. И через несколько дней мы обновим рабочий сервер до PHP 5.6. Итак, используйте symfony/process до последней стабильной версии.

Итак, в таком случае я должен прекратить отслеживать composer.lock ? Как мы могли бы получить последнюю версию и сделать миграцию на PHP5.6 проще?

Или все же лучше отслеживать файл composer.lock.

Спасибо,


person vekah    schedule 17.05.2016    source источник


Ответы (1)


Используйте две ветки, одну для разработки, другую для производства или выпуска с собственным composer.lock. Держите непрерывное слияние от разработки к производству, ежедневно, каждые несколько часов или любой другой подходящий интервал. Отделите производство от dev и измените .lock на 2.8.6. И последующее слияние с dev на production не вызовет конфликтов. Разработчики не должны переходить от локальной разработки к удаленной производственной ветке.

Если вы считаете, что 2 ветки неудобны, вы можете добавить 2 .lock в какое-то подходящее место репо. Например, 3.х.х там, где он должен быть, а 2.х.х в другой папке. В производственной среде вы можете скопировать версию 2.x.x, чтобы заменить версию 3.x.x. Это можно сделать в чем-то вроде предварительного сценария или post-checkout ловушки.

person ElpieKay    schedule 18.05.2016