Управління релізами і розгортанням відповідає за надання та тестування можливостей для надання послуг, визначених на етапі Проектування.
Основні цілі Управління релізами і розгортанням:
- формування та узгодження планів релізів і розгортання з замовниками та інвесторами;
- гарантія того, що кожен пакет для релізу складається з набору пов'язаних і сумісних компонентів;
- здійснення управління релізом і його компонентами в рамках процесів Впровадження;
- гарантія того, що всі пакети для релізів можуть бути протестовані, відслідковані, перевірені, встановлені або усунуті (при необхідності);
- гарантія того, що всі зміни управляються в рамках діяльностей з управління релізами і розгортанням;
- ведення звітів і управління ризиками, проблемами, розбіжностями, пов'язаними з новою або зміненої послугою. Здійснення коригувальних дій при необхідності;
- забезпечення доступу до інформації для замовників і інвесторів, щоб вони могли ефективно використовувати нову або змінену послугу;
- забезпечення доступу до інформації для операційного персоналу, щоб він міг надавати, підтримувати і управляти послугою.
Управління релізами і розгортанням відповідає за випуск релізів і їх ефективне використання замовниками.
Одиниця релізу (Release Unit) - компоненти послуги, які зазвичай компонуються разом і випускаються в рамках одного релізу. Одиниця релізу зазвичай включає в себе компоненти, необхідні для виконання будь-якої корисної функції. Наприклад, Одиницею релізу може бути настільний комп'ютер. що включає в себе програмне, апаратне забезпечення. ліцензії, документацію і т.п. Іншим прикладом Одиниці релізу може служити ціле додаток для розрахунку зарплати, включаючи процедури операційного управління IT та тренінги користувачів [1].
Важливо визначити відповідний рівень Одиниці релізу для кожного активу і компонента. Необхідно враховувати такі фактори:
- простота і кількість змін, необхідних для релізу і розгортання;
- кількість ресурсів і часу, необхідне для складання, тестування і розгортання;
- складність взаємозв'язків між одиницею і іншими послугами і компонентами;
- зберігання, доступне в рамках збірки, тестування, поширення та експлуатації [16].
Підхід перетворення нової або зміненої послуги визначається в рамках етапу Проектування. Існує дві опції впровадження:
- "Великий вибух" - нова або змінена послуга розгортається відразу для всіх користувачів в рамках однієї операції;
- пофазового підхід - послуга розгортається поетапно. Спочатку однієї частини користувачів, потім іншим.
На рис. 9.1 представлено застосування двох підходів.
- Реліз 1 - початкова установка на три робочі станції (1-3). Дві інші станції додаються в той же період часу (4-5);
- Реліз 2 - використання підходу "великий вибух" для розгортання. Реліз встановлюється відразу на п'ять робочих станцій (1-5). На іншому етапі на дві додаткові станції (6-7);
- Реліз 3 - пофазового підхід для розгортання. Спочатку оновлюється тільки три робочі станції (1-3), потім ще чотири (4-7). Ще одна станція додається на наступному етапі (8).
Пофазового підхід має наступні варіації:
- порції послуги надаються для використання за фазами, але всі користувачі будуть підключені до неї одночасно;
- кожен реліз розгортається поступово в залежності від кількості кінцевих користувачів;
- різні елементи послуги розгортаються в рамках різних фаз;
- комбінований підхід, що застосовує всі описані вище.
Пофазового підхід можливий тільки в тому випадку, якщо стара і оновлена послуги сумісні і можуть працювати одночасно.
Розглянемо послідовність дій в рамках Управління релізами і розгортанням.
Для розгортання релізу необхідно розробити різні плани, зокрема, Плани релізів і розгортання. Вони повинні визначати:
- охоплення і контекст релізу;
- оцінку ризиків для релізу;
- організації та окремі особи, яких торкнеться реліз;
- інвесторів, які затвердили запит на зміну;
- команду, відповідальну за реліз;
- підхід до взаємодії з інвесторами і групами розгортання, який визначає:
- стратегію надання і розгортання;
- ресурси для релізу і розгортання;
- кількість змін, які можуть бути здійснені.
В рамках Впровадження повинні бути визначені критерії, які дозволять встановити успішність виконання кожної стадії релізу і розгортання. Результат виконання або приймається - pass. або відхиляється - fail. Звідси критерії називаються прийом / відхилення (pass / fail) критерії.
Приклад, коли результат приймається:
- Всі тести завершені успішно; звіт з оцінки та RFC для збірки і тестування підписані.
Приклади, коли результати відхиляються:
- недолік ресурсів для переходу на наступну стадію. Наприклад, тестування показало недостатність фінансових коштів для надання спроектованої послуги на стадії експлуатації;
- етап Експлуатації послуг не може надати окремі атрибути послуг;
- етап Проектування послуг розробив проект, який не відповідає встановленим стандартам, технологіям, вимогам регуляторів і т.п.
- послуга не може бути надана відповідно до обмежень, накладеними на етапі Проектування;
- не виконуються критерії приймання послуги;
- необхідні документи не підписані;
- SKMS і CSM без оновлення і містять неактуальну інформацію;
- кількість інцидентів, проблем і ризиків вище, ніж передбачалося спочатку.
Перед передачею послуги в промислову експлуатацію, необхідно зробити ряд дій по збірці і тестування різних середовищ. Діяльність в рамках планування збірки і тестування полягає в:
- формування планів збірки виходячи з проектної документації, специфікацій, вимог до конфігурації обладнання;
- формування команд супроводу, логістики і збірки, необхідних для підтримки середовищ;
- тестування збірки;
- складання розкладів для тестування і складання;
- призначення ролей, розподіл ресурсів і відповідальності для ключових діяльностей;
- узгодження критеріїв приймання збірки.
Середовища, необхідні для релізу:
- середовище зборки - використовується для збору і комплектування пакета релізу;
- одинична середу тестування - використовується для перевірки функціональності, продуктивності, восстанавливаемости і корисності окремих компонентів послуги;
- комплект середовищ тестування - використовується для перевірки функціональності, продуктивності, восстанавливаемости і корисності комплекту компонентів послуги;
- Середа інтеграції - використовується для складання і інтеграції компонентів послуги;
- середу тестування послуги - використовується для тестування всіх аспектів об'єднаної архітектури послуги;
- середу тестування релізу - використовується для установки, збірки і тестування пакету релізу в контрольованому середовищі; зазвичай поєднана з середовищем тестування послуги.
- середу тестування готовності до експлуатації - для тестування можливостей послуги та її компонентів перед передачею в промислову експлуатацію;
- среда, що симулює бізнес-середовище;
- среда, що симулює Управління послугами;
- середовище для навчання;
- середовище для пілотування;
- середовище для резервного копіювання та відновлення.
Для тестування послуги на маленькій частині користувачів використовуються пілоти. Пілот (Pilot) - обмежене розгортання послуги, релізу або процесу в середовищі промислової експлуатації. Пілот використовується для скорочення ризиків і отримання зворотного зв'язку, а також приймання від користувачів [1]. При цьому важливо визначити оптимальний охоплення пілота. Якщо він буде занадто маленьким, буде некоректно відображена функціональність послуги і не виявляться багато помилок. Для пілотування також повинні формуватися плани.
Планування збірки пакета релізів містить наступні процедури:
- перевірка критеріїв входу / виходу;
- взаємодія з інвесторами:
- управління контрактами та їх деталями;
- доведення до інвесторів інформації про пропоновані зміни, вигоді, яку вони можуть принести і супутніх витратах і ризики
- настройка систем і навчання користувачів для роботи з новою або зміненої послугою;
- розробка можливостей і ресурсів для сервіс-менеджменту;
- оцінка готовності цільової групи до використання релізу;
- визначення та узгодження критеріїв для виходу.
В рамках складання планів розгортання необхідно відповісти на наступні питання:
- для кого призначене розгортання?
- хто буде користувачами?
- чи є якісь особливості розташування? (наприклад, якісь додаткові вихідні в залежності від регіону)
- де користувачі? (Наприклад, чи є віддалені користувачі або всі користувачі будуть працювати в одному місці)
- хто ще повинен бути підготовлений до релізу? (Наприклад, чи потрібно додаткове навчання персоналу сервіс-Деск)
- коли необхідно завершити розгортання?
- чому необхідно розгортання? (Наприклад, щоб виправити якусь проблему або збільшити функціональність)
- які чинники успіху і критерії виходу? (Як дізнатися, що розгортання пройшло успішно і може бути завершено)
- які поточні можливості постачальника послуг?
Далі розробляються Плани постачання і надання. Вони визначають наступне:
- як і коли реліз і його компоненти будуть надаватися?
- які є команди супроводу, і що буде в разі затримки?
- як відстежити прогрес в наданні та необхідність його завершення?
- чи є можливість захищеного зберігання, якщо буде потрібно?
Перш ніж додавати якісь дії в плани розгортання, необхідно здійснити фінансове планування. Воно розглядає питання виділення коштів для забезпечення діяльностей, придбання необхідного обладнання та ліцензій, наявні контракти та зобов'язання.
Після того, як детальні плани для кожної діяльності в рамках Управління релізами і розгортанням складені, настає етап підготовки до складання, тестування і розгортання. На цьому етапі відбувається оцінка ризиків, можливих проблем і невідповідностей в проектній документації. Оцінка перевіряє, чи принесе зміна бажані результати. Формується звіт, в якому містяться рекомендації про затвердження зміни або його відхилення.
Якщо зміна затверджено, настає етап побудови та тестування. Ключові аспекти, якими необхідно управляти в рамках цього етапу:
- використання середовищ збірки і тестування;
- стандартизація та інтеграція;
- управління конфігураціями:
- в ході діяльностей по збірці і тестування - контроль версій, управління базовим станом, контроль входів і виходів етапу побудови та тестування;
- ведення звітності, яка дозволить здійснити збірку знову при виникненні необхідності;
- управління наочністю тестування - формування звітів по тестуванню;
- контроль доступу до фізичних компонентів і технологій;
- перевірка виконання вимог безпеки;
- перевірка діяльностей - всі необхідні умови виконані;
- управління питаннями середовища - кондиціонування, електроживлення, фізичне місце, пожежна сигналізація і т.п.
- перевірка готовності релізу до передачі на наступну стадію;
- передача релізу на наступну стадію.
У ITIL вводиться поняття "базове стан". Базове стан (Baseline) - зафіксоване стан, що використовується як орієнтир (контрольна точка) [1]. Трактування залежить від контексту. В контексті Впровадження базове стан може бути використано для повернення інфраструктури до початкової конфігурації в разі, якщо впровадження релізу виявилося невдалим. Інформація про базові станах конфігурацій зберігається в CMS.
Для складання релізу необхідно об'єднати безліч компонентів, активів і продуктів від зовнішніх і внутрішніх постачальників. У цьому велику роль відіграє документація - угоди, контракти, ліцензії і т.п. Діяльність з придбання компонентів включає в себе:
- взаємодія з процесами постачання для придбання компонентів;
- збір:
- інформації про нові та оновлені активах і конфігураційних одиницях від SACM;
- квитанцій і чеків;
- документації надання, релізу та зміни від постачальника.
- перевірка, моніторинг і ведення звітності про якість надходять конфігураційних одиниць і компонентів послуг;
- забезпечення того, що наявність ліцензії можна буде довести при виникненні необхідності;
- відповідні дії в разі, якщо якість, отримане на практиці, відрізняється від очікуваного, і оцінка впливу зниження якості на впровадження в цілому;
- оновлення статусів конфігураційних одиниць в SACM.
Після того, як все необхідне куплено, документація готова, можна приступити до складання пакета релізів. При складанні релізів важливо розуміти, що продукт надійде скоро в промислове виробництво, отже, використані в рамках збірки процедури повинні бути повторимо в разі потреби.