Jump to content

Definitive media library: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
mNo edit summary
Line 9: Line 9:
The Definitive Media Library ([[DML]]) is a primary component of an organisation's release and provisioning framework and service continuity plan.
The Definitive Media Library ([[DML]]) is a primary component of an organisation's release and provisioning framework and service continuity plan.
== Background ==
== Background ==
In a controlled IT environment it is crucial that only authorised versions of software are allowed into production. The consequences of unauthorised software versions finding their way into the live environment can be serious. Typically, in a mature organisation, stringent Change and Release Management processes will exist to prevent this occurring, but such processes require a place where the authorised software versions can be safely stored and accessed. The solution put forward by ITIL in its third version is called the Definitive Media Library or DML (replacing the previously named Definitive Software Library or DSL in version two). ITIL proposes that the DML can be either a physical or virtual store and there are benefits and drawbacks with either method (see instantiation). Clearly, however, there are key factors in the success of any DML solution i.e. software required to be deployed into production should be rigorously tested, assured and licensed to perform and also packaged in such a way that it will safely and consistently deploy. Also, the DML should be easily accessed by those, and only those, authorised to do so.
In a controlled [IT] environment it is crucial that only authorised versions of software are allowed into production. The consequences of unauthorised software versions finding their way into the live environment can be serious. Typically, in a mature organisation, stringent Change and Release Management processes will exist to prevent this occurring, but such processes require a place where the authorised software versions can be safely stored and accessed. The solution put forward by ITIL in its third version is called the Definitive Media Library or DML (replacing the previously named Definitive Software Library or DSL in version two). ITIL proposes that the DML can be either a physical or virtual store and there are benefits and drawbacks with either method (see instantiation). Clearly, however, there are key factors in the success of any DML solution i.e. software required to be deployed into production should be rigorously tested, assured and licensed to perform and also packaged in such a way that it will safely and consistently deploy. Also, the DML should be easily accessed by those, and only those, authorised to do so.
== Scope ==
The DML plays a critical role in supporting the transition from development to production phases and DML solutions should be distinguished from other software and source code repositories e.g. Software Configuration Management or SCM (sometimes referred to as Software Change and Configuration Management) that supports the development or software evolution phase. This is an important distinction and often causes some confusion. In essence, whereas SCM tools or repositories store and manage all development versions and revisions of code (or work products) up to but not including the final authorised product, the DML stores only the final authorised versions of the code or product. This is analogous to a high-street product lifecycle where the product moves from design-house to factory, through to warehouse and then shop, i.e.
• records (metadata) are kept about how a product is designed developed and built. This enables the tracking down of which process is to blame where faulty products are discovered either during quality control or even in later service.
• records (metadata) are kept in a CMDB 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 CMDB 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) or actively (overseen internally with suppliers utilising the central SCM tool). All finished products, however, (application software) in its 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
• 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)


==References==
==References==

Revision as of 21:39, 15 May 2012

The Definitive Media Library & CMDB in the context of the Release Management Process

A Definitive Media Library is a secure Information Technology repository in which an organisation's definitive, authorised versions of software media are stored and protected. Before an organisation releases any new or changed application software into its operational environment, any such software should be fully tested and quality assured. The Definitive Media Library provides the storage area for software objects ready for deployment and should only contain master copies of controlled software media Configuration Items (CIs) that have passed appropriate quality assurance checks, typically including both procured and bespoke application and gold build source code and executables. In the context of the ITIL [1] best practice framework, the term Definitive Media Library supersedes the term Definitive Software Library referred to prior to version ITIL v3.

In conjunction with the Configuration Management Database (CMDB), it effectively provides the DNA of the data center i.e. all application and build software media connected to the CMDB record of installation and configuration.

The Definitive Media Library (DML) is a primary component of an organisation's release and provisioning framework and service continuity plan.

Background

In a controlled [IT] environment it is crucial that only authorised versions of software are allowed into production. The consequences of unauthorised software versions finding their way into the live environment can be serious. Typically, in a mature organisation, stringent Change and Release Management processes will exist to prevent this occurring, but such processes require a place where the authorised software versions can be safely stored and accessed. The solution put forward by ITIL in its third version is called the Definitive Media Library or DML (replacing the previously named Definitive Software Library or DSL in version two). ITIL proposes that the DML can be either a physical or virtual store and there are benefits and drawbacks with either method (see instantiation). Clearly, however, there are key factors in the success of any DML solution i.e. software required to be deployed into production should be rigorously tested, assured and licensed to perform and also packaged in such a way that it will safely and consistently deploy. Also, the DML should be easily accessed by those, and only those, authorised to do so.

Scope

The DML plays a critical role in supporting the transition from development to production phases and DML solutions should be distinguished from other software and source code repositories e.g. Software Configuration Management or SCM (sometimes referred to as Software Change and Configuration Management) that supports the development or software evolution phase. This is an important distinction and often causes some confusion. In essence, whereas SCM tools or repositories store and manage all development versions and revisions of code (or work products) up to but not including the final authorised product, the DML stores only the final authorised versions of the code or product. This is analogous to a high-street product lifecycle where the product moves from design-house to factory, through to warehouse and then shop, i.e. • records (metadata) are kept about how a product is designed developed and built. This enables the tracking down of which process is to blame where faulty products are discovered either during quality control or even in later service. • records (metadata) are kept in a CMDB 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 CMDB 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) or actively (overseen internally with suppliers utilising the central SCM tool). All finished products, however, (application software) in its 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 • 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)

References

  1. ^ Shirley Lacy and Ivor Macfarlane (2007). ITIL Service Transition. The Stationery Office. ISBN 978-0-11-331048-7.

External links

Retrieved from "https://en.wikipedia.org/w/index.php?title=Definitive_media_library&oldid=492765943"