Как реализовать рабочий процесс ветки задач

Процесс начинается с задачи в вашей системе отслеживания проблем или управления проектами: Jira, Bugzilla, Mantis, OnTime или ваше собственное внутреннее решение. Ключевое здесь в том, что все, что вы делаете, должно иметь связанную задачу. Не имеет значения, является ли это частью новой функции или исправлением ошибки – создайте для этого задачу.

Затем вы создаете ветку для этой задачи.

Мы рекомендуем простую конвенцию именования веток: Префикс ("задача" в примере), за которым следует номер задачи в системе отслеживания проблем. Это помогает вам сохранять полную прослеживаемость изменений.

Работайте над веткой задач и делайте столько коммитов, сколько необходимо. Объясните каждый шаг в комментариях, чтобы обеспечить ясность для любого рецензента.

Когда задача выполнена, установите атрибут "статус" на ветке как "решено".

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

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

Теперь очередь рецензента посмотреть на ваши изменения и увидеть, может ли он обнаружить ошибки, недочеты или несоответствия в вашем стиле кодирования, или любые аспекты дизайна, которые следует изменить. Если это так, задача будет повторно открыта, и цикл начнется заново.

Валидация является необязательным шагом.

Некоторые команды будут «валидировать» задачу – другой член команды проведет короткое исследовательское тестирование, чтобы убедиться, что новая функция или изменение имеет смысл. Они не ищут ошибки (автоматизированные тесты занимаются этим), а рассматривают изменение с точки зрения клиента. Статус может быть установлен на «валидирован» в атрибуте.

Настройте вашу систему непрерывной интеграции (CI) для мониторинга всех веток, у которых установлен данный атрибут. Ветка будет рассматриваться системой CI только тогда, когда она достигнет заданного статуса (в данном случае, «валидирован»).

После того как задача будет проверена/валидирована, ветка задачи автоматически тестируется перед слиянием с основной.

Если тестовый набор проходит слияние, оно будет подтверждено и отправлено в систему CI для сборки и тестирования. Этот процесс помогает предотвратить поломку сборки. Если он не проходит, процесс будет перезапущен, и вам придется сделать rebase от основной ветки, чтобы решить любые конфликты.

Если тесты проходят, слияние фиксируется, и ветка теперь готова к доставке. Обратите внимание, что статус теперь установлен на «слито».

Если новый релиз готов к развертыванию, новый набор изменений на основной ветке помечается как таковой, и программное обеспечение разворачивается в производственной среде.

Вы можете получить новый релиз после того, как каждая новая задача пройдет через этот цикл, или вы можете решить сгруппировать несколько задач. При практике непрерывного развертывания развертывание каждой задачи в производственной среде является наиболее логичным рабочим процессом.

С помощью Unity Version Control шаг автоматического тестирования и слияния можно настроить с использованием плагина для вашего выбранного инструмента CI, такого как Jenkins, Bamboo или Unity Cloud Build.

Этот шаг также можно организовать с помощью функции mergebot Unity Version Control. Mergebot может объединять ветки и запускать сборку, чтобы убедиться, что все работает. Слияния подтверждаются только в том случае, если сборка хорошая, что позволяет избежать сломанных сборок.

Мы предпочитаем придерживаться следующей схемы именования: префикс + номер задачи. Например, ветки могут называться task1213, task1209 и task1221. Префикс — это «task», а номер представляет собой фактический номер задачи в связанном трекере проблем.

Скриншот также показывает описание для каждой ветки вместе с номером, так как проводник веток получает номер из трекера проблем. Вы также можете увидеть описание ветки, выбрав «отобразить информацию о задаче ветки».

Правила Scrum гласят, что задачи не должны длиться более 16 часов. Эта практика помогает контролировать сроки проекта.

Ветки задач должны закрываться быстро. В идеале у вас должно быть много небольших задач, которые вы можете закрыть всего за несколько часов. Эта структура помогает поддерживать ритм вашего проекта и облегчает непрерывное развертывание. Более крупная задача, которая длится неделю, например, останавливает цикл.

Одно красное знамя, о котором стоит помнить: Не создавайте задачи "рубленого мяса". Если вам нужно разбить задачу на более мелкие части, убедитесь, что задача все еще имеет смысл в изоляции и может быть развернута независимо.

Рабочие процессы веток задач могут быть успешными только при поддержке всей команды.

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

Спросите себя (или своих товарищей по команде): Вам действительно нужен код, который вы только что закончили в задаче 1213, чтобы начать задачу 1209?

Задачи, как правило, гораздо более независимы, чем вы могли бы подумать. Да, они могут быть на одну и ту же тему, но вам не нужно касаться точно того же кода. Вы можете просто добавить что-то новое и довериться слиянию, чтобы оно выполнило свою работу.

Предположим, что 1213 и 1209 в приведенном выше примере были исправлениями ошибок, а не задачами. Вы не хотите, чтобы одно зависело от другого. Вы хотите, чтобы они попали в основную ветку и были выпущены как можно быстрее. Даже если они касаются одного и того же кода, это разные исправления.

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

Оставление деталей в комментариях к вашему внесению изменений поможет рецензенту, так как ему не нужно будет сравнивать всю ветку. Вместо этого они будут сравнивать изменения по каждому набору изменений. И они будут следовать заранее записанному объяснению, которое вы сделали, чтобы прояснить каждый этап задачи. Они не окажутся перед смелым списком из более чем 100 измененных файлов. Вместо этого они будут двигаться шаг за шагом.

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

Это небольшая цена за преимущества автоматизации. Команда должна согласовать определение "завершено", что означает "готово к производству". Взамен вы можете наслаждаться спокойствием, зная, что перенос вашей задачи в производство прост, полностью автоматизирован и не приведет к экстренной ситуации в 2:00 ночи.

Что такое переключатели функций? Они критически важны для непрерывного развертывания. Эта техника разработки программного обеспечения позволяет тестировать функции до их завершения и готовности к выпуску.

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

Давайте рассмотрим пример. У вас есть большая функция, разделенная на семь частей, которые будут преобразованы в задачи и реализованы с помощью веток задач. Как возможно развернуть Часть 4, если ничего другого не готово?

Часть 4 может быть объединена с основной веткой и даже развернута, оставаясь скрытой с помощью переключателя функции.

Скрытый не означает, что новый код пропускает тестирование перед выпуском. Когда вся функция будет готова к активации, отдельные части уже будут протестированы несколько раз. Интеграция последнего элемента не вызовет большого слияния; это просто меньшая часть, проходящая в основное.