- Потенциального воздействия релиза на другие компоненты.
- Количества человеко-часов и времени на компоновку и тестирование раздельных изменений, в сравнении с усилиями, необходимыми для их объединения и одновременного внедрения.
- Трудности инсталляции на местах пользователей. Возможно, что инсталлировать полную программу легче благодаря наличию для этого стандартных методов.
- Сложности взаимосвязей между новым программным и аппаратным обеспечением и остальной частью ИТ-инфраструктуры – чем легче изолировать программные или аппаратные средства, тем легче их тестировать.
Перед планированием релиза необходимо собрать информацию о жизненном цикле внедряемого продукта, а также обо всех подготовленных к сдаче в рамках данного релиза продуктах, описании соответствующих ИТ-услуг и их уровней и данные об авторизации соответствующих Запросов на Изменения (RFC) и т. д. При планировании релиза рассматриваются следующие вопросы:
- координация содержания релиза;
- разработка графика ввода релиза;
- согласование графика, территориальных объектов, на которых произойдет распространение релиза, и организационных единиц;
- посещение объектов для определения реально используемых аппаратных и программных средств;
- разработка плана оповещения (коммуникаций);
- согласование ролей и ответственностей;
- получение подробных коммерческих предложений и переговоры с поставщиками о новых аппаратных и программных средствах, а также услугах по их инсталляции;
- разработка планов на случай возврата к исходному состоянию;
- разработка плана обеспечения качества релиза;
- планирование приемки релиза руководством и пользователями.
Результаты этой деятельности представляют собой часть плана проведения изменения и включают планы релиза, планы тестирования и критерии приемки.
Рекомендуется выработать стандартные процедуры проектирования, компоновки и конфигурирования релизов. Основой релизов могут быть наборы компонентов (Конфигурационных Единиц – CI), разработанные внутри организации или закупленные у третьей стороны и прошедшие этап конфигурирования. Руководства по инсталляции и конфигурированию релизов должны рассматриваться как часть релиза и в качестве Конфигурационных Единиц должны включаться в число объектов, находящихся под контролем Процессов Управления Изменениями и Управления Конфигурациями.
Перед инсталляцией на месте рекомендуется настроить и протестировать все аппаратное и программное обеспечение в "лабораторных условиях". Компоненты программных и аппаратных средств необходимо тщательно конфигурировать и зарегистрировать, чтобы обеспечить возможность их многократного воспроизведения. Необходимо разработать рабочие инструкции таким образом, чтобы каждый раз воспроизводился один и тот же набор компонентов. Часто в резерве имеются стандартизированные аппаратные средства, которые используется только для компилирования или создания образов ПО[137]. Для надежности желательно, чтобы эта часть процесса была автоматизирована. Необходимые для этого программные и аппаратные средства также попадают в сферу действия Процесса Управления Релизами. В среде разработки программ такая деятельность называется Управлением Компоновкой[138]и входит в зону ответственности Управления Релизами.
План возврата к исходному состоянию
В плане возврата к исходному состоянию на уровне релиза в целом определяются действия, необходимые для восстановления услуг в случае сбоя во время внедрения (имплементации) релиза. Ответственность за разработку планов возврата несет Процесс Управления Изменениями, но Управление Релизами должно оказывать в этом помощь для обеспечения практической реализуемости этих планов. В частности, при внедрении пакетного релиза, объединяющего несколько Запросов на Изменения (RFC), может возникнуть необходимость координации различных планов возврата для этого релиза. Если возникает сбой Полного релиза или Дельта-релиза, рекомендуется свернуть релиз полностью до Прежнего стабильного состояния[139]. На случай невозможности полного свертывания релиза должны существовать Планы восстановления на случай чрезвычайных обстоятельств[140]для возобновления предоставления услуг.
Требования плана возврата к исходному состоянию, такие как создание резервных копий и обеспечение запасного сервера, рекомендуется выполнять заранее. В случаях, если внедрение может занять больше времени, чем предполагается, и если задержка может поставить под угрозу нормальное предоставление услуг, в план возврата должен включаться крайний срок, определяющий время приведения в действие плана возврата. Это требуется для своевременного возобновления услуг (например, не позднее 7:00 в понедельник). План возврата к исходному состоянию должен включаться в анализ рисков изменения и должен быть одобрен пользователями.
Реальная компоновка релиза может включать компилирование и связывание программных модулей, или наполнение баз данных тестовыми данными, или такими данными, как таблицы почтовых индексов, налоговых ставок, часовых поясов и валютных курсов, а также информацией о пользователях. Часто это выполняется автоматизированными инсталляционными скриптами[141], хранящимися в Библиотеке DSL вместе с планами возврата. Полные релизы должны отражаться в базе CMDB как Стандартные Конфигурации для облегчения конфигурирования в будущем. Планы тестирования должны включать тестирование и приемку по качеству программного и аппаратного обеспечения, процедур, инструкций по операционной деятельности и сценариев (скриптов) развертывания[142]перед выходом релиза и, возможно, оценочные испытания после внедрения релиза. Должно также проводиться тестирование инсталляционных скриптов. Для этого требуется следующая информация:
- определение релиза[143];
- график ввода релиза;
- инструкции по конфигурированию и компоновке релиза;
- описание позиций, требующих приобретения или лицензирования, с приложением графиков закупки;
- автоматизированные инсталляционные скрипты и планы тестирования;
- исходные копии кодов программ для включения в библиотеку DSL;
- планы возврата к исходному состоянию
Наиболее частой причиной неудовлетворительного внедрения изменений и релизов является неадекватность тестирования. Для предотвращения этого перед внедрением релиза должно проводиться функциональное тестирование представителями пользователей и операционное (эксплуатационное) тестирование персоналом ИТ, оценивающим технические характеристики, функциональность, операционные (эксплуатационные) аспекты, производительность и интеграцию с остальной частью инфраструктуры. Также должны тестироваться инсталляционные скрипты, процедуры возврата и любые изменения процедур управления. Формальная приемка каждого этапа должна быть представлена в Процессе Управления Изменениями. Последним этапом является утверждение внедрения релиза.
Перед тем, как Процесс Управления Релизами начнет развертывание релиза, Процесс Управления Изменениями должен организовать формальную приемку релиза пользователями и его окончательную сдачу разработчиками.
Релизы должны приниматься в контролируемой тестовой среде, состоящей из Базовых Конфигураций, которые должны быть подробно описаны в ходе определения релиза. Соответствующие Базовые Конфигурации должны быть зарегистрированы в CMDB. Если релиз не принимается, он возвращается в Процесс Управления Изменениями.
Результатами деятельности по тестированию и приемке релиза являются:
- протестированные процедуры инсталляции;
- протестированные компоненты релиза;
- известные ошибки и недостатки релиза;
- результаты тестирования;
- документация для управления и поддержки;
- перечень систем, подвергающихся воздействию;
- операционные (эксплуатационные) инструкции[144]и средства диагностики;
- планы на случай непредвиденных ситуаций и протестированные планы возврата;
- программы обучения персонала, руководителей и пользователей;
- подписанные приемо-сдаточные документы;
- авторизация из Процесса Управления Изменениями для выполнения релиза.
Составленный на предыдущих этапах план теперь дополняется информацией о действиях по внедрению.
Планирование развертывания релиза включает:
- составление графика, а также перечня задач и требуемых людских ресурсов;
- составление перечня инсталлируемых и снимаемых с использования Конфигурационных Единиц, с указанием способа вывода из операционной среды;
- составление плана действий для каждого территориального объекта с учетом запаса времени на развертывание и часовых поясов, если речь идет о географически распределенных организациях;
- рассылку уведомлений о релизе и другие контакты с вовлеченными сторонами;
- составление планов закупки аппаратного и программного обеспечения;
- закупку, размещение на хранение, определение и регистрацию всех новых CI для данного релиза в базе CMDB;
- планирование встреч с руководством, управляющими подразделениями, персоналом по Управлению Изменениями и представителями пользователей[145].
Существует несколько способов осуществления развертывания:
- полное развертывание релиза – подход "большого скачка";
- поэтапное развертывание релиза, включающее несколько разновидностей:
- функциональное наращивание, когда все пользователи получают одновременно новые элементы функциональности;