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

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

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

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

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

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

После того как вы отметите задание как выполненное, его может просмотреть коллега.

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

Проверка является необязательным этапом.

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

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

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

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

Если тесты пройдут, слияние будет проверено, и ветка будет готова к отправке. Обратите внимание, что статус теперь установлен на "объединено".

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

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

В 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 в приведенном выше примере были исправлениями ошибок, а не задачами. Вы же не хотите, чтобы одно зависело от другого. Вы хотите, чтобы они попали на главную и были освобождены как можно быстрее. Даже если они касаются одного и того же кода, это разные исправления.

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

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

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

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

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

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

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

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

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