Удлинение Релизного Цикла

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

  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~~

Прочитал open carbon 7 todo удлинение релизного цикла
Yes(3) No(1) Clear

Yes:
, Alexander Sobyanin, Сергей Трошин,

No:
Олег Стрижеченко,

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

– Звучит неплохо, это и есть требование большинства клиентов. 80 % клиентам нужен стабильный продукт, а не бурно развивающийся и баговый.

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

– Второе, это не минус, рассылки с новостями будем делать и всё ок, а хочет фич - добро пожаловать на devel, таких клиентов немного 2%. Остальные дождутся.

Денис КучаевДенис Кучаев, 07.12.2018 05:46

Обсудили с Антоном. Главный минус - сильное удорожание разработки. Опыт трехмесячных релизов уже был. Ставили такой эксперимент в биллинге. Скорость разработки значительно выше сейчас по сравнению с тем периодом. В перспективе 3-5 лет это выгодней чем суперстабильные версии с дорогой разработкой, когда надо одновременно несколько версий поддерживать.

adminadmin, 10.12.2018 04:34

прочитал

Ваш комментарий. Вики-синтаксис разрешён: