Biblioteca multimedia definitiva

Una biblioteca de medios definitiva es un repositorio de tecnología de la información seguro en el que se almacenan y protegen las versiones definitivas y autorizadas de los medios de software de una organización. Antes de que una organización publique cualquier software de aplicación nuevo o modificado en su entorno operativo, dicho software debe someterse a pruebas exhaustivas y a un control de calidad. La biblioteca de medios definitiva proporciona el área de almacenamiento para los objetos de software listos para su implementación y solo debe contener copias maestras de los elementos de configuración (CI) de los medios de software controlados que hayan superado las comprobaciones de control de calidad adecuadas , incluyendo normalmente tanto el código fuente de la aplicación adquirida como el de la versión dorada, así como los ejecutables . En el contexto del marco de mejores prácticas de ITIL ^{[ 1 ]} , el término biblioteca de medios definitiva sustituye al término biblioteca de software definitiva al que se hacía referencia antes de la versión ITIL v3.

En conjunto con la base de datos de gestión de configuración (CMDB), proporciona de manera efectiva el ADN del centro de datos, es decir, todos los medios de software de aplicación y compilación conectados al registro de instalación y configuración de la CMDB.

La biblioteca multimedia definitiva es un componente fundamental del marco de lanzamiento y aprovisionamiento de una organización, así como del plan de continuidad del servicio.

En un entorno de TI controlado , es crucial que solo se permitan versiones autorizadas del software en producción. Las consecuencias de que versiones no autorizadas lleguen al entorno en producción pueden ser graves. Normalmente, en una organización madura, existen procesos rigurosos de gestión de cambios y versiones para evitar que esto ocurra, pero dichos procesos requieren un lugar donde las versiones autorizadas del software puedan almacenarse y accederse de forma segura. La solución propuesta por ITIL en su tercera versión se denomina biblioteca de medios definitiva o DML (que sustituye a la anterior Biblioteca de Software Definitiva o DSL de la versión dos). ITIL propone que la DML puede ser un repositorio físico o virtual, y ambos métodos presentan ventajas e inconvenientes. Sin embargo, es evidente que existen factores clave para el éxito de cualquier solución DML: el software que se despliega en producción debe estar rigurosamente probado, garantizado y licenciado para su correcto funcionamiento, además de estar empaquetado de forma que su despliegue sea seguro y consistente. Asimismo, la DML debe ser fácilmente accesible únicamente para las personas autorizadas. De esta forma, un área de almacenamiento virtual (electrónico) casi siempre proporcionará una solución superior, lo que significa que el DML se puede centralizar y acceder a él de forma remota o fuera del horario laboral habitual si surge la necesidad (véase distribución).

El DML desempeña un papel fundamental en el apoyo a la transición de las fases de desarrollo a producción, y las soluciones DML deben distinguirse de otros repositorios de software y código fuente, como la gestión de configuración de software o SCM (a veces denominada gestión de cambios y configuración de software), que apoya la fase de desarrollo o evolución del software. Esta es una distinción importante que a menudo causa cierta confusión. En esencia, mientras que las herramientas o repositorios SCM almacenan y gestionan todas las versiones y revisiones de desarrollo del código (o productos de trabajo ) hasta el producto final autorizado, pero sin incluirlo, el DML almacena solo las versiones finales autorizadas del código o producto. Esto es análogo al ciclo de vida de un producto comercial, donde el producto pasa de la casa de diseño a la fábrica , luego al almacén y finalmente a la tienda .

• Se conservan registros ( metadatos ) sobre cómo se diseña, desarrolla y fabrica un producto. Esto permite identificar el proceso responsable cuando se detectan productos defectuosos, ya sea durante el control de calidad o incluso durante su uso posterior.
• records (metadata) are kept in a configuration management database about where the software is installed and deployed from the DML and into the production environment. Each installation or deployment should be authorised by a corresponding production change request and the resulting change recorded in the configuration management database as a relationship between the DML artefact and the platform where it has been deployed.

In a more mature or evolved state there is no distinction drawn between the two forms of configuration management and the process is continuous supporting the whole service delivery and service operation lifecycle. This has been referred to as Enterprise Configuration Management. Even here though the development-based artefacts should still be distinguished from and kept separate from the management of quality-assured, definitive master versions available for deployment. In an outsourced or multi-vendor arrangement the existence or otherwise of a consistent and secure form of supplier access will dictate whether or not the software configuration management is performed passively (externally by suppliers adopting their own SCM tools and then delivering the finished product) or actively (overseen internally with suppliers utilising the centrally hosted SCM tool). All finished products, however, (application software) in their authorised deployable form should be stored within the central DML.

Typical CIs that a DML will store include:

• Packaged in-house application software
• Commercial off-the-shelf (COTS) raw media
• Customised COTS software (containing enhancements, tailored configuration etc)
• Release packages
• Patches (see patch (computing))
• Gold builds (clients, servers, network and storage devices etc)
• System images
• Across multiple technology stacks and distribution technologies (e.g. Wintel, UNIX, ORACLE, mainframe, network, storage etc)

(see "definitive media library and configuration management database in the context of the release management process" diagram above)

The media release lifecycle steps are:

1. Demand for new service or product arises.
2. Decision is made to make or buy the product (service, build or application) based on functional requirements extracted from the requirements traceability tool. Product is created or selected from the service/ product catalogue in accordance with architectural design policies (Service Design). COTS product is procured and stored in the DML with asset status ‘procured’. If new, the product is added to the Approved Products Catalogue. In-house created application source code is managed directly in the software configuration management repository.
3. If COTS product or gold build is being packaged, media is extracted from the DML.
4. El producto se empaqueta o se desarrolla y empaqueta (en cuyo caso la funcionalidad adicional se trata de la misma manera que las aplicaciones y compilaciones internas).
5. Los registros provisionales o las líneas base originales se crean en la herramienta de gestión de configuración del software.
6. Las revisiones del código de desarrollo y las revisiones de los paquetes se registran en la herramienta de gestión de la configuración del software durante todo el proceso de desarrollo.
7. Se realizan pruebas unitarias.
8. El empaquetado se ha completado para crear el paquete de lanzamiento.
9. El embalaje del producto cuenta con garantía de calidad (incluidas las pruebas, la preparación y cualquier reelaboración).
10. El paquete de medios completado (compilación, servicio o aplicación) se vuelve a depositar en el DML como medio autorizado listo para su implementación.
11. Tras la aprobación de la gestión de cambios, el producto se distribuye a la infraestructura a través del sistema de distribución adecuado y las instalaciones lógicas se registran mediante el procedimiento establecido en el CMS (CMDB).
12. Las entidades DML se archivan tan pronto como:
    1. CMS o CMDB indica que la versión empaquetada ya no se utiliza en ninguna ubicación (se requiere un período de gracia después de la última desactivación o actualización para permitir cualquier regresión necesaria) y
    2. La entidad DML se ha eliminado del catálogo técnico o de usuario (servicio) como elemento seleccionable.

Si bien la Biblioteca de Medios Digitales (DML) como repositorio autorizado de contenido multimedia implica cierto grado de centralización, se requerirán Bibliotecas de Medios Locales (LML) para lograr un modelo global. De esta manera, la publicación y el despliegue de copias físicas de contenido multimedia se podrán realizar en cada país de forma oportuna, evitando descargas constantes a través de la red global. La replicación de contenido multimedia autorizado en ventanas secundarias permitiría disponer de los paquetes necesarios localmente, pero la DML seguiría siendo la biblioteca principal por motivos de control de procesos.

La jerarquía DML/LML es sinónimo de las capas de distribución maestra/secundaria presentes en muchas tecnologías de distribución y sistemas de gestión de paquetes. Sin embargo, mientras que las herramientas de distribución suelen estar sesgadas hacia una pila tecnológica específica (por ejemplo, Wintel, Unix, Mainframe, etc.), una de las principales ventajas de una DML es su naturaleza tecnológicamente independiente y su función como repositorio central para todo el software autorizado. De esta forma, las herramientas de distribución se conectan a la DML para obtener el paquete de software. El empaquetado de aplicaciones implica la preparación de instalaciones de software estándar y estructuradas, destinadas a la implementación automatizada. El empaquetado también es necesario para el software comercial (COTS), ya que permite configurarlo para que se ejecute de forma eficiente en una plataforma o entorno específico. Incluso un ligero cambio en esta plataforma (como el cambio de disco) puede impedir la correcta implementación de un paquete, por lo que la conservación de la versión en formato ISO del software es fundamental, ya que será necesaria (a menudo en caso de emergencia) si la versión empaquetada deja de funcionar, por ejemplo, tras la actualización o sustitución de la plataforma operativa.

El DML admite:

• Gestión de lanzamientos y despliegues como base y área de almacenamiento central para todos los paquetes de despliegue que se pueden publicar.
• Disponibilidad y continuidad del servicio al proporcionar la fuente de todas las aplicaciones empaquetadas y los soportes originales para su uso en procedimientos de restauración del servicio y recuperación ante desastres.
• Aprovisionamiento y racionalización automatizados de servidores mediante el almacenamiento de versiones de referencia.
• La gestión de activos se realiza proporcionando registros de metadatos y claves de licencia relacionadas con el suministro de licencias de software comercial estándar (COTS). Las instancias de soportes y el conjunto de soportes autorizados, almacenados junto con las licencias y sus condiciones, permitirán una gestión optimizada de las asignaciones de software y el cumplimiento externo de las recomendaciones de la Ley Sarbanes-Oxley y la Ley de Normas Comerciales (BSA).
• Cumplimiento de solicitudes catalogadas, ya sea en términos de solicitudes de productos para clientes de un solo usuario o solicitudes repetidas para implementaciones de un servicio/aplicación multiusuario existente en otras ubicaciones de alojamiento.

• Gestión del ciclo de vida de las aplicaciones
• gestión del ciclo de vida del producto
• Gestión del ciclo de vida del software
• Gestión de sistemas
• Implementación del sistema
• Lanzamiento de software
• Implementación de software
• Repositorio de software

• http://wiki.en.it-processmaps.com/index.php/ITIL_Glossary
• http://www.itsmwatch.com/itil/article.php/3887361/How-to-Set-Up-and-Manage-a-Definitive-Media-Library.htm Archivado el 17/12/2011 en Wayback Machine
• http://www.ibm.com/developerworks/rational/library/edge/09/mar09/rader/