Для повышения качества продукта и ускорения разработки, компания может организовать короткий цикл релиза: раз в месяц/день/час. Зачем?

1. после каждого коммита есть шанс принести баг, в быстро развивающемся проекте таких коммитов много
2. можно пойти в сторону полного unit-тестирования и интеграционного тестирования. Это может сработать в SaaS решениях, но в коробочных продуктах большую специфику превносит клиентское оборудование, сеть (тут я немного загнул. Все, конечно, зависит от самого приложения)
3. другой вариант: частые релизы, минимизировать время от коммита до выявления бага клиентом и багфиксом

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

Проблемы редкого обновления:

• софт дорого тестировать на обновления с любой версии на любую (обычно тестируют с поледней на новую)
• миграции конфигов, данных и.т.д. Сложность с увеличением «разрыва версий» повышается
• могут быть проблемы с железом или конфигурацией, которые выяснятся только при обновлении (диск посыпался, кто-то менял файлы, используются depricated опции). Большой uptime - тоже зло.

Можно выпустить LTS релиз, например, раз в 6 месяцев. Можно даже размазать обновление клиентов по этим 6 месяцам и настроить ротацию. Плюсы:

• стабильные версии, почти без багов (а для большинства клиентов - действительно без багов)

Минусы:

• для поддержания стабильности (для выявления багов) нужно содержать замотивированный пул клиентов, которые сидят не на LTS. Возможно, даже несколько разных групп
• клиенты не видят новых фишек, продукт внешне перестает выглядеть как бурно развивающийся и/или живой (возможно, можно выправить маркетингом)

Статья по мотивам поиска путей повышения стабильности обновлений продуктов. Негатив к удлиннению релизного цикла взят из доклада Devops в коробочной разработке / Максим Лапшин

P.S. а вообще, подход в erlyvideo интересный: фиче-ветки + мастер бранч с автотестами и автосборкой. При этом master считается всегда release-ready, разработчиков подключают к решению проблем у клиентов чтобы понимали к чему приводит плохой коммит («коммит писать так, будто он сразу попадет на самого ворчливого и дотошного клиента»). В принципе, все то же применимо к нашему CI, если считать master/devel/integra средством вести списки клиентов - кому и как часто фичи выкатывать. Но не порождает ли наш подход иллюзию, что в integra можно мержить некачественный код?

~~OWNERAPPROVE~~