Pull to refresh

План по стабильности в продуктовой разработке: резиновые релизы

Всем привет!

Меня зовут Кирилл, я уже третий год делаю IT продукты. А до этого делал авиадвигатели, шаровые краны и стоматологическое оборудование. Хочу рассказать про грабли по которым я ходил свой первый год в IT.

Спасибо команде, которая в достаточной мере верила что я справлюсь и прошла со мной весь этот путь гнева, боли и погружения в отчаяние чтобы все-таки выпустить продукт.

Одна из ключевых проблем которые я создавал своей команде – это резиновые и нестабильные релизы.

Резиновые релизы

Это классика неопытного продакта. У тебя в управлении команда спецов которые могут создать что угодно и тебя кроет от возможностей. Я метался по рынку как бешеный пёс собирая идеи для беклога и утрамбовывая продукт супер фичами которые перевернут игру.

Чисто техническая проблема к которой это нас привело – новые фичи блочились релизом старых фич. Мы изначально не были готовы к гибким релизам и попадание двух фич на стейдж блокировало релиз до разрешения всех конфликтов. Более того, если мы сталкивались даже с незначительной проблемой - откатывался весь релиз.

Что делать?

Определяем корни проблем:

  • Фича в контексте релиза не изолирована

  • Блокировка принятых фич к выкатке в мастер

  • Нет понимания что входит в определенный релиз

Решения довольно простые и очевидные, но как и Устав ВС они пишутся кровью идиотов, перьями из их жоп на пергаменте из их шкур )

Один релиз – одна фича.

Делайте фичу изолированной: релизы не блокируют друг друга, легко откатываются, а самое главное - по каждой фиче можно задать себе главные вопросы продуктовой разработки: "А не херню ли я делаю?" и "Как это конвертируется в деньги?"

Про организацию стейджа

По поводу выкатки в стейдж. Есть мастер ветка, от нее хочу сделать ветку с новой фичей. Разрабатываем ее в Dev, когда все готово делаем пулреквест и из него должен быть экшен для раскатки стейджа. Получается мастер со всегда актуальной кодовой базой, когда делаем фичу и пушим в стейдж - у нас собирается окружение только для этой фичи. И если надо сделать две параллельные фичи, то выкатка второй перезапишет первую. Это безумно облегчит вам жизнь.


У спринта есть конкретная цель.

Я долгое время жил с названиями "12.03-16.03". Сравните с "Делаем Gate API под фичу с гостевым доступом". Пишите чего вы хотите достичь и акцентируйте на этом внимание. В конце-концов сможете сказать что применяете метод позитивной визуализации.

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

Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.