Что такое рабочий процесс на основе выпуска?
Здесь мы обсудим, как можно создать рабочий процесс на основе выпуска с помощью GitHub.
Что такое рабочий процесс на основе выпуска?
Рабочий процесс на основе выпуска — это набор шаблонов и политик, относящихся к выпуску программного обеспечения. Хотя это понятие может показаться очевидной целью для команды разработчиков, ценность этой перспективы более нюансов. В этом уроке мы обсудим, как он управляет тремя различными частями цикла выпуска: управление проектом, выбор стратегии ветвления и выпуск для клиентов.
Планирование работы с помощью досок проектов GitHub
С точки зрения планирования, рабочий процесс на основе выпуска означает, что проблемы делятся на отдельные итерации, создающие новую версию. Эти итерации часто называются спринтами и группируются в примерно равные по времени периоды для получения поэтапных изменений. Другие команды предпочитают делать целые версии выпуска едиными итерациями, которые могут занимать по нескольку месяцев или дольше. В GitHub эти итерации управляются как проекты.
Главным компонентом проекта является его доска. Доска является центральным планом записи для итерации и содержит все карточки, которые нужно разрешить. Карточка может представлять собой вопрос, запрос на вытягивание или даже просто общую заметку.
По умолчанию каждая карточка начинает существование в столбце Надо выполнить, переходит в Выполняется после начала работы и наконец оказывается в Готово. Эти столбцы можно настроить, добавить дополнительные столбцы или применить автоматизацию к перемещению этих карта и их свойств, чтобы соответствовать процессу вашей команды.
Дополнительные сведения об управлении досками проектов.
Состояние проекта карточки является интегрированным для всего репозитория. Например, перетаскивание карта из to To do to In progress изменяет его состояние и обновляет визуальный индикатор рядом с заголовком проекта. Зеленый раздел указывает часть карточек, помеченных как Готовые, а сиреневые используются для карточек, которые Выполняются. Оставшееся пространство представляет собой карточки, которые еще не были начаты. Помимо перетаскивания карта вокруг доски, их можно обновить из основного представления.
При использовании доска проекта все заинтересованные лица могут легко понять состояние и скорость проекта. Вы также можете создавать доски, область действия которых ограничена отдельными пользователями или коллекцией репозиториев, принадлежащих организации.
Дополнительные сведения об отслеживании хода работы с помощью досок проектов.
Отслеживание конкретных вех
Для команд, или, возможно, для подгрупп внутри команд, GitHub предлагает вехи.
Вехи похожи на отслеживание проектов в том, что основное внимание уделяется приоритетному завершению проблем и запросам на вытягивание. Тем не менее, где проект может быть сосредоточен на процессе команды, веха сосредоточена на продукте.
Дополнительные сведения об отслеживании хода работы с помощью веха.
Выбор стратегии ветвления
Для репозиториев, в которых несколько разработчиков работают параллельно, требуется четко определенная стратегия ветвления. Решение об едином подходе в начале проекта экономит путаницу и разочарование в масштабе команды и базы кода.
Поток GitHub
Помимо создания платформы для совместной разработки программного обеспечения, GitHub также предлагает предписанный рабочий процесс, предназначенный для оптимизации использования различных функций. Хотя GitHub может работать практически с любым процессом разработки программного обеспечения, рекомендуется рассмотреть поток GitHub, если ваша команда еще не остановилась на процессе.
Работа с долгосрочными ветвями
Долгосрочная ветвь — это ветвь Git, которая никогда не удаляется. Некоторые команды предпочитают вообще их не использовать, применяя вместо них краткосрочные ветви для новых компонентов и исправления ошибок. Для таких команд целью любых усилий является создание запроса на вытягивание, который объединяет их работу обратно в main. Этот подход может быть эффективным для проектов, которые никогда не нуждаются в обратном просмотре, таких как сторонние веб-приложения, которые не поддерживают предыдущую версию.
Однако существуют определенные сценарии, в которых долгосрочные ветви будут полезнее для команды. Наиболее распространенным случаем использования долгосрочной ветви является ситуация, когда у продукта есть несколько версий, которые требуется поддерживать в течение продолжительного периода времени. Когда планы команды должны учитывать это обязательство, репозиторий должен соответствовать стандартному соглашению, например release-v1.0, release-v2.0 и т. д. Эти ветви также должны быть помечены как защищенные в GitHub, чтобы управление доступом на запись было управляемо, и они не могут быть случайно удалены.
Команды должны по-прежнему оставлять main в качестве корневой ветви и объединять изменения в своих ветвях выпуска выше, если они соответствуют будущему проекта. В нужный момент release-v3.0 должна быть основана на main, чтобы обслуживание release-v2.0 не усложнило репозиторий.
Обслуживание долгосрочных ветвей
Предположим, что исправление ошибки было объединено с ветвью release-v2.0, а затем повторно объединено с main выше. Затем было обнаружено, что эта ошибка также существовала в release-v1.0 ветви, и исправление, необходимое для поддержки клиентов, все еще использующих эту версию. Что лучше всего использовать для поддержки этого исправления?
Объединение main ветви release-v1.0 вниз не будет возможным вариантом, так как он будет содержать значительное количество фиксаций, которые не должны быть частью этой версии. По той же причине перебазирование release-v1.0 на текущую main фиксацию не будет вариантом.
Альтернативный вариант — вручную повторно реализовать исправление в ветви release-v1.0, но такой подход требует значительной повторной работы и плохо масштабируется при наличии нескольких версий. Однако Git предлагает автоматизированное решение этой проблемы в виде команды cherry-pick.
Что такое команда выборочного отбора в Git?
git cherry-pick — это команда, позволяющая применять определенные фиксации из одной ветви к другой ветви. Она просто повторяет выбранные фиксации, применяя их к целевой ветви в качестве новых фиксаций. При необходимости разработчики могут объединить любые конфликты перед завершением этого обратного переноса.
Дополнительные сведения о выборочном отборе в Git.
Выпуск для потребителей
Когда версия продукта готова к выпуску, GitHub упрощает процесс ее упаковки и уведомления потребителей.
Создание версии сводится к простому заполнению формы:
- Введите тег Git, который следует применить. Он должен следовать семантическому версионированию, например
v1.0.2. GitHub управляет процессом создания указанного тега Git. - Введите имя своего выпуска. Ниже приведены некоторые распространенные методики.
- используйте описательное имя;
- используйте версию Git;
- С помощью краткой сводки по изменению выпуска с момента предыдущего
- используйте кодовое имя или случайную фразу.
- предоставьте заметки о выпуске. Эту задачу можно автоматизировать с помощью приложения "Черновик выпуска", которое анализирует изменения с предыдущей версии и включает связанные заголовки запросов на вытягивание.
- Если вы хотите предоставить файлы в рамках выпуска, например предварительно созданные установщики, можно перетащить их в форму. Вам не нужно упаковывать исходный код, поскольку GitHub делает это за вас автоматически.
- Укажите, является ли версия предварительной, проверка этого поля. Это означает, что клиенты могут избежать предварительной версии, если они хотят.
После публикации выпуска все пользователи, просматривающие репозиторий, получают уведомление.
Подробнее о выпусках GitHub.