Я разработчик программного обеспечения в довольно большой гибкой команде (у нас есть восемь разработчиков, активно вносящих изменения в один репозиторий кода). Каждые две недели мы запускаем новую версию нашего программного обеспечения. Вот наш текущий рабочий процесс:
- При запуске новой задачи разработчики создают «ветку возможностей» из основной ветки разработки (мы используем git ) и отрабатываем эту новую ветку.
- Как только разработчик завершил работу над своей задачей, он объединяет свою функциональную ветвь с веткой разработки.
- Разработчик объединяет ветку разработки в ветку QA.
- Сборка запускается из ветви QA. Выходные данные этой сборки развернуты в нашей среде QA, чтобы позволить тестировщикам начать тестирование.
Наши тестировщики довольно часто находят проблемы с этими новыми функциями, которые были объединены в ветку QA. Это означает, что в любой момент времени среда QA, вероятно, содержит несколько новых функций - некоторые протестированы и не содержат ошибок, а некоторые не работают. Это затрудняет выпуск, так как сборка QA редко находится в состоянии готовности к работе.
Чтобы смягчить это, мы пытались инициировать «зависание QA», что означает, что разработчики не объединяют нашу ветку разработки с веткой QA за пару дней до релиза. Исправления ошибок в среде QA производятся непосредственно в ветви QA и объединяются в ветку разработки. Теоретически, это не позволяет использовать новые, нарушенные функции QA, но в то же время позволяет исправлять проблемы уже в QA.
Хотя эта концепция «заморозки QA» была частично успешной, ее сложно координировать, и люди часто не понимают, разрешено ли им сливаться с QA. Также было трудно установить конечный срок "заморозки QA" - всем нравится идея о некоторой передышке между заморозкой и выпуском, но на практике они предпочли бы иметь свою особенность в следующем выпуске, чем соблюдать крайний срок.
Есть ли лучший способ обеспечить чистую сборку наших выпусков каждую неделю?
Ответы:
Есть несколько проблем, которые вызывают проблемы, которые вы испытываете.
Первый - это долгосрочное отделение QA. Наличие ветки с длительным сроком действия, параллельной основной линии разработки, может стать источником путаницы, поскольку необходимо предпринять различные усилия для репликации как в ветви QA, так и в основной линии. Это означает, что либо вы проверяете исправления в ветке QA, которые должны быть объединены с основной линией (неплохая вещь), либо вы проверяете основную линию, которая сливается с веткой QA (источником возможных ошибок) ,
Другая проблема с долго работающей параллельной ветвью заключается в том, что файлы могут постоянно не синхронизироваться. Исправление кода, которое никогда не будет объединено, или конфигурация, необходимая для производственных сборок, которые никогда не тестировались и являются частью основной разработки.
Затем у вас есть роли, на которые оказывают влияние. Это означает, что роль упаковки (подробнее об этом позже) недостаточно изолируется.
В модели git-flow ветвь релиза отделена от разработки ( не разработка объединена с QA), и все исправления проверены в ветке релиза и затем объединены обратно с веткой разработки.
Некоторая философия ветвления может быть найдена в Расширенных стратегиях ветвления SCM (я считаю, что это отличное чтение). Это сосредотачивается на ролях, которые каждая ветвь может взять на себя. Ветвь релиза берет на себя роль упаковки.
Нужно серьезно рассмотреть применение всего потока мерзавцев на месте. Это не слишком далеко от того, что делается в настоящее время, и вносит некоторую дисциплину и последовательность в то, что означает каждая ветвь и как каждая ветвь взаимодействует с другими.
источник
Мне кажется, проблема в том, что у вас есть одна ветвь контроля качества.
Для каждого выпуска создайте отдельную ветвь QA из основной магистрали разработки / master. Затем объедините только исправления ошибок для функций в этой ветви, а не новые функции. Пусть QA протестирует эту ветку.
Таким образом, «заморозка» вполне очевидна - это название ветки. Вы могли бы использовать что-то вроде, я не знаю
release/26/10/2015
. Тогда очевидно, что никто не должен сливаться с новыми функциями после этого.Это особенно полезно, если вы даже не разветвляете ветку до замораживания. Люди могут присоединиться к мастеру в любое время, просто он не будет частью этого выпуска, если он не будет сделан вовремя для его тестирования.
Не имейте ни одной продолжительной ветки QA, это просто напрашивается на неприятности. Форк из основной ветки разработки для каждого релиза и QA этой ветки.
источник
Вы в некоторой степени сопоставлены с моделью ветвления Development-MAIN-Production, показанной ниже. Зона над ГЛАВНОЙ, как говорят, является областью развития. Область ниже ГЛАВНОЙ является производственной зоной.
Основные характеристики этой модели, которые я считаю актуальными для вас:
Я подозреваю, что у вас есть проблемы, потому что:
источник
Насколько я понимаю вопрос у вас две проблемы. (а) сломанные функции объединяются с хорошими функциями, которые вы хотите выпустить; (б) вы хотите быть в состоянии выпустить хорошие функции, сдерживая сломанные. В качестве ограничения возможных решений, я предполагаю, что вы хотите, чтобы ваше окончательное / официальное тестирование QA проводилось в интегрированной ветви, которая содержит все функции, запланированные для следующего выпуска.
Независимо от вашей модели ветвления SCM, я предлагаю вам попробовать одно или оба из следующих:
источник
Одно очень простое решение, которое, как я видел, работает в команде, которая немного больше вашей, - это заставить всех работать и развертываться из одной ветви.
Вы говорите, что команда гибкая, но неясно, работаете ли вы в спринте (например, в Scrum) или в подходе с более непрерывным потоком (например, в Kanban). Предполагая, что вы делаете спринты, цель команды состоит в том, чтобы код выпускался в конце каждого спринта для вашего двухнедельного выпуска. Нет никакой путаницы относительно того, сломает ли одна особенность другую, поскольку все они были разработаны вместе. Тестировщики могут получить доступ к функциям небольшими блоками, поскольку затраты на их разработку для разработчиков ниже. И вам действительно не нужен QA-Freeze, вместо этого все знают, когда конец спринта, и не должны выполнять работу, которую они не могут закончить или оставить в развертываемом (то есть отключенном) состоянии.
Очевидно, что у любого подхода есть свои плюсы и минусы, я представляю это как вариант, не обязательно «лучший способ».
источник
Причина, по которой вы получаете эти проблемы, состоит в том, что ваш код, выпущенный для QA, не достаточно хорошего качества (и кто-нибудь ?!), поэтому вам нужно начать получать лучшую версию для QA, чтобы им не приходилось так часто получать исправления. Самый простой способ сделать это - создать промежуточную ветвь, которую вы выпускаете (назовем ее тестовой). Это все еще находится в стадии разработки, но позволяет разработчикам подтолкнуть его к продолжению работы, а также имеет интегрированную ветвь, которая должна быть достаточно хорошего качества для отправки в QA.
Интеграционное тестирование может проводиться в этой ветви, чтобы найти ошибки, которые в настоящее время обнаруживает QA, ошибки могут быть исправлены в исходной ветви, а затем снова объединены, и снова, пока право или ошибки не будут исправлены непосредственно в этой ветви (я рекомендую бывший). После того, как он прошел множество базовых тестов, он может быть отправлен в QA для проверки «липкие пальцы пользователя и что они сделали?» тестирование.
Таким образом, этот подход предназначен для защиты ветви QA от сломанных функций разработки - независимо от того, была ли эта функция написана недостаточно хорошо или возникли непредвиденные проблемы интеграции, не имеет значения. Только ветки разработчика, прошедшие интеграционное тестирование, могут быть переведены в QA.
источник