최종 미디어 라이브러리

Definitive media library
릴리스 관리 프로세스의 맥락에서 정의 미디어 라이브러리 및 CMDB

최종 미디어 라이브러리는 조직의 승인된 최종 버전의 소프트웨어 미디어가 저장 및 보호되는 안전한 정보 기술 저장소입니다.조직이 운영 환경에 새 애플리케이션 소프트웨어나 변경된 애플리케이션 소프트웨어를 배포하기 전에 이러한 소프트웨어를 완전히 테스트하고 품질을 보장해야 합니다.Definitional Media Library는 배포 준비가 된 소프트웨어 개체에 대한 저장 영역을 제공하며, 일반적으로 조달된 애플리케이션과 맞춤형 애플리케이션, 골드 빌드 소스 코드 및 실행 파일을 모두 포함하여 적절한 품질 보증 검사를 통과한 제어된 소프트웨어 미디어 구성 항목(CI)의 마스터 복사본만 포함해야 합니다.ITIL[1] 모범 사례 프레임워크의 맥락에서 정의 미디어 라이브러리라는 용어는 버전 ITIL v3 이전에 언급된 정의 소프트웨어 라이브러리라는 용어를 대체합니다.

CMDB(Configuration Management Database)와 함께 CMDB 설치 및 구성 레코드에 연결된 모든 응용 프로그램 및 빌드 소프트웨어 미디어와 같은 데이터 센터의 DNA를 효과적으로 제공합니다.

최종 미디어 라이브러리는 조직의 릴리스 및 프로비저닝 프레임워크와 서비스 연속성 계획의 주요 구성 요소입니다.

배경

통제된 IT 환경에서는 승인된 버전의 소프트웨어만 프로덕션에 허용되는 것이 중요합니다.승인되지 않은 소프트웨어 버전이 실제 환경으로 유입되는 결과는 심각할 수 있습니다.일반적으로 성숙한 조직에서는 이러한 현상을 방지하기 위해 엄격한 변경 및 릴리스 관리 프로세스가 존재하지만, 이러한 프로세스에는 공인된 소프트웨어 버전을 안전하게 저장하고 액세스할 수 있는 장소가 필요합니다.ITIL이 세 번째 버전에서 제시한 솔루션은 DML(이전에 이름이 붙은 Dinfinal Software Library 또는 DSL을 버전 2에서 대체함)이라고 합니다.ITIL은 DML이 물리적 저장소 또는 가상 저장소일 수 있다고 제안하며, 두 가지 방법 중 하나에는 장점과 단점이 있습니다.그러나 DML 솔루션의 성공에는 핵심 요소가 분명히 있습니다. 즉, 프로덕션에 배포해야 하는 소프트웨어는 엄격하게 테스트, 보장 및 라이센스를 받아야 하며 안전하고 일관성 있게 배포할 수 있는 방식으로 패키지화해야 합니다.또한 DML은 권한이 있는 사용자만 쉽게 액세스할 수 있어야 합니다.이러한 방식으로 가상(전자) 스토리지 영역은 거의 항상 우수한 솔루션을 제공합니다. 즉, 필요한 경우 DML을 원격으로 중앙 집중화하여 정상 업무 시간 외에 액세스할 수 있습니다(배포 참조).

범위

DML은 개발 단계에서 생산 단계로의 전환을 지원하는 데 중요한 역할을 하며, DML 솔루션은 다른 소프트웨어 및 소스 코드 저장소와 구별되어야 합니다.소프트웨어 구성 관리 또는 SCM(소프트웨어 변경 및 구성 관리라고도 함)은 개발 또는 소프트웨어 진화 단계를 지원합니다.이것은 중요한 구별이며 종종 약간의 혼란을 야기합니다.본질적으로 SCM 도구 또는 리포지토리는 최종 승인된 제품을 포함하지 않고 코드(또는 작업 제품)의 모든 개발 버전 및 개정판을 저장하고 관리하는 반면, DML은 코드 또는 제품의 최종 승인된 버전만 저장합니다.이는 제품이 디자인 하우스에서 공장으로, 창고에서 창고로, 그리고 쇼핑으로 이동하는 번화가의 제품 라이프사이클과 유사합니다.

  • 제품이 어떻게 개발되고 제조되는지에 대한 기록(문서)이 보관됩니다.이를 통해 품질 관리 중 또는 이후 서비스에서 결함이 발견된 제품의 원인이 되는 프로세스를 추적할 수 있습니다.
  • 레코드(메타데이터)는 DML에서 운영 환경으로 소프트웨어가 설치되고 배포되는 위치에 대한 구성 관리 데이터베이스에 보관됩니다.각 설치 또는 배치는 해당하는 생산 변경 요청과 구성 관리 데이터베이스에 DML 아티팩트와 배치된 플랫폼 간의 관계로 기록된 결과 변경에 의해 승인되어야 합니다.

보다 성숙하거나 진화된 상태에서는 두 가지 구성 관리 형태가 구분되지 않으며 프로세스는 전체 서비스 제공 및 서비스 운영 라이프사이클을 지속적으로 지원합니다.이를 엔터프라이즈 구성 관리라고 합니다.여기서도 개발 기반 제품은 품질 보증 관리와 구별되어야 하며 배포 가능한 최종 마스터 버전과 분리되어 유지되어야 합니다.아웃소싱 또는 멀티벤더 방식에서 일관되고 안전한 형태의 공급업체 액세스가 존재하는지 여부는 소프트웨어 구성 관리가 수동적으로 수행되는지(외부적으로 공급업체가 자체 SCM 도구를 채택한 다음 완제품을 제공하는지) 또는 능동적으로 수행되는지(내부적으로 su로 감독됨)를 결정합니다.중앙에서 호스팅되는 SCM 툴을 활용하는 플라이어).그러나 모든 완제품(애플리케이션 소프트웨어)은 배포가 허가된 형태로 중앙 DML에 저장해야 합니다.

DML이 저장할 일반적인 CI는 다음과 같습니다.

  • 패키지화된 사내 애플리케이션 소프트웨어
  • 상용 기성품(COTS) 원시 미디어
  • 맞춤형 COTS 소프트웨어(향상된 기능, 맞춤형 구성 등 포함)
  • 패키지 릴리스
  • 패치(패치(컴퓨팅) 참조)
  • 골드 빌드(클라이언트, 서버, 네트워크 및 스토리지 장치 등)
  • 시스템 이미지
  • 다양한 기술 스택 및 배포 기술(예: Wintel, UNIX, Oracle, 메인프레임, 네트워크, 스토리지 등)

미디어 릴리스 수명 주기

(위의 "릴리스 관리 프로세스의 맥락에서 볼 수 있는 최종 미디어 라이브러리 및 구성 관리 데이터베이스" 다이어그램을 참조하십시오.

미디어 릴리스 수명 주기 단계는 다음과 같습니다.

  1. 새로운 서비스나 제품에 대한 수요가 발생합니다.
  2. 요구사항 추적 도구에서 추출한 기능적 요구사항을 기반으로 제품(서비스, 빌드 또는 애플리케이션)을 만들거나 구입하기로 결정합니다.제품은 아키텍처 설계 정책(서비스 설계)에 따라 서비스/제품 카탈로그에서 생성 또는 선택됩니다.COTS 제품은 자산 상태가 '조달됨'인 상태로 DML에 조달 및 저장됩니다.새 제품인 경우 제품이 승인된 제품 카탈로그에 추가됩니다.사내에서 생성된 애플리케이션 소스 코드는 소프트웨어 구성 관리 저장소에서 직접 관리됩니다.
  3. COTS 제품 또는 골드 빌드가 포장되는 경우 DML에서 미디어가 추출됩니다.
  4. 제품은 패키징 또는 개발 및 패키징됩니다(이 경우 애드온 기능은 사내 애플리케이션 및 빌드와 동일한 방식으로 처리됨).
  5. 스텁 레코드 또는 원본 기준선은 소프트웨어 구성 관리 도구에서 생성됩니다.
  6. 개발 코드 수정사항 및 패키지 수정사항은 개발 전반에 걸쳐 소프트웨어 구성 관리 도구에 기록됩니다.
  7. 유닛 테스트를 수행합니다.
  8. 패키지화가 완료되어 릴리스 패키지가 생성됩니다.
  9. 제품 패키지는 품질이 보장됩니다(테스트, 스테이징 및 모든 재작업 포함).
  10. 완성된 미디어 패키지(빌드, 서비스 또는 애플리케이션)는 승인된 미디어를 배포할 준비가 된 상태로 DML에 다시 보관됩니다.
  11. Change Management 승인 후, 제품은 적절한 분배 시스템을 통해 자산으로 릴리스되며 논리적 설치는 CMS(CMDB)의 적법한 프로세스를 통해 기록됩니다.
  12. DML 엔티티는 다음과 같이 즉시 보관됩니다.
    1. CMS 또는 CMDB는 패키지 릴리스가 어느 위치에서도 더 이상 사용되지 않음을 나타냅니다(필요한 회귀를 허용하려면 마지막 해제 또는 업그레이드 후 유예 기간이 필요함).
    2. DML 엔티티가 선택 가능한 항목으로 기술 또는 사용자(서비스) 카탈로그에서 제거되었습니다.

분배

미디어를 위한 공인 저장소로서의 DML은 어느 정도의 중앙 집중화를 의미하지만, 글로벌 모델을 달성하기 위해서는 로컬 미디어 라이브러리(LML)가 필요합니다.이러한 방식으로 글로벌 네트워크를 통한 지속적인 다운로드를 방지하여 국가에서 물리적 미디어 인스턴스의 릴리스 및 배포를 적시에 수행할 수 있습니다.비주요 창에서 인증된 미디어를 복제하면 필요에 따라 로컬에서 필요한 패키지를 사용할 수 있지만 DML은 프로세스 제어상의 이유로 '마스터' 상태로 유지됩니다.

DML/LML 계층은 많은 배포 기술 및 패키지 관리 시스템에서 볼 수 있는 마스터/2차 배포 계층과 동의어입니다.그러나 배포 도구가 특정 기술 스택(예: Wintel, Unix, 메인프레임 등)에 치우치는 경향이 있는 반면, DML의 주요 이점 중 하나는 기술에 구애받지 않는 특성과 승인된 모든 소프트웨어를 위한 진정한 중앙 저장소입니다.이러한 방식으로 배포 도구는 DML에 연결하여 소프트웨어 패키지를 가져옵니다.애플리케이션 패키징에는 자동화된 배포를 목표로 하는 표준 구조화된 소프트웨어 설치를 준비하는 작업이 포함됩니다.패키지를 사용하면 소프트웨어가 특정 플랫폼 또는 환경에서 효율적으로 실행되도록 구성할 수 있으므로 COTS(구매) 소프트웨어에도 패키지가 필요합니다.이 플랫폼(예: 디스크 스왑 아웃)을 조금만 변경해도 패키지가 성공적으로 배포되지 않을 수 있으므로 패키지 버전이 더 이상 배포되지 않는 경우(종종 비상 시) 필요하기 때문에 소프트웨어의 원시 미디어(ISO) 버전을 유지하는 것이 중요합니다.운영 플랫폼의 업그레이드 또는 교체 후.

혜택들

DML은 다음을 지원합니다.

  • 모든 릴리스 가능한 배포 패키지의 기반 및 중앙 스토리지 영역으로서의 릴리스 및 배포 관리
  • 서비스 복원 및 재해 복구 절차에 사용할 모든 패키지 애플리케이션 및 원시 미디어의 소스를 제공하여 가용성 및 서비스 연속성
  • 골드 빌드 스토리지를 통한 자동화된 서버 프로비저닝 및 합리화
  • COTS 소프트웨어 라이센스 제공과 관련된 메타데이터 레코드 및 라이센스 키를 제공하여 자산을 관리합니다.라이센스 및 라이센스 조건과 함께 저장된 미디어 및 공인 미디어 세트의 인스턴스를 사용하면 Sarbane-Oxley 및 BSA 권장 사항의 측면에서 소프트웨어 할당 및 외부 준수 관리를 최적화할 수 있습니다.
  • 단일 사용자 클라이언트 엔드 제품 요청 또는 기존 다중 사용자 서비스/애플리케이션을 다른 호스팅 위치에 배포하는 반복적인 요청의 측면에서 카탈로그화된 요청 이행.

참고 항목

레퍼런스

  1. ^ 셜리 레이스와 아이보르 맥팔레인(2007).ITIL 서비스 전환.문방구 사무실. ISBN978-0-11-331048-7.

외부 링크