9.9.2 Средства Управления конфигурациями.
УЭ аппаратного и программного обеспечения должны записываться в CMDB и, в идеале, их статус должен обновляться по мере продвижения работ по Релизу. Для этого необходима возможность хранить предлагаемые Изменения в CMDB и вызывать обновление этих записей из системы Управления изменениями.
9.9.3 Средства Управления конфигурациями ПО (SCM-средства).
Существует множество программных средств для управления версиями программного кода во время разработки (средства Software Configuration Management или SCM-средства). Особую ценность представляет способность SCM-средств управлять связями. Это позволяет оценить влияние Изменения в каком-либо УЭ на другие части системы и, следовательно, определить, какие действия требуются для завершения Изменения, а также спланировать соответствующее тестирование.
Управление релизами получает значительные преимущества благодаря использованию таких SCM-средств, которые могут обрабатывать пакеты Изменений, связанные с исходными запросами на Изменение. Это также подразумевает использование SCM-средств для интеграции с информацией о Проблеме и запросами на Изменение, обычно содержащимися в средствах Service Desk.
Полноценный процесс Управления релизами требует наличия автоматической сборки новых Релизов программных приложений. Это основано на возможности компилирования программ и установления связей в правильной последовательности под программным контролем и с использованием правильных версий исходного кода, которые хранятся в SCM-средстве.
Этот процесс (см. Рисунок 9.7) также требует использования информации о перекрестных ссылках, хранимых в средстве Управления конфигурацией ПО, чтобы определить, для каких «родительских» объектов необходимо провести повторную сборку при изменении единиц более низкого уровня. Например, если заголовок или «включаемый» файл изменяется, то необходимо определить все исходные модули, которые требуется перекомпилировать. Аналогично, следует определить названия программ, для которых требуется восстановить связи, на основании списка перекомпилированных модулей.
Рисунок 9.7 - Пример диаграммы иерархии модулей для программы PRG1.
Некоторые более продвинутые средства Управления конфигурациями также включают компоненты для сборки, чтобы содействовать этому процессу и исключить необходимость вручную записывать информацию о зависимостях. Если не существует уже разработанных фирменных программных средств, часто бывает рационально писать скрипты для простых процедур сборки с использованием командных языков. Однако, это не всегда просто сделать без помощи специалистов, поскольку точная сборка требует понимания зависимостей между изменяемыми УЭ, и поэтому вам, возможно, придется ограничиться только регенерацией всей системы. Специальные средства оптимизируют процесс сборки так, что повторная сборка проводится только для компонентов, задействованных в Изменении. Они также обеспечивают использование правильной версии исходного кода.
Для завершения задачи (см. Рисунок 9.8) автоматический процесс сборки должен сохранить созданные исполняемые файлы в DSL и, соответственно, обновить.
CMDB. Некоторые SCM-средства улучшают эти действия, сохраняя «следы», содержащие используемую версию исходного кода и информацию о компиляции в уже созданных исполняемых файлах. Исходная версия всех приложений и модулей собственной разработки должна храниться в DSL вместе со всем другим системным ПО, которое требуется для генерации и запуска исполняемых версий файлов, таким как компиляторы и операционные системы.
Рисунок 9.8 - Процесс сборки ПО.
9.9.5 Электронное распространение ПО.
Многие организации располагают большим количеством рабочих станций и серверов в среде эксплуатации, которые требуют введения Изменений в ПО в состав Релиза. Более того, это может потребовать скоординированного обновления ПО на нескольких платформах. Процесс распространения ПО не всегда проходит плавно независимо от того, автоматизирован он или нет - иногда происходят сбои. Соответственно, важно иметь возможность записывать ход действий по распространению и отдельные сбои (например, вследствие ошибки, на нескольких рабочих станциях не установлено временное решение). Может понадобиться настоять на откате всего Релиза, если успешно прошла только его часть.
Сегодня становится все более трудно достичь надежности и продуктивности распространения ПО, используя процессы, выполняемые вручную, и поэтому в продаже имеется множество средств по распространению ПО, которые могут помочь в выполнении этих задач. Они варьируются от простых утилит переноса файлов до модулей больших наборов программ системного управления. Тем не менее, введение подобных средств должно быть тщательно оценено, поскольку многие из них сложны в использовании и часто предъявляют все более высокие требования к пропускной способности сети - что часто требует дополнительных затрат.
Для обеспечения возможности автоматической инсталляции приложений требуется понимание того, как это можно сделать вручную, и общего понимания того, как ПО инсталлируется и конфигурируется на целевой платформе. Многие приложения содержат свои программы инсталляции, а иногда создание скрипта для автоматического запуска этих программ - простая задача. Тем не менее, этого не всегда достаточно, и требуются дополнительные Изменения. Иногда требуются специальные утилиты, чтобы точно определить, какие файлы были изменены инсталляционными программами. Это делается путем сканирования.
содержимого этих файлов до и после инсталляции. Такое сканирование бывает особенно необходимым на рабочих станциях.
Функциональность, желательная (см. Рисунок 9.9~) в средствах электронного распространения ПО, включает следующее:.
■ Гарантированная доставка программных файлов. Хорошие системы включают проверку целостности отправленных данных и возможность возобновления прерванной передачи данных, начиная с точки отказа.
■ Различные варианты доставки для оптимизации пропускной способности сети. В некоторых случаях программные файлы можно получить на компакт-диске. Все необходимые пакеты программ отправляются по почте с уведомлением. Другой подход - подход «разветвления», который задействует промежуточные серверы в удаленных офисах для помощи в распространении.
■ Способность хранить новые версии приложений в состоянии ожидания. Это требуется для возможности очень быстрой активации или деактивации после запуска Релиза.
Рисунок 9.9 - Функциональность электронного распространения ПО.
9.9.6 Средства проведения аудита программного и аппаратного обеспечения.
Для проведения успешных Релизов важно быть уверенным в целевой платформе. Помочь в этом может использование средств автоматизации для проведения аудита аппаратного и программного обеспечения. Такие средства могут точно определить, какое ПО инсталлировано, и выявить наиболее критические моменты в конфигурации АО.
Использование таких средств позволяет проверить наличие достаточного места на диске или других условий для среды эксплуатации незадолго до распространения Релиза и, тем самымполучить время для исправления ситуации. Как следствие, количество отказов во время развертывания Релизов должно уменьшиться.
9.9.7 Средства управления рабочими станциями.
Можно ограничить изменения, которые отдельные Пользователи могут проводить на рабочих станциях, благодаря чему целевая среда для новых Релизов станет намного более надежной. Иногда это может быть достигнуто с помощью правильного конфигурирования параметров операционной системы, а иногда может потребоваться дополнительное ПО для усиления контроля.
Независимо от того, используются средства электронного распространения ПО или нет, полезно сохранять стандартную сборку рабочих станций на сервере както автоматизировать проведение инсталляций. Существует ряд языков для написания скриптов, которые могут помочь в этом. Также можно использовать специализированные продукты для инсталляции ПО.
В зоне ответственности Управления релизами находится внедрение процедур, чтобы обеспечить хранение всех инсталляционных файлов на сервере и обновление этих файлов по мере добавления в DSL новых Релизов.
9.9.8 Средства управления серверами.
Удаленный контроль и средства удаленной диагностики для серверов, находящихся в эксплуатации, могут помочь в определении сбоев и их разрешении во время и после развертывания Релизов. Типичные средства включают следующее:.
■ удаленный контроль операций на сервере. Например, для помощи в проведении Изменений на сервере как части развертывания Релиза;.
■ удаленный мониторинг журнала регистрации событий и различных журналов регистрации Проблем на сервере;.
■ мониторинг использования ресурсов процессора, памяти и дискового пространства;.
■ управление дисковым пространством на серверах. Например, для мониторинга загрузки, реорганизации файлов для улучшения производительности и для выделения большего места на диске для приложений.