■ средства поддержки Релизов АО и ПО в среду эксплуатации, например, средства распространения ПО;.

■ персонал, обеспечивающий поддержку Управления релизами;.

■ обучение;.

■ рекомендации по составлению графиков событий в рамках организации, а также создание общего графика Релизов, включающего события, которые можно спрогнозировать (например, организация может дать поручение, чтобы все события записывались определенным образом или с использованием определенной базы данных событий);.

■ шаблоны документов для помощи в планировании конкретных Релизов;.

■ управление и использование соответствующих и эффективных сред сборки и тестовой среды;.

■ обеспечение наличия правильных механизмов проведения Релизов;.

■ обеспечение достаточного дискового пространства в среде сборки, тестовой среде, среде распространения и среде эксплуатации для проведения успешного Релиза.

Процедуры должны быть задокументированы для:.

■ проектирования, сборки и развертывания Релиза в организации;.

■ Релиза и распространения ПО, включая контроль и поддержку DSL;.

■ закупок, инсталляции, переноса и контроля ПО и АО, которое относится к Управлению релизами;.

■ управления и использования средств и оборудования поддержки;.

■ отслеживания действий Управления релизами, их анализа, управления рисками и эскалации Проблем.

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

Политика Релизов.

Следует создать документ, содержащий политику Релизов в организации, который четко объяснит роли и обязанности в Управлении релизами. Это может быть один документ на всю организацию или же свод рекомендаций и определенных сведений для каждой поддерживаемой системы или ИТ-услуги. Политика Релизов обычно составляет часть общего плана Управления изменениями в организации.

Политика Релизов пересматривается и расширяется, когда организация вводит новую техническую инфраструктуру. Новые пилотные процедуры Управления релизами должны входить в проект по внедрению новой инфраструктуры. Например, может потребоваться разработка нового подхода к релизам ПО, если организация решит ввести новую платформу АО или ПО. Это может быть что-то незначительное, например, новый язык программирования или очень крупное, например, совершенно новая аппаратная платформа со своей операционной системой или системой управления сетью.

Политика Релизов должна включать следующее:.

■ указания относительно уровня контроля ИТ-инфраструктуры для каждого определенного типа Релиза (например, системы приложений или отдельные программные файлы);.

■ правила именования и нумерации Релизов;.

■ определение комплексных и частичных релизов, а также политику выпуска срочных решений;.

■ указания по частоте проведения комплексных и частичных Релизов (например, для какой-либо организации может быть нормой планирование графика на год вперед, а проведение комплексного Релиза - ежеквартально);.

■ идентификация критичных для бизнеса периодов, в течение которых следует избегать внедрений, а также требования по управлению такими периодами (например, организация может решить не проводить изменения в системе начисления зарплаты в последние две недели каждого месяца, тем самым, выделяя временной период, в течение которого можно планировать новые Релизы);.

■ ожидаемые результаты для каждого типа Релиза (например, инструкции по инсталляции и описание Релиза);.

■ указания, как и где Релизы должны документироваться (например, как и какое средство следует использовать);.

■ политика, связанная с созданием и степенью тестирования планов отката;.

■ согласованные роли, обязанности центрального подразделения Управления релизами в техническом анализе архитектуры приложений и проектировании;.

■ описание процесса контроля Управления релизами (например, собраний для проведения анализа, оценок хода выполнения (контрольных точек), эскалации, анализа влияния, проверки сопутствующих требований);.

■ документирование точной конфигурации DSL и определение критериев приемки для добавления нового ПО (ниже приведено несколько примеров правил).

Примеры правил по добавлению ПО в DSL:.

■ все элементы являются подлинными и были заказаны или получены законно;.

■ все ПО соответствует ожиданиям, и отсутствуют вредоносные дополнения (это может представлять особую проблему для пакетов ПО для ПК, которые могут содержать вирусы);.

■ все разработанное ПО успешно прошло задокументированный анализ качества;.

■ все дополнения к предыдущим версиям были авторизованы Управлением изменениями и никакие другие дополнения включены не были - это может потребовать наличия средств сравнения файлов;.

■ все элементы, которые добавляются в DSL, были корректно зарегистрированны в CMBD. При добавлении этих элементов CMDB должна быть обновлена (если это не происходит автоматически как часть процедуры добавления файлов в DSL).

Процедуры планирования Релиза и развертывания.

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

■ понимания стандартов инфраструктуры организации и требований Управления релизами;.

■ понимания требований Управления услугами и операционных требований, включая инструкции о том, как справляться с отказами, зависимостями и другими операционными требованиями;.

■ указаний, как осуществлять проектирование, сборку и конфигурацию Релиза для каждой платформы;.

■ понимания процедур приемки Релизов, включая определение критериев их ввода и вывода;.

■ изучения того, как использовать шаблоны планирования развертывания для содействия проектным группам, объединяющим все требуемые действия и ресурсы;.

■ понимания требований по коммуникациям, подготовке и обучению;.

■ понимания процедур распространения и инсталляции (см. ниже).

Процедуры и документы для закупок, инсталляции, переноса и контроля ПО и АО, которое относится к Управлению релизами, включают в себя:.

■ запросы на закупку и заказы;.

■ лизинговые соглашения;.

■ лицензионные соглашения.

■ соглашения о поддержке;.

■ Соглашения об уровне обслуживания (например, для заказов нового АО или ПО).

■ процедуры по инсталляции и переносу оборудования;.

■ процедуры по удалению оборудования и носителей ПО;.

■ указания по технике безопасности и охране здоровья;.

■ политику и процедуры безопасности;.

■ планы Управления изменениями и Управления конфигурациями.

■ процедуры приемки и авторизации.

Проект может включать разработку Релиза конечного продукта. В этом случае следует четко определить взаимодействие между Управлением релизами и Управлением проектами. Для продуктов, разрабатываемых под контролем PRINCE2, авторизация Релизов требует наличия Уведомления об операционной приемке и Уведомления о приемке пользователем. Поскольку проект ограничен во времени, проверочная документация должна быть формально передана Управлению релизами для последующих ссылок и обновлений.

Процедуры распространения Релиза АО.

Распространение АО и создание необходимой среды для Релиза должно быть тщательно спланировано. Подробная информация по этому вопросу включена в книгу «Управление информационными и коммуникационными технологиями» (ICT Infrastructure Management).

Процедуры распространения Релиза ПО.

Следует документировать стандартные процедуры для распространения Релизов ПО от сред тестирования-сборки до среды (сред) эксплуатации и начала их использования в этой среде (средах). Там, где среда сборки не находится на том же компьютере, что и соответствующие тестовая среда (среды) или среда (среды) эксплуатации, важно использовать какое-либо соединение для коммуникаций или же какой-либо тип портативного магнитного носителя (переносной диск или магнитная лента).

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

Так же, как и при передаче содержимого сборки в целевую среду, часто необходимо выполнить некоторые дополнительные процессы на целевом компьютере, чтобы активировать работу нового ПО после его внедрения. Это активирование может включать такие действия, как архивирование предыдущих версий ПО и загрузку существующих рабочих данных в новую структуру базы данных. Кроме этого, это почти всегда влечет за собой некоторые действия по «активированию», например, переключение библиотеки или перезагрузку блока.

Если Релиз ПО должен быть распространен в большом количестве офисов, может понадобиться, чтобы все Пользователи начали использование нового Релиза в одно и то же время. Например, при изменении законодательства страны, которое должно вступить в силу в определенный день, или если задействована распределенная корпоративная база данных. Если Релиз должен внедряться одновременно в нескольких офисах, могут потребоваться особые действия. Масштабы Релиза могут потребовать того, чтобы его распространение во всех офисах было разнесено на длительный промежуток времени. Этот Релиз, находящийся в состоянии ожидания, может быть инсталлирован в каждом офисе и находиться в стадии подготовки к эксплуатационному внедрению. При этом имеется какой-либо «переключатель», который вводит все эти Релизы в эксплуатацию в определенное время. Такой переключатель может вызывать определенную команду либо в центральном контролирующем офисе, либо в различных распределенных офисах. Другой вариант - это какой-либо программный переключатель, который вводится в состав самого Релиза и активируется после определенного события. Релиз такого рода - крупное событие, которое может оказать значительное влияние на бизнес. Следовательно, он должен подлежать тщательному и полному тестированию, планированию и управлению.

Все необходимые скрипты и параметры, которые используются во время внедрения, должны контролироваться таким же образом, как и те, которые используются во время сборки. Цель - сделать процесс внедрения как можно более простым, защищенным от случайных ошибок и безопасным. В идеале, после того, как распространение Релиза успешно завершено, группа Управления релизами должна дать только одну команду с терминала или консоли для начала процесса внедрения. Также должна быть возможность из центра распространения осуществить проверку того, что внедрение прошло успешно. Если передача данных проходит посредством магнитного носителя, тогда неизбежна определенная «работа на местах». В идеале эти действия должны быть ограничены простой вставкой диска или кассеты, обновлением локальных процедур и руководств и т.п.

Если процесс распространения и внедрения не может контролироваться автоматически или из центра с использованием программных средств, тогда проверку того, что распространяемое ПО поступило вовремя и было проверено на подлинность каким-либо практичным способом, а также того, что это ПО вовремя вошло в эксплуатацию следует провести с помощью процедур, в которых участвуют люди. Эти процедуры должны включать следующие действия:.

■ передача информации от персонала центрального подразделения Управления релизами к персоналу, находящемуся в удаленных офисах, о том, когда ожидать доставку распространяемого ПО;.

■ предоставление отчетов персонала из удаленных офисов персоналу центрального Управления релизами, когда распространяемое ПО успешно получено;.

■ проверка центральным персоналом того, что все ПО получено в удаленных офисах в должном состоянии;.

М предоставление центральным персоналом четких инструкций о том, когда ПО должно быть внедрено;.

М подача в центр отчетов персонала из удаленных офисов о внедрении ПО.

Запись о Релизе в CMDB должна указывать на то, какие инсталляции должны получить Релиз. Необходимо обновлять CMDB для отражения ситуации о получении и внедрении Релиза в каждом удаленном офисе.

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

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

Роли и обязанности при Релизе.

Релизы, состоящие из множества типов различного ПО и АО, могут вовлекать большое количество персонала в процессы, связанные с развертыванием и управлением Релиза. Типовые обязанности по утверждению компонентов Релиза должны быть централизованно определены и затем по необходимости модифицированы для конкретных Релизов. Типичные роли - Менеджер изменений (см. главу 8). Менеджер релизов и Менеджер тестирования.

Там, где задействованы стандартные процедуры сборки и инсталляции, которые заранее определены и утверждены, целесообразно разрешить дальнейшие действия без постоянных ссылок на Управление изменениями (например, стандартная инсталляция прикладной программы на новую рабочую станцию). CMDB должна обновляться, предпочтительно автоматически, всякий раз для отображения выполненных изменений. Такой метод может быть разрешен только там, где каждая инсталляция удовлетворяет всем задокументированным обязательным условиям и соответствует согласованным операционным ограничениям, таким как ограничения в количестве дополнительных рабочих станций в каждом конкретном офисе.

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

Таблица 9.1 - Пример матрицы ответственности.

Рисунок 9.4 показывает участие Управления релизами и Управления изменениями в запросе на что-либо новое или находящееся за рамками согласованных операционных ограничений. Он также показывает, что для каждого запроса служба Service Desk может поставить дополнительные рабочие станции с теми же самыми спецификациями без прямого обращения к процессу Управление изменениями - до тех пор, пока эти действия находятся в рамках определенных операционных ограничений. При этом CMDB обновляется. То же самое относится к инсталляции какого-либо приложения на существующей рабочей станции в соответствии с утвержденными инструкциями. Таблица 9.1 помогает объяснить некоторые из этих ролей на примерах. Пакет установки для прикладной системы (например, новое приложение) выпускается «Менеджером по разработке прикладных систем», который НЕ является участником процесса Управления релизами и не входит в состав службы эксплуатации. Операционное управление связано с существующими системами, находящимися в эксплуатации, а «Разработка прикладных систем» связана с проектированием и сборкой следующего Релиза системы, которая в данном случае является прикладной системой (т.е. определенной конфигурацией системы и прикладного ПО).

Рисунок 9.4 - Управление релизами и Управление изменениями Кадровое обеспечение.

Необходимое количество персонала Управления релизами зависит от объема работ. Поскольку Управление релизами является важным звеном между разработкой приложений и их эксплуатацией, а также вовлечено во все важные Изменения в эксплуатируемых системах, должно быть достаточное количество обученного персонала для обеспечения работы во время ежегодных отпусков и отсутствия сотрудников на рабочем месте по другим причинам.

В более крупных проектах необходимо учесть загрузку персонала центрального подразделения и обеспечить дополнительные ресурсы (предпочтительно за счет командирования сотрудников из других подразделений частей организации, например, из Службы Service Desk) или финансирование для выполнения работ по Управлению релизами, Управлению изменениями и Управлению конфигурациями.

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

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

Обучение.

Персонал Управления релизами должен пройти обучение по теории и практике Управления изменениями и Управления конфигурациями, по разработке и сопровождению ПО, а также по использованию средств поддержки и вспомогательных программ. Кроме этого необходимо более полное ознакомление с ИТ-инфраструктурой и предоставляемыми ею услугами вместе с пониманием вопросов, связанных с бизнесом организации.

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

Может потребоваться дополнительное обучение обслуживающего персонала, который предоставляет услуги для бизнеса, и бизнес-Пользователей, которые нуждаются в «новых услугах» для удовлетворения своих бизнес-нужд.