Что такое рабочий процесс на основе выпуска?
Здесь мы обсудим, как можно создать рабочий процесс на основе выпуска с помощью GitHub.
Что такое рабочий процесс на основе выпуска?
Рабочий процесс на основе выпуска — это набор шаблонов и политик, относящихся к выпуску программного обеспечения. Хотя это понятие может показаться очевидной целью для команды разработчиков, ценность этой перспективы более нюансов. В этом уроке мы обсудим, как он управляет тремя различными частями цикла выпуска: управление проектом, выбор стратегии ветвления и выпуск для клиентов.
Планирование работы с помощью досок проектов GitHub
С точки зрения планирования, рабочий процесс на основе выпуска означает, что проблемы делятся на отдельные итерации, создающие новую версию. Эти итерации часто называются спринтами и группируются в примерно равные по времени периоды для получения поэтапных изменений. Другие команды предпочитают делать целые версии выпуска едиными итерациями, которые могут занимать по нескольку месяцев или дольше. В GitHub эти итерации управляются как проекты.
Главным компонентом проекта является его доска. Доска является центральным планом записи для итерации и содержит все карточки, которые нужно разрешить. Карточка может представлять собой вопрос, запрос на вытягивание или даже просто общую заметку.
По умолчанию каждая карточка начинает существование в столбце Надо выполнить, переходит в Выполняется после начала работы и наконец оказывается в Готово. Вы можете настроить эти столбцы, добавить дополнительные столбцы или применить автоматизацию к перемещению этих карточек и их свойств, чтобы соответствовать процессу вашей команды.
Дополнительные сведения об управлении досками проектов.
Состояние проекта карточки является интегрированным для всего репозитория. Например, перетаскивание карточки из "Чтобы выполнить" изменяет его состояние и обновляет визуальный индикатор рядом с заголовком проекта. Зеленый раздел указывает часть карточек, помеченных как Готовые, а сиреневые используются для карточек, которые Выполняются. Оставшееся пространство представляет собой карточки, которые еще не были начаты. Помимо перетаскивания карточек по доске, их можно обновить в основном представлении.
При использовании доска проекта все заинтересованные лица могут легко понять состояние и скорость проекта. Вы также можете создавать доски, область действия которых ограничена отдельными пользователями или коллекцией репозиториев, принадлежащих организации.
Дополнительные сведения об отслеживании хода работы с помощью досок проектов.
Отслеживание конкретных вех
Для команд, или, возможно, для подгрупп внутри команд, 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.