Изолирующий пакет symfony, чтобы каждая команда могла работать в отдельном пакете
У меня есть огромный api, написанный на symfony3 с несколькими пакетами (все пакеты включены в один и тот же репозиторий git), у нас есть несколько команд, каждая из которых работает над своим собственным пакетом, моя проблема: у нас есть одна ветка по env, поэтому, если разработчик работать над веткой dev, хотя все другие команды используют ту же ветку, он не может интегрировать свой собственный код в ветку prod, потому что все другие изменения, сделанные другими, также могут быть введены в prod, и это очень сложная ситуация для управления. Итак, как разделить мое приложение, чтобы каждая команда могла фиксировать / продвигать свою собственную работу в ветке env без такой сложной процедуры? Какую архитектуру лучше всего использовать в этом случае, как изолировать каждый пакет другим с помощью symfony? Или что вам нужно сделать, если вы уже испытали то же самое? Зная, что моя платформа DevOps основана на wercker CI, она создает одно большое докер для изображений со всеми пакетами Symfony и развертывает его на Amazon ecs.
Хорошо, мистер Алекс, чтобы задать вопрос другим способом, который может вас заинтересовать, если вы испытываете то же самое, какова лучшая архитектура, рабочий процесс веток, решение для развертывания, которое следует использовать, чтобы ваши команды могли вводить свои PR и легко внедрять их изменения.
Описанный здесь сценарий довольно распространен: вы не разделите код только потому, что, возможно, вы получите меньше конфликтов во время слияния. Вы разделяете код из-за многих вещей (разделение, микросервисы, "SRP" и так далее ...) ИМХО, каждый разработчик должен переустанавливать свою ветку несколько раз в день (если у вас частая интеграция в исходной ветке), чтобы избежать кошмара слияния . Конфликты являются частью этого процесса, и вы не сможете их избежать, даже если разделите код на одну строку для каждого репозитория git.
Я ищу не решение, позволяющее избежать конфликтов, а решение изолировать пакет symfony в отдельных репозиториях git. Во избежание слияния работы других команд. Иногда только одна команда должна вносить свои изменения в производство, проблема здесь в том, что они должны перебазировать, чтобы избежать нескольких десятков коммитов (это одно репо, все остальные команды совершают в той же ветке разработки), а в некоторых ситуациях это вообще невозможно Итак, что делать, чтобы упростить этот процесс.
Ответы 4
Вы можете использовать подмодули или разделить свое приложение с помощью подмодулей git или с использованием структуры композитора, это означает, что весь ваш пакет должен потребоваться композитору при создании приложения в вашем CI, и поэтому вы можете свободно продолжать свои DevOps
Приятно, но подмодули также могут быть сложными в некоторых ситуациях, точнее во время процесса сборки
Я рекомендую использовать микросервисную архитектуру, каждый пакет должен быть отдельным проектом, поэтому ваши команды могут размещать свой код в отдельном репозитории git, нет необходимости иметь один большой проект, в котором все вносят свои изменения в одну и ту же ветвь разработки, что означает, что каждый PR может содержать изменения всех остальных разработчиков. Микросервисы могут быть решением, это очень дорого в установке в качестве архитектуры, но я думаю, что это лучшее решение для таких проектов.
Я думаю, что это очень дорогая в реализации архитектура, которая представляет для меня революцию, у меня нет на это времени и ресурсов. Спасибо :)
Предыдущее решение для микросервисов, которое было предоставлено @ imane-bahiaoui, кажется хорошим выбором, особенно с новой версией symfony 4, которая идеально подходит для микросервисов. Но принимая во внимание ваш комментарий, я рекомендую разделить ваш проект на несколько репозиториев git и использовать composer для объединения всего этого, как если бы это был один проект во время процесса сборки на вашем сервере CI или в локальной среде, вы должны обратить внимание на семантическое управление версиями ваши связки.
Примером этого является файл composer.json с исходным кодом фреймворка Laravel:
https://github.com/laravel/framework/blob/5.6/composer.json
"replace": {
"illuminate/auth": "self.version",
"illuminate/broadcasting": "self.version",
"illuminate/bus": "self.version",
"illuminate/cache": "self.version",
"illuminate/config": "self.version",
"illuminate/console": "self.version",
Вы можете привести мне реальный пример?
вы можете взглянуть на некоторые современные фреймворки composer.json, такие как фреймворк laravel: github.com/laravel/framework/blob/5.6/composer.json, взгляните на раздел replace
Если вы не можете разделить код в разных подпроектах / пакетах, которые будут поддерживаться в их собственном репозитории и отдельно требуются композитору, самый простой и чистый способ справиться с большими командами, работающими с большими функциями, - использовать git flow.
По сути, он использует отдельную ветку для каждой новой функции, созданную и в конечном итоге объединенную обратно в общую ветку разработки, когда функция готова для постановки / тестирования.
Вы можете увидеть здесь хороший обзор
https://datasift.github.io/gitflow/IntroductionGitFlow.html
Вы не получите разделения кода, но если вы сохраняете четко определенные функции и имеете твердую архитектуру, слияние должно полностью контролироваться.
Дополнительным преимуществом является то, что поток поддерживается многими инструментами.
Это именно то, что я использую сейчас, но это все еще недостаточное решение, почему? Все завершенные функции находятся вместе в одной ветке. Предполагая, что коммерческая команда хочет внедрить функцию X в prod, на данный момент у нас есть 15 завершенных новых функций в dev env, это означает, что нам нужно искать ветку X в истории git, чтобы внедрить ее в prod env, это далеко не так просто в реальности. Поскольку в некоторые другие ветки в prod может быть передано больше недавних, поэтому для внедрения X вы должны управлять очень сложным процессом перебазирования. Моя тюрьма состоит в том, чтобы максимально упростить этот процесс.
gitflow уже предлагает решение для этого. Только ветви функций, запланированные для следующего выпуска, должны быть объединены в основную ветвь разработки. Проверьте 3-ю диаграмму по ссылке
И если вы действительно не доверяете своим командам, что они не делают глупостей, возможно, вы могли бы использовать ветвления функций fork и pull request. Это также может хорошо интегрироваться с вашим CI (как в pull, только если тесты пройдены и т. д.)
Вы ищете рабочий процесс функциональной ветки? Понятия не имею, ваш вопрос не имеет смысла. И состояние, в котором он сейчас находится, слишком широкое для SO.