Есть ли способ разрабатывать / выпускать функции «когда будет готово» без использования веток контроля версий?

Question

Моя команда уже некоторое время использует Continuous Integration, используя подход «все идет в транке». Мы изучаем возможность изменения этой практики, чтобы позволить нам выпускать отдельные функции, как только они будут готовы, без необходимости ждать, пока другие функции догонят (у нас есть несколько команд, работающих над различными функциями одновременно). Существует множество примеров того, как сделать это с помощью стратегий ветвления (ветвление на элемент и т. Д.), Использования git и т. П., И это, вероятно, мой предпочтительный подход. Но менеджеры попросили нас по крайней мере исследовать другие варианты, потому что беспокойство заключается в том, что стратегия ветвления может привести к отсроченным точкам интеграции, которых мы хотим избежать. Однако я не хочу, чтобы это обсуждалось со стратегией CI / ветвления, поэтому я постараюсь быть более конкретным в своем вопросе.

Кто-нибудь использовал какие-либо стратегии для выпуска функций, когда они были готовы, без запуска нескольких ветвей контроля версий? Например, используя Ветвление по абстракции или какой-либо другой способ иметь функции с различными состояниями «готовности» в одной ветви. Если у кого-то есть опыт (хороший или плохой) с таким подходом, я бы хотел знать.

Answer 1

Механизм ветвления по абстракции нелегко масштабируется для больших проектов с устаревшей архитектурой, потому что указанный "уровень абстракции" не всегда легко / быстро внедрить, чтобы изолировать ваши изменения.

Однако другая идея, упомянутая в этой статье, состоит в очень небольшом числе ветвей, и только коммиты представляют приложение , готовое к развертыванию .
Это то, что DVCS (Децентрализованные VCS, такие как Git или Mercurial) может легко приспособиться благодаря механизму публикация (, ортогональному ветвлению ), и который позволяет:

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

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

Answer 2

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

Таким образом, рабочий процесс, запускающий новую функцию:

Клонируйте функцию агрегата репозитория CI, регулярно извлекая из репозитория CI Окончательное извлечение из репозитория CI, затем добавляйте функцию в CI Push из CIв релиз репо.

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

С этим решением вам никогда не нужно будет создавать ветки.