Удлинение Релизного Цикла
Различия
Здесь показаны различия между двумя версиями данной страницы.
|
foxdev_7:todo:удлинение_релизного_цикла [20.11.2018 08:29] nikolay_carbonsoft1 Approved(nikolay_carbonsoft1 2018/11/20 08:29) |
foxdev_7:todo:удлинение_релизного_цикла [20.05.2019 15:18] |
||
|---|---|---|---|
| Строка 1: | Строка 1: | ||
| - | |||
| - | Для повышения качества продукта и ускорения разработки, компания может организовать короткий цикл релиза: раз в месяц/день/час. Зачем? | ||
| - | |||
| - | - после каждого коммита есть шанс принести баг, в быстро развивающемся проекте таких коммитов много | ||
| - | - можно пойти в сторону полного 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)} | ||
admin