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

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

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

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

Можно выпустить LTS релиз, например, раз в 6 месяцев. Можно даже размазать обновление клиентов по этим 6 месяцам и настроить ротацию. 
Плюсы:
  * стабильные версии, почти без багов (а для большинства клиентов - действительно без багов)

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



Статья по мотивам поиска путей повышения стабильности обновлений продуктов. Негатив к удлиннению релизного цикла взят из доклада [[https://www.youtube.com/watch?v=pTRRfW0_eC0|Devops в коробочной разработке / Максим Лапшин]]

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

~~OWNERAPPROVE~~
/*Не удаляйте эту строку и ниже!*/
{(rater>id=1|name=Прочитал_open_carbon_7:todo:удлинение_релизного_цикла|type=vote|trace=user|tracedetails=1)}