• координация содержания релиза;

• разработка графика ввода релиза;

• согласование графика, территориальных объектов, на которых произойдет распространение релиза, и организационных единиц;

• посещение объектов для определения реально используемых аппаратных и программных средств;

• разработка плана оповещения (коммуникаций);

• согласование ролей и ответственностей;

• получение подробных коммерческих предложений и переговоры с поставщиками о новых аппаратных и программных средствах, а также услугах по их инсталляции;

• разработка планов на случай возврата к исходному состоянию;

• разработка плана обеспечения качества релиза;

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

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

8.4.2. Проектирование, компоновка и конфигурирование

Рекомендуется выработать стандартные процедуры проектирования, компоновки и конфигурирования релизов. Основой релизов могут быть наборы компонентов (Конфигурационных Единиц – CI), разработанные внутри организации или закупленные у третьей стороны и прошедшие этап конфигурирования. Руководства по инсталляции и конфигурированию релизов должны рассматриваться как часть релиза и в качестве Конфигурационных Единиц должны включаться в число объектов, находящихся под контролем Процессов Управления Изменениями и Управления Конфигурациями.

Перед инсталляцией на месте рекомендуется настроить и протестировать все аппаратное и программное обеспечение в «лабораторных условиях». Компоненты программных и аппаратных средств необходимо тщательно конфигурировать и зарегистрировать, чтобы обеспечить возможность их многократного воспроизведения. Необходимо разработать рабочие инструкции таким образом, чтобы каждый раз воспроизводился один и тот же набор компонентов. Часто в резерве имеются стандартизированные аппаратные средства, которые используется только для компилирования или создания образов ПО [137] . Для надежности желательно, чтобы эта часть процесса была автоматизирована. Необходимые для этого программные и аппаратные средства также попадают в сферу действия Процесса Управления Релизами. В среде разработки программ такая деятельность называется Управлением Компоновкой [138] и входит в зону ответственности Управления Релизами.

План возврата к исходному состоянию

В плане возврата к исходному состоянию на уровне релиза в целом определяются действия, необходимые для восстановления услуг в случае сбоя во время внедрения (имплементации) релиза. Ответственность за разработку планов возврата несет Процесс Управления Изменениями, но Управление Релизами должно оказывать в этом помощь для обеспечения практической реализуемости этих планов. В частности, при внедрении пакетного релиза, объединяющего несколько Запросов на Изменения (RFC), может возникнуть необходимость координации различных планов возврата для этого релиза. Если возникает сбой Полного релиза или Дельта-релиза, рекомендуется свернуть релиз полностью до Прежнего стабильного состояния [139] . На случай невозможности полного свертывания релиза должны существовать Планы восстановления на случай чрезвычайных обстоятельств [140] для возобновления предоставления услуг.

Требования плана возврата к исходному состоянию, такие как создание резервных копий и обеспечение запасного сервера, рекомендуется выполнять заранее. В случаях, если внедрение может занять больше времени, чем предполагается, и если задержка может поставить под угрозу нормальное предоставление услуг, в план возврата должен включаться крайний срок, определяющий время приведения в действие плана возврата. Это требуется для своевременного возобновления услуг (например, не позднее 7:00 в понедельник). План возврата к исходному состоянию должен включаться в анализ рисков изменения и должен быть одобрен пользователями.

Реальная компоновка релиза может включать компилирование и связывание программных модулей, или наполнение баз данных тестовыми данными, или такими данными, как таблицы почтовых индексов, налоговых ставок, часовых поясов и валютных курсов, а также информацией о пользователях. Часто это выполняется автоматизированными инсталляционными скриптами [141] , хранящимися в Библиотеке DSL вместе с планами возврата. Полные релизы должны отражаться в базе CMDB как Стандартные Конфигурации для облегчения конфигурирования в будущем. Планы тестирования должны включать тестирование и приемку по качеству программного и аппаратного обеспечения, процедур, инструкций по операционной деятельности и сценариев (скриптов) развертывания [142] перед выходом релиза и, возможно, оценочные испытания после внедрения релиза. Должно также проводиться тестирование инсталляционных скриптов. Для этого требуется следующая информация:

• определение релиза [143] ;

• график ввода релиза;

• инструкции по конфигурированию и компоновке релиза;

• описание позиций, требующих приобретения или лицензирования, с приложением графиков закупки;

• автоматизированные инсталляционные скрипты и планы тестирования;

• исходные копии кодов программ для включения в библиотеку DSL;

• планы возврата к исходному состоянию

8.4.3. Тестирование и приемка релиза

Наиболее частой причиной неудовлетворительного внедрения изменений и релизов является неадекватность тестирования. Для предотвращения этого перед внедрением релиза должно проводиться функциональное тестирование представителями пользователей и операционное (эксплуатационное) тестирование персоналом ИТ, оценивающим технические характеристики, функциональность, операционные (эксплуатационные) аспекты, производительность и интеграцию с остальной частью инфраструктуры. Также должны тестироваться инсталляционные скрипты, процедуры возврата и любые изменения процедур управления. Формальная приемка каждого этапа должна быть представлена в Процессе Управления Изменениями. Последним этапом является утверждение внедрения релиза.