Как мы можем включать готовые к выпуску функции в наши производственные выпуски раз в две недели?

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

• При запуске новой задачи разработчики создают «ветку возможностей» из основной ветки разработки (мы используем 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, получает одну ветку и не сливается с разработкой.
  • Если вы хотите пойти по этому пути с последовательными именами и хуками, можно предотвратить слияние в ветку релиза.
• Исправьте все, что нужно исправить в ветке релиза, и объедините эти изменения с основной веткой.
• По окончании релиза объедините ветку релиза с веткой «Releases Go Here» и отметьте ее как таковую.
  • Некоторые сайты не имеют ветки «релизы идут сюда» и просто оставляют конец ветки релиза с тегом.

Нужно серьезно рассмотреть применение всего потока мерзавцев на месте. Это не слишком далеко от того, что делается в настоящее время, и вносит некоторую дисциплину и последовательность в то, что означает каждая ветвь и как каждая ветвь взаимодействует с другими.

Мне кажется, проблема в том, что у вас есть одна ветвь контроля качества.

Для каждого выпуска создайте отдельную ветвь QA из основной магистрали разработки / master. Затем объедините только исправления ошибок для функций в этой ветви, а не новые функции. Пусть QA протестирует эту ветку.

Таким образом, «заморозка» вполне очевидна - это название ветки. Вы могли бы использовать что-то вроде, я не знаю release/26/10/2015. Тогда очевидно, что никто не должен сливаться с новыми функциями после этого.

Это особенно полезно, если вы даже не разветвляете ветку до замораживания. Люди могут присоединиться к мастеру в любое время, просто он не будет частью этого выпуска, если он не будет сделан вовремя для его тестирования.

Не имейте ни одной продолжительной ветки QA, это просто напрашивается на неприятности. Форк из основной ветки разработки для каждого релиза и QA этой ветки.

Вы в некоторой степени сопоставлены с моделью ветвления Development-MAIN-Production, показанной ниже. Зона над ГЛАВНОЙ, как говорят, является областью развития. Область ниже ГЛАВНОЙ является производственной зоной.

Основные характеристики этой модели, которые я считаю актуальными для вас:

• Ваши разработчики должны (Forward Integrate (FI)) (FI = слияние с MAIN) часто (2-3 раза в неделю) в свои ветви DEV, чтобы их последние изменения всегда учитывали последние общие события.
• Ваши разработчики должны использовать Reverse Integrate (RI) (RI = объединение с MAIN) в ветке TEST только тогда, когда они достигли вехи завершения возможности, которую они хотят представить в QA и для которой они готовы предоставить быстрые исправления в ответ на QA обратной связи. Исправления будут выполнены в ветке TEST и сразу же в FI в их ветке DEV.
• Никогда RI из любой ветки DEV в MAIN
• Всегда RI из ветки TEST в MAIN, только когда ваш QA считает, что качество TEST в порядке. Сохраняйте порог высокого качества для слияния с MAIN. По крайней мере, ваш менеджер по продукту должен иметь возможность всегда демонстрировать рабочую версию вашего продукта из последней фиксации в MAIN.
• Создавайте филиалы в производственной зоне только по мере необходимости. Ваш сервер сборки должен всегда отмечать все ветви, в том числе из области разработки, а источник любой сборки / выпуска должен быть всегда идентифицируемым независимо от ветви, из которой он получен.
• Берите релизы для производства только из ГЛАВНОЙ или производственной зоны. Если позже вам потребуется предоставить исправление для точной выпущенной версии (т.е. вы не можете просто предоставить последнюю версию из MAIN), создайте ветку в рабочей области из тега MAIN неисправного выпуска, когда это исправление необходимо. Всегда устраняйте проблему в ветви HotFix, а затем немедленно отправляйте RI в MAIN и FI в TEST.

Я подозреваю, что у вас есть проблемы, потому что:

• Ваш разработчик RI в тестовый код, который не является вехой
• Ваши разработчики RI в TEST, не получая зеленый свет от QA (т.е. QA не контролирует то, что вводится в TEST)
• Когда QA сообщает об ошибке в TEST, ваши разработчики исправляют ее в своей ветви DEV, а затем пересылают в TEST. Это серьезная плохая практика, потому что объединение всегда будет приводить к другим неполным дерьмовым разработчикам. Они всегда должны исправить это на TEST, а затем FI в своей ветке DEV. Если это невозможно исправить на TEST, они поставили полный дерьмо в первую очередь, и у вас есть большие проблемы.
• Ваши разработчики не используют FI достаточно часто из TEST, поэтому они дестабилизируют TEST всякий раз, когда доставляют туда. Это изобразительное искусство, балансирующее, как часто FI в DEV. Отложите это слишком много, и это будет чрезвычайно дорого и рискованно прямо перед доставкой, чего вы никогда не захотите. Делайте это слишком часто, и вы не получите никакой реальной работы с разработчиками, если вы слишком сильно пересекаетесь с работой, выполняемой другими людьми в TEST за это время.

Насколько я понимаю вопрос у вас две проблемы. (а) сломанные функции объединяются с хорошими функциями, которые вы хотите выпустить; (б) вы хотите быть в состоянии выпустить хорошие функции, сдерживая сломанные. В качестве ограничения возможных решений, я предполагаю, что вы хотите, чтобы ваше окончательное / официальное тестирование QA проводилось в интегрированной ветви, которая содержит все функции, запланированные для следующего выпуска.

Независимо от вашей модели ветвления SCM, я предлагаю вам попробовать одно или оба из следующих:

1. Назначьте ресурс QA каждой особой команде. Пусть они проведут некоторое тестирование функций на сборках из ветви компонентов и дадут им полномочия решать, когда функция достаточно хороша для объединения. В идеале, пусть они работают совместно с (остальной частью) специальной группой, поэтому материал тестируется вскоре после написания. (Обратите внимание, это не означает, что они должны делать все тестирование самостоятельно.)
2. Используйте переключатели функций вместо ветвей функций или в дополнение к ним. Если все сделано правильно, переключатели функций позволяют отключить сломанную функцию, не пытаясь отсоединить ее от кода, чтобы можно было протестировать и выпустить другие функции. Тип переключения, о котором я говорю, недоступен для клиентов; Вы не хотите экспоненциально растущего числа комбинаций для тестирования. Вы устанавливаете переключатели в ветви QA так, чтобы они соответствовали функциям, которые вы планируете выпустить, и если план изменяется из-за того, что функция не готова, вы меняете этот переключатель.

Одно очень простое решение, которое, как я видел, работает в команде, которая немного больше вашей, - это заставить всех работать и развертываться из одной ветви.

Вы говорите, что команда гибкая, но неясно, работаете ли вы в спринте (например, в Scrum) или в подходе с более непрерывным потоком (например, в Kanban). Предполагая, что вы делаете спринты, цель команды состоит в том, чтобы код выпускался в конце каждого спринта для вашего двухнедельного выпуска. Нет никакой путаницы относительно того, сломает ли одна особенность другую, поскольку все они были разработаны вместе. Тестировщики могут получить доступ к функциям небольшими блоками, поскольку затраты на их разработку для разработчиков ниже. И вам действительно не нужен QA-Freeze, вместо этого все знают, когда конец спринта, и не должны выполнять работу, которую они не могут закончить или оставить в развертываемом (то есть отключенном) состоянии.

Очевидно, что у любого подхода есть свои плюсы и минусы, я представляю это как вариант, не обязательно «лучший способ».

Причина, по которой вы получаете эти проблемы, состоит в том, что ваш код, выпущенный для QA, не достаточно хорошего качества (и кто-нибудь ?!), поэтому вам нужно начать получать лучшую версию для QA, чтобы им не приходилось так часто получать исправления. Самый простой способ сделать это - создать промежуточную ветвь, которую вы выпускаете (назовем ее тестовой). Это все еще находится в стадии разработки, но позволяет разработчикам подтолкнуть его к продолжению работы, а также имеет интегрированную ветвь, которая должна быть достаточно хорошего качества для отправки в QA.

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

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