Удлинение Релизного Цикла
Для повышения качества продукта и ускорения разработки, компания может организовать короткий цикл релиза: раз в месяц/день/час. Зачем?
- после каждого коммита есть шанс принести баг, в быстро развивающемся проекте таких коммитов много
- можно пойти в сторону полного unit-тестирования и интеграционного тестирования. Это может сработать в SaaS решениях, но в коробочных продуктах большую специфику превносит клиентское оборудование, сеть (тут я немного загнул. Все, конечно, зависит от самого приложения)
- другой вариант: частые релизы, минимизировать время от коммита до выявления бага клиентом и багфиксом
Проблема в том, что клиенты получают нестабильный дистрибутив, жалуются на ошибки, просят LTS или долго не обновляются.
Проблемы редкого обновления:
- софт дорого тестировать на обновления с любой версии на любую (обычно тестируют с поледней на новую)
- миграции конфигов, данных и.т.д. Сложность с увеличением «разрыва версий» повышается
- могут быть проблемы с железом или конфигурацией, которые выяснятся только при обновлении (диск посыпался, кто-то менял файлы, используются depricated опции). Большой uptime - тоже зло.
Можно выпустить LTS релиз, например, раз в 6 месяцев. Можно даже размазать обновление клиентов по этим 6 месяцам и настроить ротацию. Плюсы:
- стабильные версии, почти без багов (а для большинства клиентов - действительно без багов)
Минусы:
- для поддержания стабильности (для выявления багов) нужно содержать замотивированный пул клиентов, которые сидят не на LTS. Возможно, даже несколько разных групп
- клиенты не видят новых фишек, продукт внешне перестает выглядеть как бурно развивающийся и/или живой (возможно, можно выправить маркетингом)
Статья по мотивам поиска путей повышения стабильности обновлений продуктов. Негатив к удлиннению релизного цикла взят из доклада Devops в коробочной разработке / Максим Лапшин
P.S. а вообще, подход в erlyvideo интересный: фиче-ветки + мастер бранч с автотестами и автосборкой. При этом master считается всегда release-ready, разработчиков подключают к решению проблем у клиентов чтобы понимали к чему приводит плохой коммит («коммит писать так, будто он сразу попадет на самого ворчливого и дотошного клиента»). В принципе, все то же применимо к нашему CI, если считать master/devel/integra средством вести списки клиентов - кому и как часто фичи выкатывать. Но не порождает ли наш подход иллюзию, что в integra можно мержить некачественный код?
~~OWNERAPPROVE~~
| Прочитал open carbon 7 todo удлинение релизного цикла |
admin
Обсуждение
– Звучит неплохо, это и есть требование большинства клиентов. 80 % клиентам нужен стабильный продукт, а не бурно развивающийся и баговый.
– Второе, это не минус, рассылки с новостями будем делать и всё ок, а хочет фич - добро пожаловать на devel, таких клиентов немного 2%. Остальные дождутся.
Обсудили с Антоном. Главный минус - сильное удорожание разработки. Опыт трехмесячных релизов уже был. Ставили такой эксперимент в биллинге. Скорость разработки значительно выше сейчас по сравнению с тем периодом. В перспективе 3-5 лет это выгодней чем суперстабильные версии с дорогой разработкой, когда надо одновременно несколько версий поддерживать.
прочитал