Я искал хорошие ресурсы по стратегиям ветвления после того, как много лет занимался ветвлением функций и боролся с множеством ветвей и кошмарами слияния. Ветви функций действительно давали нам хорошую изоляцию при управлении выпусками с довольно детальной детализацией в отношении того, какие функции должны перейти в выпуск. Однако проблемы, которые они создавали (множество ветвей, конфликты слияния), были намного больше, чем те преимущества, которые они давали.
Мы работаем с базой данных Oracle (с 5000 объектами) на бекенде. У нас также есть несколько команд, работающих над разными областями одного и того же продукта. Мы используем Visual Studio с TFS (без DVCS).
Чем больше веток мы создаем, тем больше экземпляров базы данных нам требуется для обеспечения надлежащей изоляции при функциональном тестировании в этих ветвях (каждая ветка - один экземпляр БД), которые представляют собой еще один набор проблем.
Мы внедряем scrum и ищем модель ветвления, которая будет соответствовать нашему циклу выпуска (4 раза в год) и сборкам CI. Мы планируем провести 5 обычных спринтов и 1 спринт по укреплению на каждый выпуск.
От модели ветвления функций мы переработали нашу модель ветвления до очень простой модели ветвления, как показано ниже -
Ветвь разработки работает как наша «магистраль» (для разработки на основе магистрали), и ВСЕ разработчики (все команды) принимают участие в этой ветке (для ежеквартального выпуска), тестировщики тестируют в этой ветке, а CI-сервер (Jenkins) создает эту ветку ежедневно. . Нам просто нужна чистая ГЛАВНАЯ в любое время в целях безопасности как «Единственный источник истины для последнего выпуска», который часто используется нами по нескольким причинам.
Ветка обслуживания - это наша ветка для исправления ошибок (исправление), которая выпускается несколько раз в течение года (независимо от ежеквартального выпуска). Мы предпочитаем не работать непосредственно с основной веткой, так как хотим иметь «чистую» главную ветку. Мы не хотим, чтобы код уходил на главную без "ручного" / функционального тестирования. После выпуска исправления ошибок код объединяется из раздела «Обслуживание» -> «Главная» -> «Разработка», чтобы интегрировать исправления ошибок в разработку.
Обычно нам не требуются «ветви выпуска», как это предлагается в TBD, поскольку мы будем постоянно исправлять ошибки в ветви обслуживания, выпускать из обслуживания и затем объединять изменения в главном (а затем в разработке). Мы поддерживаем только «Последний выпуск», и в случае, если требуется исправление предыдущего выпуска, мы создаем ветку старого выпуска из ярлыков в главном.
Изменили ли мы разработку на основе магистрали до такой степени, что это вызовет проблемы в будущем? Ваши предложения?
Ссылаться:
http://paulhammant.com/2013/12/04/what_is_your_branching_model
http://paulhammant.com/2013/04/05/what-is-trunk-based-development/#comment-2765204723
