Полная медиа-библиотека - Definitive Media Library

Полная медиа-библиотека и CMDB в контексте процесса управления релизами

А Полная медиа-библиотека это безопасный Информационные технологии репозиторий, в котором хранятся и защищаются окончательные авторизованные версии носителей программного обеспечения. Прежде чем организация выпустит какое-либо новое или измененное прикладное программное обеспечение в свою операционную среду, любое такое программное обеспечение должно быть полностью протестировано и обеспечено качество. Стандартная библиотека мультимедиа предоставляет область хранения для программных объектов, готовых к развертыванию, и должна содержать только основные копии контролируемых носителей программного обеспечения. элементы конфигурации (CI), прошедшие соответствующий гарантия качества чеки, обычно включающие как закупленные, так и сделанный на заказ приложение и сборка золота исходный код и исполняемые файлы. В контексте ITIL^[1] рамки передовой практики, термин Definitive Media Library заменяет термин полная библиотека программного обеспечения упоминается до версии ITIL v3.

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

Стандартная медиабиблиотека (DML) - это основной компонент структуры выпуска и предоставления услуг, а также плана непрерывности обслуживания.

Фон

В контролируемой ЭТО среды очень важно, чтобы в производство допускались только авторизованные версии программного обеспечения. Последствия попадания неавторизованных версий программного обеспечения в рабочую среду могут быть серьезными. Как правило, в зрелой организации существуют строгие процессы управления изменениями и выпусками для предотвращения этого, но такие процессы требуют места, где разрешенные версии программного обеспечения могут быть безопасно сохранены и доступны. Решение, предложенное ITIL в его третьей версии, называется Definitive Media Library или DML (заменяет ранее названную Definitive Software Library или DSL во второй версии). ITIL предлагает, чтобы DML мог быть как физическим, так и виртуальным хранилищем, и у любого метода есть свои преимущества и недостатки. Однако очевидно, что существуют ключевые факторы успеха любого решения DML, то есть программное обеспечение, необходимое для развертывания в производственной среде, должно быть тщательно протестировано, гарантировано и лицензировано для работы, а также упаковано таким образом, чтобы его можно было безопасно и последовательно развертывать. Кроме того, DML должен быть легко доступен для тех и только тех, кому это разрешено. Таким образом, виртуальная (электронная) область хранения почти всегда будет лучшим решением, то есть DML может быть централизован и доступен удаленно или в нерабочее время, если возникнет необходимость (см. Распределение).

Объем

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

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

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

Типичные CI, которые будет хранить DML, включают:

Пакетное прикладное программное обеспечение собственного производства
Коммерческая готовая продукция (COTS) необработанные медиа
Специальное программное обеспечение COTS (содержащее улучшения, индивидуальную конфигурацию и т. Д.)
Пакеты выпуска
Патчи (см. патч (вычисления) )
Золотые сборки (клиенты, серверы, сетевые устройства, устройства хранения и т. Д.)
Системные образы
Через несколько технологических стеков и технологий распространения (например, Wintel, UNIX, ORACLE, мэйнфреймы, сеть, хранилище и т. Д.)

Жизненный цикл выпуска СМИ

(см. диаграмму «Полная медиа-библиотека и CMDB в контексте процесса управления релизами» выше)

Шаги жизненного цикла медиа-релиза:

Возникает спрос на новую услугу или продукт.
Решение о производстве или покупке продукта (услуги, сборки или приложения) принимается на основе функциональных требований, извлеченных из инструмента отслеживания требований. Продукт создается или выбирается из каталога услуг / продуктов в соответствии с политиками архитектурного проектирования (Сервисный дизайн). Продукт COTS закупается и хранится в DML со статусом актива «закуплено». Если новый, продукт добавляется в каталог одобренных продуктов. Исходный код приложения, созданный внутри компании, управляется непосредственно в репозитории управления конфигурацией программного обеспечения.
Если продукт COTS или сборка золота упаковываются, носитель извлекается из DML.
Продукт упаковывается или разрабатывается и упаковывается (в этом случае дополнительные функции обрабатываются так же, как внутренние приложения и сборки).
В средстве управления конфигурацией программного обеспечения создаются промежуточные записи или исходные базовые планы.
Изменения кода разработки и версии пакетов записываются в средстве управления конфигурацией программного обеспечения на протяжении всей разработки.
Проводится модульное тестирование.
Завершена упаковка для создания релиз-пакета.
Гарантия качества на упаковку (включая тестирование, постановку и любые доработки).
Завершенный медиа-пакет (сборка, услуга или приложение) возвращается в DML как авторизованный носитель, готовый к развертыванию.
После утверждения Управления изменениями продукт передается в собственность через соответствующую систему распространения, а логические установки записываются в CMS (CMDB) с помощью надлежащей процедуры.
Сущности DML архивируются, как только:
1. CMS или CMDB указывает, что упакованный выпуск больше не используется в любом месте (требуется льготный период после последнего списания или обновления, чтобы учесть любые необходимые регрессии) и
2. Сущность DML была удалена из технического или пользовательского (сервисного) каталога как доступный для выбора элемент.

Распределение

Несмотря на то, что DML в качестве авторизованного хранилища мультимедиа предполагает определенную степень централизации, для создания глобальной модели потребуются локальные библиотеки мультимедиа (LML). Таким образом, выпуск и развертывание физических экземпляров носителей может быть достигнуто в стране своевременно, избегая постоянных загрузок по глобальной сети. Репликация авторизованных носителей в неосновных окнах сделает необходимые пакеты доступными локально по мере необходимости, но DML останется «главным» по причинам контроля процесса. Иерархия DML / LML является синонимом основного / вторичного уровней распространения, наблюдаемого во многих технологиях распространения и системах управления пакетами. Однако, в то время как инструменты распространения склонны ориентироваться на определенный технологический стек (например, Wintel, Unix, Mainframe и т. Д.), Одним из основных преимуществ DML является его технологически независимый характер и истинное центральное хранилище для всего авторизованного программного обеспечения. Таким образом, инструменты распространения будут подключаться к DML для получения пакета программного обеспечения. Пакетирование приложений включает в себя подготовку стандартных структурированных установок программного обеспечения, предназначенных для автоматического развертывания. Упаковка также требуется для покупного программного обеспечения (COTS), поскольку упаковка позволяет настроить программное обеспечение для эффективной работы на конкретной платформе или среде. Даже небольшое изменение в этой платформе (например, замена диска) может помешать успешному развертыванию пакета, поэтому сохранение версии программного обеспечения на необработанном носителе (ISO) имеет решающее значение, поскольку это будет необходимо (часто в экстренных случаях). упакованная версия больше не развертывается, например после обновления или замены операционной платформы.

Преимущества

DML поддерживает;

Управление выпуском и развертыванием как основа и центральная область хранения для всех выпускаемых пакетов развертывания
Доступность и непрерывность обслуживания за счет предоставления источника всех упакованных приложений и необработанных носителей для использования в процедурах восстановления службы и аварийного восстановления
Автоматизированная подготовка и рационализация серверов за счет хранения золотых сборок
Управление активами путем предоставления записей метаданных и лицензионных ключей, связанных с предоставлением лицензий на программное обеспечение COTS. Экземпляры носителей и авторизованный набор носителей, хранящиеся вместе с лицензиями и условиями лицензий, позволят оптимизировать управление распределением программного обеспечения и внешним соответствием с точки зрения рекомендаций Sarbane-Oxley и BSA.
Выполнение каталогизированных запросов, будь то однопользовательские запросы продукта на стороне клиента или повторяющиеся запросы на развертывание существующей многопользовательской службы / приложения в других местах размещения.

Смотрите также

внешняя ссылка

[1] Ширли Лейси и Айвор Макфарлейн (2007). Переход на услуги ITIL. Канцелярия. ISBN 978-0-11-331048-7.

[1]