Что такое управление релизами и чем оно отличается от развёртывания

Зачем управление релизами

ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 отвечает за один шаг, который часто путают с соседними: сделать новое доступным для использования 1. Речь именно о включении: открыть людям доступ и убедиться, что они смогут этим пользоваться, — постройка и перенос на серверы происходят до этого и в других практиках.

ГОСТ Р ИСО/МЭК 20000-1 формулирует свою часть требованиями. Типы релизов, включая аварийные, их частота и способ управления должны быть определены. Внедрение планируется в связке с управлением изменениями. Сам релиз сверяют с критериями приёмки и утверждают до внедрения 2.

Главная мысль практики выглядит как формальность ровно до первого разговора о том, почему пользователи не пользуются новым.

Развернуть — значит поставить в рабочую среду. Выпустить — значит открыть людям и сделать так, чтобы они смогли этим пользоваться 1.

Отсюда работа, которую редко записывают в выпуск: обучение, объявления, документация, поддержка первых дней. Выпуск бывает простым и техническим — сменить статус версии в хранилище, — а бывает сложным и человеческим, вплоть до обучения пользователей ради снижения рисков перехода 1.

Когда практика работает

Три вопроса, ответы на которые видны в день выпуска.

Известно, что именно выпускаем и кому. Как проверить: у релиза есть состав, аудитория и дата, а не только номер сборки.

Есть заранее описанный тип выпуска. Как проверить: типы релизов и их частота определены — этого требует ГОСТ Р ИСО/МЭК 20000-1 2.

Есть план на случай неудачи. Как проверить: шаги на случай неудачного развёртывания продуманы до начала — этого требует FitSM 3.

Что входит и что рядом

Выпуск и развёртывание: две модели работы

Границу устраивают двумя способами, и выбор между ними определяет всё остальное 1.

Совмещённый. Как только компонент попал в рабочую среду, он доступен пользователям. Сосуществование версий редко и коротко, чёткой границы между выпуском и развёртыванием нет. Так обычно работают с оборудованием и большими монолитными системами.

Разделённый. Новая версия сначала развёртывается, а выпускается позже — для всех или для части пользователей. Работа практики сводится к включению доступа: сменить статус версии, открыть её выбранной аудитории. Этот способ пришёл вместе с гибкой разработкой и облачными решениями.

При непрерывном развёртывании второй способ распространён и эффективен: новые версии попадают в рабочую среду сразу по готовности, а практика выпусков «включает» их пользователям 1.

Отсюда и ответ на вечный спор «релиз — это то же самое, что развёртывание?». Решают не термины, а то, какая из двух моделей у вас работает.

Что на входе и что на выходе

Практика собирает готовое и решает, когда и кому это откроется. На входе — разрешённые изменения, проверенные сборки, требования заказчика и регуляторов; на выходе — работающее у людей новое и материалы, которые помогают им это освоить.

Особенность связей: практика опирается на службу поддержкиСлужба поддержки (service desk)Единая точка контакта между теми, кто пользуется ИТ-услугами, и теми, кто их предоставляет: сюда приходит обращение и здесь оно должно быть зафиксировано.ITIL 4, практическое руководство Service Desk; MOF 4.0. Именно туда придут первые вопросы, и её готовность к выпуску — часть плана выпуска, а не любезность.

Кто решает, переходить ли

Одно из решений, которое закладывается в модель выпуска 1. В руководстве эти два подхода называются push и pull.

Выбор взвешивают по шести соображениям 1. Выгода единой версии — для поддержки и совместимости. Выгода свободы выбора — для образа компании и гибких тарифов. Дальше: можно ли технически и организационно вести несколько версий сразу, насколько критично изменение, чего требует заказчик и чего требуют регуляторы.

Смешанный вариант — норма: часть обновлений включают всем, часть оставляют на усмотрение пользователя 1.

Выпуск как способ проверить гипотезу

Практику можно использовать не только чтобы отдать готовое, но и чтобы узнать, работает ли задумка. Это называют проверкой гипотез: услуга выпускается для выборочной группы пользователей, и по её поведению делается вывод 1.

ITIL перечисляет приёмы 1:

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

Такие эксперименты требуют участия соседей: инфраструктуры, разработки, развёртывания, архитектуры, службы поддержки и разбора инцидентовИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами 1. То есть канареечный выпуск без готовности службы поддержки — это эксперимент, поставленный на пользователях без наблюдателя.

Как это работает

Работа делится надвое: наладить подход к выпускам — и провести конкретный выпуск 1.

Цвет шага: приём, учёт, работа с обращением техническая работа проверка, разбор, улучшение

Три места стоит объяснить отдельно.

Первый шаг — требование ГОСТа. Типы релизов, включая аварийные, их частота и способ управления должны быть определены 2. Организация, где каждый выпуск — событие с индивидуальным сценарием, тратит на согласования больше, чем на работу.

Четвёртый шаг решает судьбу выпуска. Релиз сверяют с записанными критериями приёмки и утверждают до внедрения; при несоблюдении критериев решение принимают вместе с заинтересованными сторонами 2. FitSM добавляет здравую оговорку: объём проверки соответствует типу релиза и его возможному влиянию на услугиУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation 3.

Седьмой шаг питает первый. Стоит пересматривать подходы и модели раз в два-три месяца или чаще, если существующие плохо работают 1.

Что с чем путают

Релиз и развёртывание. Разобрано выше, в блоке про две модели.

Релиз и изменение. Изменение разрешает работу, релиз её упаковывает и отдаёт людям. ГОСТ требует согласовывать планирование релизов с управлением изменениями и ссылаться на конкретные запросы, ошибки и проблемыПроблемаПричина одного или нескольких инцидентов.ITIL, которые релиз закрывает 2.

Релиз и сборка. Сборка — технический артефакт. Релиз — решение о том, что эта сборка становится доступна такой-то аудитории с такой-то даты.

Релиз и проект. Крупный выпуск может вестись как проект, но практика отвечает за порядок выпуска, а не за управление работами 1.

Библиотека проверенного

MOF требует того, чего нет в современных руководствах, а зря. Все версии программных элементов, чьё развёртывание утверждено, кладут в защищённую библиотеку — целиком и в проверенном виде. Библиотека названа надёжным источником того, что работает в рабочей среде 4.

Сегодня эту роль играют хранилища артефактов и образов, но требование от этого не изменилось: то, что уезжает пользователям, должно браться из одного проверенного места, а не собираться на машине разработчика.

Кто участвует

Как измерять

Рядом стоит держать две меры: частоту выпусков и долю выпусков без отката. По отдельности первую разгоняют в ущерб надёжности, вторую поднимают, выпуская реже.

Единственная метрика во всей книге, где обе границы — ноль. Число непротестированных релизов: и цель, и тревога равны нулю 7. У Брукса нет допуска даже в одну штуку, и обоснование он даёт прямое — тестировать положено и срочные релизы тоже. Показатель тем и хорош, что не поддаётся усреднению: он либо ноль, либо разговор.

Рядом — срочные релизы: цель 0 при тревоге в 5 7. Пара работает вместе с парой из таблицы выше. Срочность — обычное оправдание пропущенной проверки, и когда оба числа на одной панели, оправдание перестаёт работать: видно, сколько раз спешили и сколько раз это стоило проверки.

Разброс у инцидентов после выпуска в десять раз — цель 5, тревога 50 7. Такой коридор не небрежность, а признание: число зависит от размера релиза и числа пользователей сильнее, чем от качества работы. Точнее меряется соседний показатель — точность оценки трудозатрат: цель 80%, тревога ниже 60. Она показывает не скорость, а то, насколько команда понимает, за что берётся.

Числа Брукса — образцы для настройки под свой ритм выпусков, не отраслевая норма. Переносится привычка держать у показателя цель и порог вмешательства.

Зрелость управления релизами

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

Выпуск равен развёртыванию по умолчанию. Никто не решал, как устроена граница, и включение новых возможностей происходит само, вместе с переносом в рабочую среду 1.

Типы релизов не определены. Каждый выпуск согласуется индивидуально, аварийный порядок придумывается на ходу — хотя ГОСТ требует определить типы и частоту 2.

Пользователей не готовят. Версия включена, инструкций нет, служба поддержки узнаёт о новом от пользователей.

Критерии приёмки формальны. Проверка сводится к «собралось» — а ГОСТ требует сверять релиз с записанными критериями приёмки 2.

План отката не продуман. FitSM прямо требует предусмотреть шаги на случай неудачного развёртывания 3.

Разбор выпусков не проводится. Модели не меняются, и те же грабли повторяются от выпуска к выпуску 1.

Что говорят своды

Своды знаний и стандарты, которые описывают эту практику:

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL держит выпуск и развёртывание разными практиками и объясняет, зачем: в современных решениях они разнесены во времени 1.

ГОСТ Р ИСО/МЭК 20000-1 объединяет релизы и внедрение одним пунктом и требует определить типы и частоту, планировать в связке с изменениями, сверять релиз с критериями приёмки и отчитываться о результатах 2.

FitSM тоже держит их одним процессом и добавляет соразмерность: объём проверки зависит от типа релиза и его влияния 3.

COBIT выделяет передачу и приёмку изменений отдельной целью управленияЦель управленияЕдиница описания COBIT: цель с проверяемым содержанием, у которой есть процесс того же имени.COBIT 2019, книга Governance and Management Objectives, отдельно от управления изменениями 5.

MOF разводит разработку с тестированием и выпуск как отдельные шаги и требует защищённой библиотеки проверенного ПО 4.

Расхождение здесь одно и практическое: разделять выпуск и развёртывание имеет смысл там, где вы умеете держать в рабочей среде то, что ещё не включено пользователям. Если такой возможности нет, разделение остаётся терминологическим.

Где описано

Что почитать дальше

Три соседние практики, между которыми живёт выпуск: CHNКонтроль изменений — где изменение получает разрешение, DEPУправление развёртыванием — как оно попадает в рабочую среду, TSTПроверка и тестирование услуг — как проверяют, что можно выпускать.