На моем последнем рабочем месте у нас был поток, похожий на «поток git», но у нас было три непрерывных ветви вместо новых веток релиза для каждого выпуска.
- Разработка
- Постановка/ Release (на оставшуюся часть поста я назову это release)
- Master
У нас была автоматизация в Jenkins, поэтому в любое время QA могла перенести всю ветку Develop в Release иначните тестировать доступную работу.
Все исправления этой работы были сделаны в ветке релиза, чтобы изолировать текущую сборку от нежелательных изменений при разработке, а затем были объединены в разработку после завершения.
Идея заключалась в том, что ветвь релиза была полностью изолированной сборкой, и в любой момент времени, если QA доволен состоянием ветки релиза, они могли нажать другую кнопку в Jenkins и автоматически развернуть всю ветку в рабочем состоянии и отметить ее..
- Разработка была историей работы
- Релиз был историей тестируемых сборок
- Master был официальной версией
На моем новом рабочем месте в настоящее время я единственный, кто работает над моим конкретным проектом, и не было никакой автоматизации или надлежащих потоков Git, настроенных такМой план состоял в том, чтобы продолжать использовать то, что я использовал годами, но другие проекты используют стандартные потоки Git, и мы обсуждали различия и тому подобное.
В их потоках - QA - этотестирование отдельных заявок вне разработки, и только когда планируется выпуск действительного релиза, они помещаются в новую ветку релиза для дополнительного тестирования.С этого момента мы следуем тому же потоку, в котором исправления ошибок происходят в ветке релиза и объединяются в разработку.
Мы обсуждали, какой способ работает лучше, но, использовав мой поток в течение многих лет, я 'Я не могу найти в Интернете ничего, что говорит о его сильных или слабых сторонах, чтобы поддержать меня, и мне интересно, есть ли с этим проблемы, о которых я не подозреваю, поскольку это, казалось, работало действительно хорошо?Я либо не справляюсь со своим googlefu, либо удивляюсь, что не могу найти существующее обсуждение?Я также вижу несколько проблем с их способом, который мог бы решить мой метод?
При моем текущем способе
- У меня есть стабильная среда QA, которая может быть выпущена в любой момент.
- QA никогда не нужно беспокоиться о том, что происходит в Develop, пока они не хотят новой работы.
- У меня есть история уникальных сборок в Release, которую всегда легко найти
- Я всегда сливаюсь с головы веток.
С другой стороны,
К моменту тестирования сборки разработка уже продвинулась вперед.Если QA хочет развернуть эту сборку в рабочей среде, им теперь нужно выбрать момент времени и создать из него ветку выпуска (которая может быть подвержена ошибкам, поскольку это больше не ветка HEAD)
Одна из наших основных сред тестирования всегда представляет текущую базу кода разработки, поэтому, когда разработка прерывается, веб-сайт ломается и не может быть протестирован.
Есть ли какие-тонедостаток в методе ветвления непрерывного выпуска, который мне не хватает, по сравнению с потоком отдельных веток релиза, когда релиз готов к сокращению?
Мне кажется, что более простое развертывание в производственной среде с непрерывной ветвью?Даже если они сразу же прекратили тестирование из-под разработки и создали уникальную ветку релиза, какое преимущество это имеет по сравнению с непрерывной веткой, помеченной тегом?
Примечание - я был не из тех, ктоПервоначально настроил это на моем последнем рабочем месте и настроил автоматизацию в первый раз.Есть ли у них проблемы с автоматизацией, с которыми я столкнулся в моем методе по сравнению с обычным потоком мерзавцев?