?

Log in

No account? Create an account
Стабильные версии - Дважды мудак — ЖЖ [entries|archive|friends|userinfo]
Декларативное рулит

Site Meter

[ website | Мой сайт ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Стабильные версии [июн. 10, 2019|13:30 pm]
Andy Melnikov
[Tags|, ]

По опыту многолетней эксплуатации двух проектов оказывается, что стабильные версии компонентов удобнее помечать пост-фактум.

Есть "книжное" понятие стабильной версии здорового человека: делаем новую ветку мастера с feature freeze и только фиксим баги. Через какое-то время в этой ветке оказывается нечего чинить: всё починили, остались только баги, на которые всем похуй, новые баги обнаруживаются редко. Код стабилизировался.

Такие "настоящие" стабильные версии попадаются крайне редко, обычно разные вариации стабильной версии курильщика.

1. Замораживание перед релизом.

Это наиболее частая форма стабилизации, в особенности перед первым релизом. Часто это не для стабилизации вовсе - просто все заебались и хотят релизиться, но QA не пускает. Если QA нет - это внутреннее чувство прекрасного, не позволяющее релизить совсем уж говно и/или заказчик, от которого надо получить бабло и забыть проект как страшный сон.

2. Замораживание перед деплоем

Это наиболее характерно для проектов в стадии поддержки.

3. LTS-ветки

Надо понимать, что LTS-ветки - это просто замороженные ветки. Они обретают некоторую степень стабильности лишь через некоторое время, когда наиболее значительные баги там обнаружат и пофиксят. Ну то есть идея "обновиться на свежевышедшую LTS-ветку" это ужас-ужас.

4. Бэкпорт-ветки

Это как LTS, только на баги в ветке всем похуй. Однако исправления, которые делаются в основной ветке, по возможности бэкпортируются.

Допустим, у нас в проекте есть подсистема из говна. Мы делаем ветку, и затем в мастере заменяем её на подсистему из шоколада. В случае LTS-ветки баги в системе из говна чинятся. А в случае бэкпорт-ветки - нет.

Идея бэкпортов в том, что бэкпорты очень дёшевы. Кроме того они встречаются в сценариях, когда веток как таковых нету.

5. Погонять на стейджинге

Это уже хипсторская идея, в чём-то похожая на старые бета-версии и релиз-кандидаты. Мастер выкатывается на стейджинг, и если всё ок - то через какое-то время выкатывается на продакшен.

6. Погонять на продакшене и если поломалось - откатить

Это вариация 5, но более экстремальная (во всех смыслах).

7. Погонять на продакшене и если поломалось - починить по-быстрому, если не получилось - откатить

И тут как раз мы приходим к первому абзацу поста. Если откатывать - то куда? Надо помечать годные ревизии.

У меня получается так. Запилил фичу - пометил текущую ревизию на проде как стабильную, выкатил на прод. Запилил хотфикс - выкатил по-быстрому, ничего не помечая. Если цепочка хотфиксов после которой обнаруживается что-то фатальное что чинить долго - то откатываем не на прошлый хотфикс, а на последнюю помеченную.


Преимущества такие:
- получается человекочитаемые имена версиям давать в виде даты. Благо двух версий в один день не бывает
- не бывает такого, что версия, помеченная как стабильная, становится нестабильной (может когда-то и бывает, но у меня не было)
- между стабильными версиями нетехнический ченжлог - то есть не бывает такого, что весь ченжлог - это шишку где-то в кишках поменяли на мышку, как правило есть какие-то видимые фичи и улучшения
- виден долгосрочный прогресс - условно, сколько обновлений в год
- всё вышеперечисленное не замусоривается хотфиксами
СсылкаОтветить

Comments:
[User Picture]From: rdia
2019-06-11 09:09 pm
А у вас сколько продов? Один или два?
(Ответить) (Thread)
[User Picture]From: nponeccop
2019-06-12 11:33 am
А вы с какой целью интересуетесь?

Проектов два. Компонентов с версионированием задним числом 6. Серверов в сумме около 15.

Edited at 2019-06-12 11:51 (UTC)
(Ответить) (Parent) (Thread)
[User Picture]From: rdia
2019-06-12 02:25 pm
Ну у нас два. Но и пиздюли за продолб, видимо, будут несопоставимы.

Собственно, у нас alpha, beta, prod backup, prod. И код движется слева направо. Фичи, как правило, можно включать и отключать налету на любом кластере. То есть имеется что-то вроде единого реестра настроек. Этот реестр покрывает только специфические и простые настройки. База, естественно, реплицирована на каждую машину.
(Ответить) (Parent) (Thread)
[User Picture]From: nponeccop
2019-06-12 07:27 pm
Ну у нас в одном из проектов похожая схема:

- сервер бэкапов и инфраструктуры (на него реплицируется база с прода который прод)
- запасной прод, он же стейджинг. Независимая база, при переключении прода её затираем той, что со слейва репликации.
- конфиг фич тупо вкоммичен в сорцы, там свитч по хостнеймам. Ну то есть налету отключаемо, но это одна из форм хотфиксов. Надо помнить, что где отключено, что проще делать в сорс-контроле.
- девелоперские сервера (независимые минипродакшены 24/7)
(Ответить) (Parent) (Thread)
[User Picture]From: rdia
2019-06-13 03:13 am
У нас, к сожалению, система довольно большая, то есть, каждый кластер состоит из 4-5 серверов типа ваших 256Гб ОЗУ, которые вы на ebay'е покупаете. Соответственно, невозможно каждому разработчику выдать персональный dev, на котором он может делать всё, что хочет.

Была идея сделать "общий dev" - некоторый кластер, на который еженощно копируется α, ну, а днём каждый разработчик имеет практически права root. Вы про такую схему слышали - есть у неё какие-то фатальные косяки? И как, вообще, строятся dev кластеры в таком случае? Ну нельзя же каждому разработчику выдавать кластер.

> Надо помнить, что где отключено, что проще делать в сорс-контроле.

У нас для этого спец. механизм с историей, разной интроспекцией, правами доступа, разделением по группам и т.д. Действительно удобная и надёжная вещь. Но и контора громадная, надо сказать.
(Ответить) (Parent) (Thread)
[User Picture]From: nponeccop
2019-06-13 03:09 pm
> У нас для этого спец. механизм с историей

Ну то есть конфиг это отдельный компонент по сути. Понятно.

> как, вообще, строятся dev кластеры в таком случае

У нас есть 4 механизма:
- можно использовать для тестирования часть компонентов со стейджинга, известных своей неубиваемостью. Им всё равно откуда таски приходят - со стейджинга или с дева. Можно даже одновременно.
- легковесный дев - то есть минимум узлов и минимум фич
- покомпонентные пускалки - есть возможность запустить компонент изолированно от кластера, в mock-окружении
- тесты (ну то есть уменьшение необходимости пускать интеграционные тесты)

Для выдачи разрабам кластеров можно пробовать виртуалки. Взять толстый сервер (сервера), на который помещается по памяти 4 максимально облегчённых кластера, и поставить туда 10 инстансов.

Может оказаться, что комбинация оверкоммита, запрета одновременно пускать более Х виртуалок (в очередь, сукины дети) и встроенной в VM дедупликации памяти (в ESXi из коробки) сработает в вашем случае.

Ещё может оказаться вариант арендовать мощностя на амазоне на время рабочего дня. Подымать в 7 утра по крону. Но опять же зависит от масштабов и бюджетов. Если на з-п уходит миллион в месяц, можно сравнить стоимости различных решений, может оказаться что не так и дорого.

Edited at 2019-06-13 15:10 (UTC)
(Ответить) (Parent) (Thread)
[User Picture]From: rdia
2019-06-12 07:09 pm
Наверное staging - это наш prod2.

А так примерно как у вас. Немного, кстати, не раскрыта тема компонент. Ну когда часть компонент может быть заморожена.
(Ответить) (Parent) (Thread)
[User Picture]From: nponeccop
2019-06-12 07:34 pm
У нас компоненты не заморожены, просто достигли стабильности здорового человека (не модифицируются годы, так как feature complete и все приоритетные баги пофикшены).

Соответственно деплой идёт всего одного-двух компонентов, и откатывать в случае чего надо только их.
(Ответить) (Parent) (Thread)
[User Picture]From: bvlb
2019-06-12 04:26 pm
semantic versioning как раз же для этого. Третья цифра для хотфиксов, вторая для фич.

Тэги для помечания версий, release branches (оно таки книжное! https://producingoss.com/en/release-branches.html) для замораживания и работы над релизом, потом мерджатся обратно в транк.

А проблему с тем, что реально понятно только постфактум из того, что я видел решают (частично) тем, что дробят процесс релиза на кучу этапов типа alpha -> beta -> release candidate 0 -> release candidate 1 и т.п., пока багов совсем мало явных багов не останется. В семантик вершининг 2.0 кстати этот хвост тоже описан (типа tensorflow 1.13.1-rc2)
(Ответить) (Thread)
[User Picture]From: nponeccop
2019-06-12 07:17 pm
TLDR: по большому счёту, моя мысль в том, что если релизов как таковых нету - получаются короткие цепочки "выкатывание-хотфиксы-откат", разделённые длинными интервалами.

- выкатывание 1
- откат

- выкатывание 2
- хотфикс - "cтабильная версия"

- выкатывание 3 - "cтабильная версия"

- выкатывание 4

---------
1. Ну моя мысль как раз о том, что традиционная модель говно и не нужна, и превращается в фарс карго культа. Отличительная черта "книжности" в том, что "книжное" не работает.

В нашей нетрадиционной™ хипсторской реальности с continuous delivery обычный release management (замораживания-мержи-бранчи-альфы-беты-QA-приёмка) заменяется на пункты 5-7 хуяк-хуяк. То есть абзацы 2-3 мимо кассы.

2. Semantic versioning не для этого. Ну то есть сразу по открытию ссылки https://semver.org/ читаем про API, packages и dependencies.

Моё определение semver - это "semver - это схема версионирования интерфейсов с third parties для отслеживания обратной совместимости". То есть, если нет интерфейсов, third parties или совместимости - то semver мимо кассы.

3. Перепутаны фиксы и хотфиксы:

https://en.wikipedia.org/wiki/Hotfix

The term "hotfix" originally referred to software patches that were applied to "hot" systems; that is, systems which are live, currently running, and in production status rather than development status. For the developer, a hotfix implies that the change may have been made quickly and outside normal development and testing processes.

4. Проблему того, что понятно постфактум, решают многими способами. Например, достаточно широко распространены deprecated versions. Но это опять же, больше для пэкеджей.




(Ответить) (Parent) (Thread)