Andy Melnikov (nponeccop) wrote,
Andy Melnikov
nponeccop

Categories:

Стабильные версии

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

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

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

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

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

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

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

3. LTS-ветки

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

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

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

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

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

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

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

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

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

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

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

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


Преимущества такие:
- получается человекочитаемые имена версиям давать в виде даты. Благо двух версий в один день не бывает
- не бывает такого, что версия, помеченная как стабильная, становится нестабильной (может когда-то и бывает, но у меня не было)
- между стабильными версиями нетехнический ченжлог - то есть не бывает такого, что весь ченжлог - это шишку где-то в кишках поменяли на мышку, как правило есть какие-то видимые фичи и улучшения
- виден долгосрочный прогресс - условно, сколько обновлений в год
- всё вышеперечисленное не замусоривается хотфиксами
Tags: programming, все пидарасы а я
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 10 comments