Определяющие факторы

Частота релизов

Есть много факторов, которые создают давление на команду в промежутке между релизами. Вот некоторые из них. There are many factors that put pressure on the team to lengthen the interval between releases. Here are some.

Длина итерации

Разные Agile команды имеют разную длину итерации. Какие-то команды работают с итерациями по 3 недели, какие-то по 2 недели, какие-то по 1 неделе. Какие-то команды не имеют итераций вообще, особенно если они используют технику Continuous Delivery..

Если ваша итерация длится 4 недели или больше, и каждая из этих четырех недель меняется при приближении к релизу и не можете быть изменена, то вы можете быть в затруднительном положении. Вы можете следовать заветам Trunk-Based Development, пользоваться всеми преимуществами Continuous Integration (это возможно в любой модели ветвления), но вы можете быть не в состоянии сделать Continuous Delivery (или Continuous Deployment).

Водопад

Тут все просто. Если вы работаете по водопаду (каскадная модель управления проектами), то до требования “не ломать сборку”, которое нужно для Trunk-Based Development, вам рукой подать. Попробуйте Agile методологии с короткой итерацией, например Экстремальное Программирование.

Объем задачи

В Trunk-Based Development подходе нужно чтобы у вас были задачи небольшого размера. Оптимальное время работы над задачей от начала кодинга до отправки на code review - несколько часов. Если код пишется больше пары дней, то потом придется объединять свой код с кодом других разработчиков в какой-нибудь отдельной ветке и вливать это в trunk. Или, что ещё хуже, из-за вас другим придется создавать ветку от вашей ветки, в которой вы сейчас работаете. Или, что тоже неприятно, забирать код, который был влит в вашу ветку, несмотря на то, что работа сделана не до конца.

В общем, всей команде разработки следует декомпозировать большие задачи на более маленькие. В Agile есть мнемоническое правило INVEST, которое помогает декомпозировать задачи.

Время сборки

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

Выбор системы контроля версий

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

Старые версии ClearCase и PVCS Dimensions делали первую операцию за 30 минут, а вторую за 45 минут. Это время удваивалось если два разработчика одновременно пытались сделать операцию синхронизации/обновления кода. При такой конфигурации работать по Trunk-Based Development не представляется возможным.

Двоичные файлы в репозитории?

В зависимости от того, сколько раз и как часто используются двоичные файлы, одни системы контроля версий подходят для их хранения лучше, чем другие. Perforce может обрабатывать терабайты двоичных и тестовых файлов. Subversion стремится к этому. Git может обрабатывать только огромные бинарные файлы если он настроен в Git-LFS режиме.

Размер репозитория?

Существует рекомендация для Git и Mercurial не хранить историю (за исключением Git+LFS), размер которой превышает 1 гигабайт. Есть различные отчеты, которые могут быть во много раз больше этого размера, но командой разработки все-таки рекомендуется максимальный размер в 1 гигабайт. Если вы хотите использовать Git и каждый год не упираться в этот лимит, то вы можете оказаться в ситуации, когда вам придется продолжать архивировать репозиторий и запускать новый без истории, чтобы иметь больше места для хранения истории. Архивирование может выглядеть как переименование репозитория в GitHub и превращение его в доступный только для чтения, чтобы вся история, issues и комментарии на code review сохранились. Более простые и рациональные стратегии клонирования могут включать рекомендуемую “–shallow-Since” дату клонирования или использование более современных возможностей частичного клонирования для клонирования полного репо с фиксацией истории, не получая historical blobs (в папке .git/ - прим. пер.) до тех пор, пока они не понадобятся.

Пиковая частота вливаний кода

В “чистом” Git, если коллега опередил вас и влил свой код (он прошел code review и автотесты на CI для его ветки прошли успешно) в тот момент, когда вы планировали влить свой код, то Git вас предупредит о том, что вы сначала должны подтянуть его изменения к себе, а только потом вливать код. Вы подтягиваете код и исправляете конфликты в коде (будем надеяться что их нет), и затем вливаете свой код. В репозиториях, где идет активная работа, вам иногда может быть тяжело найти момент для того, чтобы влить код таким образом, не столкнувшись с этой проблемой снова. Эта проблема известна как “гонка слияний”.

Базирующиеся на forks “pull запросы” и базирующиеся на ветках “merge запросы” в git сервисах решают эту проблему в определенной степени с помощью подхода, который автоматически поддерживает ветки с запросами на слияние в master на урвоне мастера до тех пор, пока там не возникают конфликты.

Однако, даже с Pull запросами, очень высокая частота вливаний кода в общем репозитории означает конкуренцию и искусственную сериализацию. Это стало одной из причиной для Miscrosoft создать свою виртуальную файловую систему Git (GitVFS GVFS VFS for Git).

Мы уверены, что через несколько лет Git сможет справиться и с более высокой частотой вливаний кода. Либо с помощью технологии Microsoft, либо с помощью чего-то другого.

Закон Конвея

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

Перенос баз данных

Чтобы управлять схемами базы данных в Trunk-Based Development, вам нужно будет найти способ обрабатывать изменения формы таблицы в системе управления версиями и даже управлять существующими данными, в которых появились новые/измененные столбцы. Книга Прамода Садладжа(Pramod Sadlage) и Скотта Амбера(Scott Amber) “Рефакторинг баз данных: эволюционный дизайн базы данных" рассказывает про это очень много, равно как и книга Continuous Delivery.

Общее владение кодом

Команды, работающие по Trunk-Based Development, обычно имеют общие правила владения кодом, касающиеся внесения изменений в различные части кода. Если у них нет полностью равноправной системы для всех разработчиков, то у них должнв быть объективные правила для внесения изменений в код. Правила, которые сосредоточены на стандартах и предполагают быструю и объективную проверку кода. Команды, работающие по Trunk-Based Development, могут иметь свои особенные разрешения на запись для каталогов внутри ветки trunk, но никогда не имеют никаких препятствий для чтения файлов в trunk ветке - все могут видеть все.