Разработка с разными версиями зависимостей

Question

Мы разрабатываем приложение PHP и несколько зависимостей для него.При разработке мы хотели бы использовать ветки dev и версии с тегами производства.
Проблема в том, что некоторые из этих модулей зависят друг от друга.

Как лучше всего обрабатывать рабочий процесс здесь?

Потому что, если в основном приложении нам нужны версии dev, каждый должен помнить, чтобы изменить его перед слиянием с master.
Одним из решений было бы использование отдельного файла composer.json для разработки, но я думаю, что это не сработаетс зависимостями зависимостей.

Для иллюстрации:

Основное приложение composer.json в разработке:

"module_1": "dev-develop",
"module_2": "dev-develop",

В "module_1" composer.json:

"module_3": "dev-develop"

---

В производственном главном composer.json:

"module_1": "^1.0.0",
"module_2": "^1.0.0",

В "модуле_1" composer.json:

"module_3": "^1.0.0"

Answer 1

Я собираюсь оспорить предпосылку и сказать:

Не делай этого.

Как правило, вы должны стараться максимально приблизиться к производственному выпуску во время разработки. Это означает тестирование в среде, близкой к рабочей, с использованием данных, близких к рабочим данным, и с использованием версий зависимостей, которые будут использоваться в рабочей среде. Любое отклонение от этого увеличивает риск пропуска ошибок, которые скрыты этим отклонением.

Иногда неизбежно отклоняться от производства (новая версия зависимости требуется для новой функции, производственные данные не могут быть использованы из-за соображений конфиденциальности и т. Д.), Но к этой цели следует стремиться.

---

Тем не менее, если вы абсолютно должны иметь разные зависимости во время разработки:

Потому что, если в основном приложении нам нужны версии для разработчиков, каждый должен не забудьте изменить его до слияния с мастером.

Это, кажется, указывает на то, что вы разрабатываете функции в ветвях, а затем объединяетесь с мастером. Если это так, то самым чистым решением было бы изменить на производственные версии до слияния .

Весь смысл наличия функциональных ветвей состоит в том, чтобы протестировать код перед его слиянием. Правильное тестирование требует использования зависимостей, которые будут использоваться на мастере. Итак, ваш рабочий процесс слияния должен быть:

• переключение версий зависимостей на «производственные версии» (вы можете взломать скрипт, чтобы сделать это, если много работы)
• перепроверить все, чтобы убедиться, что коммутатор не сломал все
• слияние (без конфликтов слияния в composer.json, потому что на мастере то же самое)

Answer 2

Можно удалить composer.json из управления версиями и вместо этого отметить два файла composer.json-template-develop и composer.json-template-main.

Обратите внимание, что это обобщает все файлы конфигурации.Это делает разницу между управлением версиями и развертыванием более явной.Это также рекомендуется Subversion, цитируя FAQ:

У меня есть файл в моем проекте, который должен изменить каждый разработчик, но мне не нужны эти локальныемоды, которые когда-либо будут совершены.Как я могу заставить 'svn commit' игнорировать файл?

Ответ таков: не ставьте этот файл под контроль версий.Вместо этого поместите шаблон файла под контроль версий, что-то вроде «file.tmpl».

Затем, после первоначальной проверки svn, пусть ваши пользователи (или ваша система сборки) сделают обычную копию ОСшаблона с правильным именем файла, и попросите пользователей настроить копию.Файл не версионный, поэтому он никогда не будет зафиксирован.И если вы хотите, вы можете добавить файл в свойство svn: ignore его родительского каталога, чтобы он не отображался как '?'в команде 'svn status'.