Требуется магистральное развитие

Question

Я искал хорошие ресурсы по стратегиям ветвления после того, как занимался ветвлением функций в течение нескольких лет и боролся с множеством ветвей и кошмаров слияния. Функциональные ветки дали нам хорошую изоляцию в управлении выпусками довольно детальным образом относительно того, какие функции должны идти в выпуске. Тем не менее, проблемы, которые они ставили (многие отрасли, конфликты слияний) были намного больше, чем выгоды, которые они давали.

Мы работаем с базой данных Oracle (с 5000 объектами) на заднем плане. У нас также есть несколько команд, работающих над разными областями одного и того же продукта. Мы используем Visual Studio с TFS (без DVCS).

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

Мы внедряем scrum и ищем модель ветвления, которая будет соответствовать нашему циклу выпуска (4 раза в год) и сборкам CI. Мы планируем сделать 5 регулярных спринтов и 1 закалку для каждого релиза.

От модели ветвления объектов мы переработали нашу модель ветвления до очень простого ветвления, как показано ниже:

Ветвь разработки работает так, как наша "Trunk" (для разработки на основе Trunk) и ВСЕ разработчики (все команды) принимают участие в этой ветке (для ежеквартального выпуска), тестеры проводят тестирование в этой ветке, а CI-сервер (Jenkins) строит эту ветку ежедневно, Мы просто нуждаемся в чистом ГЛАВНОМ в любое время для безопасности как "Единый источник правды для последнего выпуска", который часто используется по нескольким причинам.

Ветка по обслуживанию - это наша ветка по исправлению ошибок (исправление), которая выпускается несколько раз в течение года (независимо от ежеквартального выпуска). Мы предпочитаем не работать напрямую с основной веткой, так как хотим иметь "чистую" главную ветку. Мы не хотим выпускать код в Main без "ручного" / функционального тестирования. По завершении выпуска исправления ошибки код объединяется из раздела "Обслуживание" -> "Основные" -> "Разработка" для интеграции исправлений ошибок в разработку.

Как правило, нам не требуются "ветки релиза", как предложено в TBD, поскольку мы будем постоянно исправлять ошибки в ветке техобслуживания, выпускать из техобслуживания, а затем объединять изменения с основной (а затем с разработкой). Мы поддерживаем только "Последний выпуск", и в случае, если требуется предыдущее исправление, мы создаем старую ветку релиза из Labels in Main.

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

См:

http://paulhammant.com/2013/12/04/what_is_your_branching_model

http://paulhammant.com/2013/04/05/what-is-trunk-based-development/

Answer 1

Вы должны сделать ветку maintence из выпущенного тега, только если вы столкнулись с ошибкой. На самом деле это ветка релиза, и она должна быть названа в честь релиза. Скажите rel_1.1. К тому времени, когда вы выпустили релиз 1.2, и стало ясно, что вы не собираетесь откатываться, удалите rel_1.1.