Коли справа доходить до scrum доставки, люди зазвичай очікують виконання випуску після закінчення спринту. Це означає безпосередньо після успішної демонстраційної презентації клієнту.
Але я завжди дивувався, як це може бути таким автоматичним очікуванням. Особливо якщо ви врахуєте наведені нижче можливі дії, які мають відбутися до або поруч.
- Розвивайте та завершуйте всі історії в спринті. Деякі з них можуть бути завершені раніше, але в більшості випадків історії завершуються безпосередньо перед кінцем спринту. Можливо, навіть після демонстраційної презентації, щоб бути відкритим тут.
- Виконайте всі заплановані тести вмісту спринту, щоб переконатися, що код, який буде випущено, готовий до виробництва.
- Наздоганяйте виявлені помилки та виправляйте їх вчасно до випуску.
- Переконайтеся, що конвеєр розгортання оновлено найновішим вмістом, а сам конвеєр надійний для виконання.
- Запустіть конвеєр у всіх відповідних середовищах, щоб привести їх у найновіший стан з точки зору коду та даних.
- Підготуйте примітки до випуску та повідомте клієнту про вплив випуску та про те, що саме зміниться після цього.
- За необхідності синхронізуйте роботу з іншими паралельними командами scrum, щоб забезпечити одночасний випуск залежного вмісту. Нічого не повинно бути втрачено, щоб гарантувати, що вміст вашого випуску працюватиме належним чином.
- Крім усього цього, пройдіть усі церемонії сутичок. Не лише пов’язані з поточним спринтом, а й з тими, що націлені на наступний спринт (наприклад, сеанси вдосконалення історій).
А тепер уявіть, що спринт триває два тижні.
Самі по собі заходи з випуску потребують часу та людей. Але це не може зайняти занадто багато. Одразу після останнього дня спринту настає перший день наступного спринту, і коло починається знову.
Чи очікування випуску після кожного спринту все ще виглядає таким автоматичним?
Обробка вмісту випуску
Якщо всі процеси в спринті автоматизовані, є можливість просто «натиснути на курок» і інсталювати останню версію коду в виробництві в кінці кожного спринту. Проблема в тому, що я ніколи не відчував такого ідеального стану команди scrum.
Якщо це дійсно так у деяких малих приватних підприємствах, я їм справді заздрю. Але реальність у корпоративному світі така, що команда scrum не досягне такого рівня зрілості. Навпаки, процеси випуску зазвичай пов’язані з трудомісткими діями, які досягають більшої частини наступного спринту, впливаючи на цей спринт з точки зору вмісту та всіх показників. Випуск — це просто стресова дія, через яку ніхто з команди не радий пройти.
Тому я знайшов наступний найкращий сценарій для роботи з релізами.
Висновок полягав у тому, щоб кожен другий спринт був спринтом звільнення. Ось що це означає.
Окрема версія коду для наступного випуску
Це стосується обробки окремих гілок у сховищі GIT. Є багато способів підійти до однієї проблеми, і всі вони можуть бути успішними. Але для цілей цієї статті я збираюся зробити все просто, щоб продемонструвати підхід та його вплив.
Щоб якнайменше впливати на поточну діяльність з розробки, важливо відокремити вміст для наступного випуску в окрему гілку. Давайте назвемо це Release Branch. При цьому буде вирішено наступне:
- Команда розробників може продовжувати свою діяльність і вливатися в нові історії основної гілки без збоїв.
- Немає ризику, що на вміст випуску вплинуть несподівані зміни коду від команди scrum.
- Тестування можна виконувати в ізольованому просторі. Тут будуть внесені лише зміни, необхідні для вирішення тестування.
- Оскільки конвеєр випусків розгортатиме у виробництво лише вміст із гілки випуску, у нас є чіткий процес і повний контроль над вмістом, який буде випущено. Не може трапитися, щоб якийсь неочікуваний комміт у гілку Git зламав уже перевірений код.
Тому просто тримайте вміст наступного випуску осторонь і дайте йому завершитися до стабільного стану, готового до випуску.
Час випусків, щоб вони працювали неодноразово
Я відмовився від амбіцій робити випуск після кожного спринту. Було надзвичайно ясно, що це не матиме жодного шансу спрацювати. Принаймні, не з такими побічними ефектами, як:
- впливаючи на вміст розробки наступного спринту,
- нездатність стабілізувати вміст випуску,
- надолужити всі необхідні дії з тестування тощо.
Тому метою було виконати випуск до кінця кожного другого спринту. Це означало б наступне:
- Реліз завжди міститиме історії з двох останніх уже завершених спринтів. Оскільки випуск виконується в межах поточного (активного спринту), цей вміст спринту ще не включено до випуску.
- Є цілий один спринт для виконання необхідних дій тестування та виправлення помилок.
- Власник випуску має достатньо часу, щоб зібрати інформацію, пов’язану з випуском (тестові випадки, примітки до випуску тощо) за допомогою спринту без випуску. Таким чином, вони можуть працювати практично автономно, а решта команди розробників працюватиме над новими історіями.
- У разі виявлення помилки власник випуску може швидко зв’язатися з конкретним розробником, щоб вирішити проблему та повернутися до поточного вмісту спринту. Тому завжди має бути виділено певний відсоток часу від можливостей команди для підтримки цього виправлення помилок. Скільки саме можна виявити з часом.
Зрозуміло, що користувачі не отримають останній вміст спринту в останньому випуску. Але з часом це стане неактуальним. Вони все одно отримуватимуть два спринти вмісту з кожним наступним випуском, після кожного другого спринту.
Це виглядає як гарний компроміс між швидким задоволенням від доставки та не відставанням від діяльності scrum без значних перешкод.
Виконайте розгортання випуску
Після успішного завершення тестування, виправлення помилок і готовності конвеєра це досить простий процес для виконання виробничого конвеєра та завершення випуску для виробництва.
Оскільки він розгортається з автономної гілки, це може бути в основному непоміченою та невидимою діяльністю. Нікому не потрібно знати. Якщо це так, це найкраща реалізація розгортання випуску.
Необхідною умовою для цього є створення надійного автоматизованого конвеєра DevOps. Використовується не лише для розгортання у виробничому середовищі, але й у всіх інших середовищах нижчого рівня. Це може включати розробку, пісочницю, тестування, забезпечення якості, середовище продуктивності тощо. Це одне клацання для розгортання всіх рішень для кожного окремого середовища.
Звільнення не повинно викликати болю чи стресу. Або кошмар, якого всі бояться і готуються до цього дня тиждень. Ні – замість цього, якщо ніхто взагалі цього не помічає, це найкраща ознака успішного випуску.
Знову злийте гілку Release у гілку Development
Гілка випуску тепер містить деякий спеціальний вміст, якого немає у звичайній гілці поточної розробки. Це пов’язано з усіма виправленнями, реалізованими протягом періоду тестування. Цей вміст потрібно об’єднати назад у гілку розробки, щоб гарантувати, що виправлення залишаться там навіть після наступного випуску.
На цьому етапі остання гілка випуску слугує готовим до повторного розгортання виробничим кодом. Якщо невдовзі після розгортання виробництва потрібно вирішити термінову проблему високого пріоритету, вона може використовувати цю гілку. Взяти цей код і впровадити виправлення всередині просто. Це все ще точна копія поточного робочого коду без будь-якого нового неопублікованого вмісту.
Нарешті, коли розпочнеться новий період тестування, попередню гілку випуску можна буде видалити та замінити новою. Новий знову створюється як копія поточної гілки розробки.
Встановіть регулярні випуски
І тепер ми це маємо 😀 — надійний процес наближення до випуску. Єдине, чого не вистачає, — це взяти на себе зобов’язання підтримувати його регулярно. У цьому випадку після кожного другого спринту.
Зберігаючи його регулярним, ми фактично закладаємо основу, щоб полегшити його виконання, головним чином тому, що:
- Якщо випуск відбудеться через не надто довгий час, не буде так багато нового вмісту для встановлення в робочу версію. Приріст невеликий і вважається стабільним.
- Тепер стільки нового вмісту означає не надто багато тестування та створення тестів. Менше комунікацій, дзвінків для узгодження та співпраці із зацікавленими сторонами щодо того, що все потрібно повторно перевірити. Вони також погодяться, що з останнього релізу минуло не так вже й багато часу. Тож цій дії надається менше значення.
- Команда звикне до цього циклу; з часом це стане природною частиною команди.
- Як побічний ефект середовища розробки та тестування часто оновлюють дані. Це все одно необхідно для кожного нового циклу тестування. Тож це не буде просто ще одна запланована діяльність. Швидше, дія, яка вже є частиною встановленого процесу. Ця зміна точки зору так сильно впливає на атмосферу в команді. Людина не повірить.
Висновок
Цей розділ завершує мої попередні публікації на тему життєвого циклу scrum. Крім того, йдеться про те, що виявилося ефективним у реальному житті.
Часто команди починають гнучкий шлях і роблять багато речей неправильно. Потім вони еволюціонують, зрештою, і починають робити речі по-іншому. Ця серія може допомогти деяким із них швидше здійснити ці зміни.
Цей підхід до випуску не є єдиним працездатним і не обходиться без проблем. Вони все ще будуть існувати, і командам доведеться з ними боротися. Тоді вдосконалюйте те, що можливо, і забудьте те, що не має сенсу.
Але наскільки я знаю, цей підхід, хоч і простий, довів, що зміни можливі. Від хаотичних, непередбачуваних спринтів до більш стабільної доставки з регулярними випусками, на які можна покластися та планувати. І для цього не потрібна особлива, надскладна методика – лише прості правила та бажання слідувати плану.