Як ми налагодили релізний менеджмент без нічних деплоїв для 6 команд

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Ще рік тому релізи для spiritual wellness платформи Nebula працювали в режимі «On Demand»: відсутність графіків, узгодження пріоритетів «на ходу» й спроби втиснути максимум в кожну поточну збірку. Без чіткої каденції релізів навіть сильним командам складно планувати: тестування перезапускається по колу, зʼявляється зайва напруга в комунікаціях, а бізнесу важче прогнозувати, коли саме фіча потрапить до користувача. На трьох платформах (веб, iOS та Android) це відчувається ще сильніше.

Тому в OBRIO вирішили навести лад у самому процесі — і побудувати релізний ритм, у якому складні задачі вирішуються системно, а команди фокусуються на результаті замість постійного гасіння пожеж.

Мене звати Анастасія Павленко, я — Technical Program Manager в OBRIO, ІТ-компанії з екосистеми Genesis. Хочу поділитися, як наші 6 команд перейшли на щотижневу систему релізів. Розповім, що ми змінили в правилах і ролях та як змогли вибудувати стабільний графік без овертаймів і нічних деплоїв.

Точка болю: що не так з «однією маленькою фічею»

Коли я прийшла в OBRIO, моїм першим завданням від СТО було налагодити систему релізів. Робота команд організована навколо продуктових доменів: є команда, що відповідає за чат і його стабільність, ретеншен-команда, яка розвиває механіки утримання та повернення користувачів, є контент-команда тощо.

Кожен стрім — кросфункціональний. Усередині зазвичай є бекенд- та фронтенд-розробники, mobile-інженери (iOS та Android), продакт-менеджери та продакт-овнери. Тобто команда може самостійно пройти весь цикл: придумати рішення, реалізувати, протестувати й довести фічу до користувача. Це про реальний вплив: рішення приймаються всередині стріму, а результат роботи не губиться в погодженнях і швидко доходить до користувача. Усі 6 команд працюють одразу на трьох платформах — веб, iOS та Android.

До перебудови процесу в нас фактично не було сталої системи: релізилися «за потреби» без графіка і прогнозу, коли буде наступна збірка. Іноді це означало кілька релізів на тиждень, інколи — вночі або у вихідні.

Для компанії, що швидко росте, це типова пастка: 6 кросфункціональних команд продовжують швидко будувати фічі, але їхній шлях у продакшн стає непередбачуваним. Продакт-менеджери, не знаючи дати наступного релізу, намагалися докласти максимум у поточний — навіть якщо це була «ще година роботи».

На практиці це ламало тестування. Повний мануальний цикл у нас займає близько 4 годин. Коли посеред нього з’являється терміновий івент або правка UI, частину перевірок доводиться запускати заново. Далі працює доміно: реліз зміщується, інші команди приносять свої «термінові» фікси — і в підсумку все затримується.

Коли ми проаналізували ситуацію, стало очевидно: і технічній, і продуктовій сторонам потрібно одне й те саме — прогнозованість.

Release Train: філософія та правила руху

Release Train — це потяг, який відправляється суворо за розкладом. Якщо фіча не готова до моменту «закриття дверей», вона не зупиняє весь реліз — просто їде наступним потягом за тиждень. Ми зафіксували кілька правил:

1. Роль «фільтра». Я стала людиною, яка стоїть між запитом «треба зараз» і реальним ресурсом команд. Реліз-менеджер в OBRIO не залучений у розробку стрімів — і це критично: я не прив’язана до конкретних фіч і можу сказати «ні», захищаючи стабільність релізу.
2. Спільна мета для всіх сторін. Ми проговорили з командами, що всім потрібне одне й те саме: передбачуваний ритм і зрозумілий шлях фіч у продакшн.
3. Розклад під бізнес. Ми врахували, як живе продукт: важливо, щоб новий функціонал був доступним на вихідних, але реліз у п’ятницю ввечері — зайвий ризик. Тому ми прийшли до моделі релізів щочетверга для всіх трьох платформ.

Як це виглядає на практиці

Вівторок: очищення скоупу

• Реліз-менеджер нагадує продактам і командам переглянути скоуп: які задачі реально встигають пройти розробку й тестування до релізу, а що слід перенести.
• Увечері реліз-менеджер дивиться на статуси: усе, що застрягло в in progress, переїжджає в наступну версію.

Середа: Scope Freeze і стабілізація

• Зранку оголошуємо Code / Scope Freeze — у цей реліз більше нічого не додається.
• О 10:00 системою автоматично відрізається релізна гілка (release branch): потяг зачиняє двері.
• Увесь день команди займаються стабілізацією: доводять до ладу те, що вже потрапило в реліз, дотестовують, фіксять баги, дописують автотести.
• У ніч проти четверга запускаються автотести.

Четвер: релізний день

• До 10:00 повинен бути готовий релізний кандидат.
• QA, який чергує, дивиться репорт автотестів, закриває смоуки й ті сценарії, що залишилися в мануалі.
• На кожній платформі (iOS, Android, веб) є чергові QA та розробник, які оперативно реагують на проблеми.
• Реліз летить у стор/продакшн зазвичай між 13:00 і 15:00. Якщо до обіду не встигаємо, це сигнал, що реліз може відкластися.

Понеділок: підсумки й наступний цикл

• Підсумкова комунікація про реліз і наступні плани.

Технічна сторона: від ручного тестування до автоматизації

Перехід на Release Train вимагав підтягнути інфраструктуру під новий ритм. На вебі CI/CD і роботу з гілками довелося вибудовувати майже з нуля. Команда налаштувала автоматичне відрізання release-branch так, щоб реліз не блокував подальшу розробку: команди продовжують мерджити зміни в develop branch, а все, що не потрапило в поточний реліз, автоматично їде в наступну версію (Development Driven Flow).

Щоб тримати скоуп релізу прозорим, ми зав’язали процес на Jira: без Fix Version задача не переходить у тестування. Це дозволяє і командам, і реліз-менеджеру в будь-який момент бачити, що саме «їде» цим потягом.

Для синхронізації ми ведемо окремі календарі релізів для вебу, iOS та Android: в них видно Scope Freeze, вікна тестування й дату релізу. Це зменшило кількість запитів «коли ви деплоїте?» і загалом спростило комунікацію.

Рівень автоматизації тестів на платформах різний. На iOS покриття автотестами близьке до повного — для QA реліз часто зводиться до рев’ю звіту. На Android тестування все ще переважно мануальне, тому ця платформа найбільш чутлива до затримок із реліз-кандидатом. Стратегічний вектор очевидний: більше автотестів — стабільніший процес і потенційно частіші релізи. Але навіть поточний рівень автоматизації вже дав відчутний виграш у передбачуваності.

Що було найважчим у впровадженні

Головний виклик був не технічним. Найскладніше — роль «фільтра»: людини, яка балансує між запитом «потрібно вже» і стабільністю релізного процесу. Часто це означає сказати «ні», відмовити у перенесенні релізу заради фічі. Водночас ця роль не про заборони за будь-яку ціну. Якщо зміна справді критична для бізнесу, правильним рішенням стає окремий позаплановий реліз. Але подібні випадки трапляються рідко, бо кожна зміна має бути чітко обґрунтована.

На старті ми свідомо мінімізували винятки: кілька перших релізів мали пройти за новими правилами, щоб процес закріпився. Якщо хтось приносить фічу після Scope Freeze, це впливає не лише на одну команду — перебудовуються плани інших. Тому ми зробили change-менеджмент досить складним: потрібно пояснити причину, оцінити наслідки й погодити зміни з усіма, кого це зачіпає. І часто саме це знімає запит. Так ми швидко привчилися планувати на тиждень уперед, а не в останній момент.

Коли все йде не за планом: людський фактор і форс-мажори

На схемі Release Train виглядає ідеально, але реальне життя підкидає сюрпризи — здебільшого через людський фактор або дрібні побутові «граблі», про які ніхто не подумав. Ось декілька кейсів, після яких ми підкрутили правила.

Кейс № 1: додавали без попередження нові фічі в реліз кандидат.

Рішення: зафіксували дисципліну версійності — кожна зміна має бути прив’язана до релізної версії, а будь-яке розширення скоупу проходить через зрозумілий change management.

Кейс № 2: не запустились автотести через відключення світла або через те що прибиральниця відключила комп.

Рішення: встановили безперебійник на комп’ютер та відповідального за машину на якій раняться автотести.

Кейс № 3: прилітали запити на додаткові релізи з критичним багом.

Рішення: описали спрощений процес позапланових релізів та критеріїв, за яким ми їх робимо.

Результати: що ми отримали

З квітня після переходу на Release Train у нас не було регулярних овертаймів через релізи. Реліз стабільно виходить у четвер до 14:00, а в команди є час на пост-релізний моніторинг у межах робочого дня. Продакт-менеджери планують скоуп під чіткі дедлайни: якщо фіча не готова, вона їде в наступному релізі. У підсумку з’явилася прогнозованість: чіткий ритм і правила прибрали хаос і зайву напругу та дали командам можливість фокусуватися на результаті.

З введенням релізного менеджменту життя команди змінюється. Він дає ритм, у якому продукт росте стабільно, а команди працюють без овертаймів. Перші релізи будуть тестом для процесу, але щойно ви один раз випустите реліз за графіком без критичних проблем — команда повірить у систему.

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.