Ostateczna biblioteka multimediów

Definitive Media Library i CMDB w kontekście procesu zarządzania wydaniami

Definitive Media Library to bezpieczne repozytorium technologii informatycznych , w którym przechowywane i chronione są ostateczne, autoryzowane wersje nośników oprogramowania organizacji. Zanim organizacja wypuści jakiekolwiek nowe lub zmienione oprogramowanie do swojego środowiska operacyjnego, każde takie oprogramowanie powinno zostać w pełni przetestowane i zapewnione pod względem jakości. elementów konfiguracji nośników oprogramowania (CI), które przeszły odpowiednie kontrole zapewnienia jakości , zazwyczaj obejmujące zarówno zamówione, jak i wykonane na zamówienie aplikacje oraz kod źródłowy złotej kompilacji i pliki wykonywalne . W kontekście ITIL termin Definitive Media Library zastępuje termin ostatecznej biblioteki oprogramowania , o którym mowa przed wersją ITIL v3.

W połączeniu z bazą danych zarządzania konfiguracją ( CMDB ), skutecznie zapewnia DNA centrum danych , tj. wszystkie nośniki aplikacji i oprogramowania do kompilacji połączone z zapisem instalacji i konfiguracji CMDB.

Ostateczna biblioteka multimediów (DML) jest głównym składnikiem struktury udostępniania i udostępniania oraz planu ciągłości usług w organizacji.

Tło

W kontrolowanym środowisku IT kluczowe znaczenie ma dopuszczanie do produkcji tylko autoryzowanych wersji oprogramowania. Konsekwencje przedostania się nieautoryzowanych wersji oprogramowania do środowiska na żywo mogą być poważne. Zwykle w dojrzałej organizacji istnieją rygorystyczne procesy zarządzania zmianami i wydaniami, aby temu zapobiec, ale takie procesy wymagają miejsca, w którym autoryzowane wersje oprogramowania mogą być bezpiecznie przechowywane i dostępne. Rozwiązanie zaproponowane przez ITIL w trzeciej wersji nosi nazwę Definitive Media Library lub DML (zastępując poprzednio nazwaną Definitive Software Library lub DSL w wersji drugiej). ITIL sugeruje, że DML może być fizycznym lub wirtualnym sklepem, a obie metody mają zalety i wady. Oczywiście istnieją kluczowe czynniki decydujące o powodzeniu każdego rozwiązania DML, tj. oprogramowanie, które ma zostać wdrożone w środowisku produkcyjnym, powinno być rygorystycznie testowane, mieć pewność i uzyskać licencję na działanie, a także być spakowane w taki sposób, aby można go było bezpiecznie i spójnie wdrożyć. Ponadto DML powinien być łatwo dostępny dla tych i tylko tych, którzy są do tego upoważnieni. W ten sposób wirtualny (elektroniczny) obszar przechowywania prawie zawsze zapewnia lepsze rozwiązanie, co oznacza, że ​​DML można scentralizować i uzyskać do niego dostęp zdalny lub poza normalnymi godzinami pracy, jeśli zajdzie taka potrzeba (patrz dystrybucja).

Zakres

DML odgrywa kluczową rolę we wspieraniu przejścia z fazy rozwoju do fazy produkcji, a rozwiązania DML należy odróżnić od innych repozytoriów oprogramowania i kodu źródłowego, np . faza ewolucji oprogramowania. Jest to ważne rozróżnienie i często powoduje pewne zamieszanie. Zasadniczo, podczas gdy narzędzia lub repozytoria SCM przechowują i zarządzają wszystkimi wersjami programistycznymi i poprawkami kodu (lub produktami roboczymi) aż do ostatecznego autoryzowanego produktu, ale z wyłączeniem, DML przechowuje tylko ostateczne autoryzowane wersje kodu lub produktu. cyklu życia produktu z głównych ulic, w którym produkt przemieszcza się od biura projektowego do fabryki , przez magazyn , a następnie do sklepu , tj.

  • zapisy ( metadane ) dotyczące sposobu projektowania, opracowywania i budowy produktu. Umożliwia to wyśledzenie, który proces jest odpowiedzialny za wykrycie wadliwych produktów podczas kontroli jakości lub nawet w późniejszym serwisie.
  • rekordy (metadane) są przechowywane w CMDB o tym, gdzie oprogramowanie jest instalowane i wdrażane z DML do środowiska produkcyjnego. Każda instalacja lub wdrożenie powinno być autoryzowane przez odpowiednie żądanie zmiany produkcyjnej, a wynikająca z tego zmiana powinna zostać zarejestrowana w CMDB jako relacja między artefaktem DML a platformą, na której został wdrożony.

W bardziej dojrzałym lub rozwiniętym stanie nie ma rozróżnienia między dwiema formami zarządzania konfiguracją, a proces jest ciągły i wspiera cały cykl świadczenia usługi i eksploatacji usługi. Zostało to określone jako zarządzanie konfiguracją przedsiębiorstwa. Nawet tutaj artefakty oparte na programowaniu nadal powinny być odróżniane i trzymane oddzielnie od zarządzania gwarantowaną jakością, ostatecznymi wersjami głównymi dostępnymi do wdrożenia. W przypadku outsourcingu lub umowy obejmującej wielu dostawców istnienie lub brak spójnej i bezpiecznej formy dostępu do dostawców będzie decydować o tym, czy zarządzanie konfiguracją oprogramowania odbywa się w sposób pasywny (zewnętrznie przez dostawców przyjmujących własne narzędzia SCM, a następnie dostarczających gotowy produkt), czy też nie. aktywnie (nadzorowane wewnętrznie z dostawcami przy użyciu centralnie hostowanego narzędzia SCM). Jednak wszystkie gotowe produkty (oprogramowanie aplikacyjne) w ich autoryzowanej, nadającej się do wdrożenia formie powinny być przechowywane w centralnym DML.

Typowe elementy CI, które będą przechowywane w DML, obejmują:

  • Wewnętrzne oprogramowanie użytkowe w pakiecie
  • Komercyjne gotowe surowe media (COTS).
  • Dostosowane oprogramowanie COTS (zawierające ulepszenia, dostosowaną konfigurację itp.)
  • Wydawaj pakiety
  • Łatki (zobacz łatki (przetwarzanie) )
  • Złote kompilacje (klienci, serwery, urządzenia sieciowe i pamięci masowej itp.)
  • Obrazy systemowe
  • W wielu stosach technologicznych i technologiach dystrybucji (np. Wintel, UNIX, ORACLE, mainframe, sieć, pamięć masowa itp.)

Cykl życia publikacji w mediach

(patrz diagram „Definitive Media Library i CMDB w kontekście procesu zarządzania wydaniami” powyżej)

Etapy cyklu życia publikacji w mediach to:

  1. Powstaje zapotrzebowanie na nową usługę lub produkt.
  2. Decyzja o wykonaniu lub zakupie produktu (usługi, kompilacji lub aplikacji) jest podejmowana na podstawie wymagań funkcjonalnych wyodrębnionych z narzędzia identyfikowalności wymagań. Produkt jest tworzony lub wybierany z katalogu usług/produktów zgodnie z zasadami projektowania architektonicznego (Service Design). Produkt COTS jest nabywany i przechowywany w DML ze statusem zasobu „zakupiony”. Jeśli jest nowy, produkt zostaje dodany do Katalogu Zatwierdzonych Produktów. Stworzony we własnym zakresie kod źródłowy aplikacji jest zarządzany bezpośrednio w repozytorium zarządzania konfiguracją oprogramowania.
  3. Jeśli pakowany jest produkt COTS lub złota kompilacja, media są wyodrębniane z DML.
  4. Produkt jest pakowany lub opracowywany i pakowany (w takim przypadku funkcje dodatkowe są traktowane w taki sam sposób, jak aplikacje i kompilacje wewnętrzne).
  5. Rekordy pośredniczące lub oryginalne linie bazowe są tworzone w narzędziu do zarządzania konfiguracją oprogramowania.
  6. Wersje kodu programistycznego i wersje pakietów są rejestrowane w narzędziu do zarządzania konfiguracją oprogramowania w trakcie opracowywania.
  7. Przeprowadzane są testy jednostkowe.
  8. Pakowanie jest zakończone, aby utworzyć pakiet wydania.
  9. Pakiet produktów ma zapewnioną jakość (w tym testy, etapy i wszelkie przeróbki).
  10. Gotowy pakiet nośników (kompilacja, usługa lub aplikacja) jest ponownie umieszczany w DML jako autoryzowany nośnik gotowy do wdrożenia.
  11. Po zatwierdzeniu Change Management, produkt jest uwalniany do osiedla za pośrednictwem odpowiedniego systemu dystrybucji z logicznymi instalacjami rejestrowanymi w odpowiednim procesie w CMS (CMDB).
  12. Jednostki DML są archiwizowane, gdy tylko:
    1. CMS lub CMDB wskazuje, że wersja pakietowa nie jest już używana w żadnej lokalizacji (wymagany jest okres karencji po ostatnim wycofaniu z eksploatacji lub aktualizacji, aby umożliwić wszelkie niezbędne regresje) oraz
    2. Jednostka DML została usunięta z katalogu technicznego lub użytkownika (usługi) jako pozycja do wyboru

Dystrybucja

Chociaż DML jako autoryzowany magazyn mediów wymaga pewnego stopnia centralizacji, do osiągnięcia modelu globalnego potrzebne będą lokalne biblioteki mediów (LML). W ten sposób wydawanie i wdrażanie fizycznych wystąpień nośników można osiągnąć w kraju w odpowiednim czasie, unikając ciągłego pobierania przez globalną sieć. Replikacja autoryzowanych nośników w oknach typu non-prime sprawiłaby, że wymagane pakiety byłyby dostępne lokalnie zgodnie z wymaganiami, ale DML pozostałby „głównym” ze względu na kontrolę procesu. Hierarchia DML/LML jest równoznaczna z głównymi/pomocniczymi warstwami dystrybucji występującymi w wielu technologiach dystrybucji i systemach zarządzania pakietami. Jednakże, podczas gdy narzędzia dystrybucyjne są zwykle ukierunkowane na określony stos technologii (np. Wintel, Unix, Mainframe itp.), jedną z głównych zalet DML jest jego niezależny od technologii charakter i prawdziwy centralny magazyn dla całego autoryzowanego oprogramowania. W ten sposób narzędzia dystrybucyjne łączyłyby się z DML w celu uzyskania pakietu oprogramowania. Pakowanie aplikacji obejmuje przygotowanie standardowych, ustrukturyzowanych instalacji oprogramowania przeznaczonych do zautomatyzowanego wdrażania. Opakowanie jest również wymagane w przypadku oprogramowania zakupionego (COTS), ponieważ opakowanie umożliwia skonfigurowanie oprogramowania do wydajnego działania na określonej platformie lub w określonym środowisku. Nawet niewielka zmiana na tej platformie (taka jak wymiana dysku) może uniemożliwić pomyślne wdrożenie pakietu, dlatego zachowanie wersji oprogramowania raw media (ISO) ma kluczowe znaczenie, ponieważ będzie to potrzebne (często w sytuacjach awaryjnych). wersja spakowana nie jest już wdrażana, np. po aktualizacji lub wymianie platformy operacyjnej.

Korzyści

DML obsługuje;

  • Zarządzanie wydaniami i wdrożeniami jako podstawa i centralny obszar przechowywania dla wszystkich pakietów wdrożeniowych, które można wydać
  • Dostępność i ciągłość usług poprzez zapewnienie źródła wszystkich spakowanych aplikacji i nieprzetworzonych nośników do wykorzystania w procedurach przywracania usług i odzyskiwania po awarii
  • Zautomatyzowane udostępnianie i racjonalizacja serwerów dzięki przechowywaniu złotych kompilacji
  • Zarządzanie zasobami poprzez dostarczanie rekordów metadanych i kluczy licencyjnych związanych z udzielaniem licencji na oprogramowanie COTS. Przechowywane instancje nośników i autoryzowany zestaw nośników wraz z licencjami i warunkami licencyjnymi pozwolą zoptymalizować zarządzanie alokacjami oprogramowania i zgodnością zewnętrzną w zakresie zaleceń Sarbane-Oxley i BSA.
  • Spełnianie żądań skatalogowanych, zarówno pod względem żądań produktu końcowego klienta dla jednego użytkownika, jak i powtarzających się żądań wdrożenia istniejącej usługi/aplikacji dla wielu użytkowników w innych lokalizacjach hostingowych.

Zobacz też

Linki zewnętrzne