Застряли на выборе модели ветвления Git? Эта статья поможет вам определиться.
Это всегда одна и та же история. Я присоединяюсь к новому проекту с новой командой, в восторге от того, что мы собираемся создать вместе. Создание программного обеспечения — это командный вид спорта, поэтому ключевое слово здесь — «вместе». Мы вместе проводим мозговой штурм и вместе проектируем. Но, к сожалению, большую часть времени мы программируем в одиночку. Как всегда, мы быстро вспоминаем, что весь наш код должен быть потом каким-то образом слит, и так история повторяется. Мы снова выбираем модель ветвления.
Если ваша команда также сталкивается с дилеммой выбора модели ветвления, продолжайте читать. В этой статье я собрал множество мыслей, фактов и точек зрения, которые позволят вам поднять эти обсуждения с вашей командой далеко за пределы уровня «вот как мы делали это в моей предыдущей команде».
Мы снова выбираем модель ветвления
Для удобства я разделил это на разделы:
- Культура и ценности
- Сравнение моделей
- Лучшие практики
- Ключевые метрики
- Данные из мира для поддержки вышеизложенного (чтобы мы могли максимально ориентироваться на данные)
Культурные ценности и принципы
Поскольку DevOps является одним из побочных продуктов Agile, он сильно зависит от культуры.
С самого начала Agile всегда отдавал приоритет следующим ценностям:
- Сотрудничество и общение: Люди и взаимодействие важнее процессов и инструментов (agile-манифест 2001 г.)
- Простота: работающее программное обеспечение, а не исчерпывающая документация (agile-манифест 2001 г.)
- Обратная связь: реагирование на изменения вместо следования плану (agile-манифест 2001 г.)
- Смелость: психологическая безопасность, чтобы чувствовать себя в безопасности, рискуя
Принципы
- Иметь легкий и понятный процесс изменений
- Стремитесь к разработке на основе ствола как к идеалу
- Непрерывная интеграция
- Непрерывная доставка (зависит от разработки на основе CI и Trunk)
Приведенные ниже модели и практики в настоящее время являются современными в плане поддержки и реализации этих ценностей и принципов.
Модели
Модель утопии (обычно неосуществимая)
Прямо в ствол, подходит для 1–100 разработчиков
Что это
Практически никаких веток.
Когда вы готовы к коммиту — вы просто делаете коммит в основную ветку (транк).
Преимущества
- Настоящая непрерывная интеграция.
- Не нужно пиар-циклов.
- Может легко доставлять небольшие приращения стоимости.
Задачи
- Нужна очень комплексная сборка.
- Полная сборка должна выполняться перед каждой фиксацией и отправкой (и локально).
- Повышенный риск взлома кода для всех.
Следующее лучшее после модели утопии
Модель краткосрочных ветвей (SLB), подходит для 2–1000 разработчиков
Что это
- Только одна долгоживущая ветка
- Короткие ветки (разрыв отношения ветки-функции 1: 1)
- Ветки живые ‹ 1d
- Приходится открывать PR для слияния
Преимущества
- Полная сборка может быть отложена
- Меньший риск взлома кода для всех
- Может вести работу в одиночку (тоже недостаток)
- Нет необходимости в зависании кода*
Задачи
- Нужно отвлечь другого разработчика от его потока для PR (переключение контекста)*
- Риск вложить слишком много работы в одну ветку*
- Принудительная линеаризация коммитов может создать узкое место для PR
- Может вести работу в одиночку и изоляцию разработчика
*посмотрите решения в «лучших практиках» ниже
Современные рекомендации
Используйте их, чтобы облегчить вышеуказанные проблемы (фактический успех зависит от культуры).
Парное программирование
Парное программирование — это, по сути, онлайн-ревью кода.
Устраняет дорогостоящее переключение контекста. Парный запрограммированный PR, по сути, уже одобрен автоматически (до такой степени, что PR можно автоматизировать)
Меньшие коммиты
Кратковременные ветки помогают выполнять небольшие коммиты.
Чем крупнее изменения, тем больше времени требуется для проверки и утверждения.
Большие затраты на PR:
- Высокие затраты на переключение контекста для автора и рецензентов из-за того, что они постоянно ходят туда-сюда, пока не будет достигнуто соглашение.
- Более высокий риск проскальзывания ошибок из-за более сложных для понимания изменений
- Вредит производительности и снижает пропускную способность
Объединить направления
Перебазируйте, чтобы обновить ветку перед открытием PR.
Это помогает сохранить вашу ветку — о ваших изменениях (в отличие от слияния, которое смешивает все вместе).
Сохраняйте линейную и чистую историю
Squash при объединении PR с main для ясной, чистой и легко просматриваемой истории
Релизы не обязательно должны быть ветками
Релиз может быть вырезан из тега на основном.
Для устранения проблемы в рабочей среде ветка релиза может быть создана задним числом из тега(и выбрано из основного).
Выборочные исправления от основной до ветки релиза
Это избавит от необходимости замораживать код.
Нет необходимости в подверженных ошибкам многоветвевых слияниях (как в git-flow).
История останется читаемой, чистой и ясной (и поддающейся аудиту). .
Прервите отношения между функциями и ветвями 1:1.
Функция не является ветвью. Если вы используете Jira или аналогичную систему и привыкли называть ветки именами задач, попробуйте перестать связывать жизненный цикл ветки и тикета. Многие маленькие и недолговечные ветки в порядке.
КПЭ и показатели
Краткий список вещей, которые нужно измерить, позволит вам почувствовать опыт разработчиков и выявить узкие места в скорости разработки.
- Время от PR до одобрения (часы — хорошо, дни — плохо)
* дополнительные данные в разделе «данные» ниже - Скорость фиксации (чем больше, тем лучше)
- Среднее время сборки (в идеале должно быть меньше времени между фиксациями)
- Общая производительность доставки
- Время выполнения: сколько времени от фиксации до развертывания (сильно зависит от первых трех)
- Интенсивность отказов изменений: сколько развернутых изменений вызвало ухудшение/сбои службы.
- MTTR: среднее время восстановления обслуживания
Интересные данные, которые мы видим в мире
Социолог Рон Веструм создал модель культуры, в которой он определяет следующую типологию организаций (Westrum 2014). Он обнаружил, что это определение организационной культуры предсказывает результаты деятельности.
Двухлетнее исследование Google дало аналогичные результаты (https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/)
Статистика проверки кода из «Современной проверки кода: пример из Google» (2018 г.)
- 80 % — это изменения в одном файле (более 10 % — это однострочные изменения).
- Среднее время проверки кода — 4 часа.
- Медиана авторов-разработчиков 3 изменения в неделю
- Среднее количество изменений, просматриваемых в неделю, составляет 4 (разработчиком).
Как понимание должно измениться в зависимости от ожидаемого результата проверки кода
Карта возможностей производительности доставки (отчет о состоянии DevOps, 2019 г.)
Когда дело доходит до коммитов — чем меньше, тем лучше.
Эффективность доставки
Отчеты о состоянии DevOps из года в год показывают, что самые эффективные команды:
- Развертывайте наиболее часто
- Минимальное время на внесение изменений (от кода, переданного в производство)
- Максимально быстро восстановить сервис в случае сбоя
- Сбои реже (% неудачных развернутых изменений)
Смельчаку, достигшему этого момента, я горжусь тобой.
Комментарии, мысли, данные и опыт приветствуются в комментариях ниже.
