У сфері scrum розробки, часто очікується, що реліз продукту відбудеться безпосередньо після завершення спринту, особливо після успішної демонстрації клієнту. Однак, такий підхід може бути не завжди оптимальним, зважаючи на низку дій, необхідних для якісного випуску:
- Завершення всіх задач (історій) у спринті, що часто відбувається ближче до його закінчення, а іноді навіть після демонстрації.
- Проведення повного тестування коду, щоб гарантувати його готовність до використання в реальному середовищі.
- Виправлення виявлених помилок до випуску.
- Оновлення конвеєра розгортання з останнім кодом та перевірка його надійності.
- Запуск конвеєра у всіх необхідних середовищах для оновлення коду та даних.
- Створення нотаток до випуску та інформування клієнта про зміни та їх вплив.
- Синхронізація дій з іншими scrum-командами для забезпечення одночасного випуску залежних компонентів.
- Участь у всіх scrum-церемоніях, включно з підготовкою до наступного спринту.
Враховуючи ці аспекти, особливо коли спринт триває всього два тижні, стає зрозумілим, що процес випуску не може бути повністю автоматизованим і потребує значних зусиль.
Обробка контенту релізу
У ідеальному світі, де всі процеси автоматизовані, можна було б випускати оновлення одразу після завершення кожного спринту. Однак, на практиці, особливо у великих компаніях, процес випуску часто пов’язаний з ручними операціями, які займають значну частину часу, впливаючи на наступний спринт. Реліз стає стресовим періодом для команди.
Тому, необхідно знайти оптимальний підхід до управління випусками. Одним з варіантів є проведення випусків через кожні два спринти, що дає змогу ретельно підготуватись.
Окрема гілка коду для майбутнього випуску
Один зі способів ефективно керувати випусками – це використання окремих гілок у системі контролю версій Git. Для спрощення, можна використовувати гілку, названу “Release Branch”. Це дозволяє досягти наступних цілей:
- Команда розробників може працювати над новими функціями без перешкод.
- Знижується ризик внесення випадкових змін до контенту, який готується до випуску.
- Тестування відбувається в ізольованому середовищі, де вносяться лише необхідні виправлення.
- Процес випуску є більш контрольованим, оскільки конвеєр розгортає лише контент з гілки Release.
Такий підхід дозволяє стабілізувати контент релізу до його випуску.
Планування випусків для регулярності
Відмова від амбіції випускати оновлення після кожного спринту дозволяє уникнути негативних наслідків, таких як:
- Вплив на розробку наступного спринту.
- Недостатня стабілізація контенту релізу.
- Неповне виконання тестування.
Метою є випуск оновлень наприкінці кожного другого спринту, що означає:
- Кожен реліз містить історії з двох попередніх спринтів.
- Є цілий спринт для тестування та виправлення помилок.
- Власник випуску має час на збір інформації, використовуючи спринт без випуску.
- У разі виявлення помилки, розробник може швидко її виправити.
Користувачі не отримують найновіший контент з останнього спринту, але це компенсується стабільними випусками через кожні два спринти.
Цей підхід – це компроміс між швидкістю випуску та ефективною роботою scrum команди.
Реалізація розгортання випуску
Після завершення тестування, виправлення помилок і підготовки конвеєра, розгортання виробничої версії стає відносно простим процесом. Оскільки випуск відбувається з окремої гілки, він має бути непомітним для більшості членів команди. Це є показником добре налагодженого процесу випуску.
Необхідною умовою є наявність надійного автоматизованого конвеєра DevOps, який використовується для розгортання в різних середовищах. Це дозволяє виконувати розгортання одним кліком.
Розгортання не має бути стресовим досвідом. Навпаки, непомітне розгортання є ознакою його успіху.
Злиття гілки Release назад в гілку Development
Гілка релізу містить зміни, які не входять до основної гілки розробки, тому необхідно злити ці зміни назад, щоб виправлення залишилися в коді.
Остання гілка випуску містить готовий до розгортання код. Якщо після випуску знайдено термінову помилку, можна скористатися цією гілкою для швидкого виправлення.
З початком нового циклу тестування, стара гілка випуску може бути видалена, а нова створена на основі гілки розробки.
Запровадження регулярних випусків
Регулярні випуски, наприклад, після кожного другого спринту, створюють надійну структуру, що полегшує процес, оскільки:
- Невеликі інкременти зменшують ризик нестабільності.
- Менший обсяг нового коду означає менше тестування.
- Команда звикає до циклу, і він стає частиною рутини.
- Часте оновлення даних у середовищах розробки та тестування стає звичайною частиною процесу.
Висновки
Ці напрацювання є доповненням до попередніх публікацій на тему scrum, і представляють практичні поради, які ефективні в реальних умовах.
Команди часто починають працювати за agile-методикою з помилками, але з часом еволюціонують. Ця стаття може допомогти командам прискорити цей процес.
Цей підхід до випуску не є ідеальним і має свої недоліки, але команда має їх ідентифікувати, покращувати, та відкидати непрацююче.
Цей простий підхід довеів свою ефективність в переході від хаотичних спринтів до стабільних та регулярних випусків, на які можна покладатися та планувати. Для цього не потрібні складні методики, лише прості правила та бажання дотримуватися плану.