28.01.2009
Das Configuration Management im SCCM schafft Ordnung
Wir reden hier vom «Configuration Management» (Konfigurations-Management) im engeren Sinne, als organisatorische Einheit bzw. als Disziplin innerhalb des umfassenden SCCM (Software Change and Configuration Management).
Aufgabe: Das Configuration Management legt Konfigurationen fest.
Im Maschinenbau würde man von Baugruppen sprechen, dargestellt durch eine Stückliste. Es bündelt vorhandene Software-Artefakte (a bis e) zu logischen Einheiten (Konfigurationen, KO1 bis KO3), die wiederum zu grösseren logischen Einheiten bzw. Konfigurationen zusammengefasst werden können (Software-Produkt oder -Teilprodukt, Change-Paket, neuer Release usw.). Eine ganze Software-Anwendung ist auch eine Konfiguration und besteht letzten Endes auch aus einer Menge von Artefakten.
Grosses BildSCCM Disziplin: Configuration Management
Eine Konfiguration kann und muss nach Bedarf geändert werden können (KO2). Jede Änderung an einer Konfiguration wird im Versionsverwaltungs-System gespeichert und versioniert.
Diese Einheiten werden ihrerseits über das «Change Management» den Change Requests zugeordnet.
Konfigurationen erstellen – logische Einheiten bilden
Unter einer Konfiguration versteht man primär: eine Menge von Artefakten, die miteinander physisch zusammenhängen, z.B. eine Programm-Source mit allen dazugehörenden Include-Dateien, Programm-Spezifikation und –Dokumentation, programmspezifische Help-Files, Job-Control usw.
Logisch zusammengehörende Teile eines neuen Releases können nach Bedarf als Change-Paket (Stückliste) zu grösseren Konfigurationen zusammengesetzt werden. Das Paket muss so geschnürt sein, dass die darin enthaltenen Software-Teile und Dokumente als konsistente Einheit auf jeder höheren Stufe den Qualitätsanforderungen genügt. Bevor eine in sich konsistente Konfiguration als Paket auf der nächst höheren Stufe integriert werden kann, wird sie eingefroren und fortan Baseline genannt. Mit einem Namen (Release Candiate) versehen, wird sie als Einheit auf die nächst höhere Stufe transportiert (promote), als Einheit generiert und für die Tests freigegeben.
Die Konfiguration auf der obersten Ebene umfasst schliesslich eine ganze Anwendung. Die aus der Baseline erzeugte Software (inkl. Dokumente) ist ein Teil des an den Kunden auslieferbaren Produkts (Release) und erhält vom Release Management eine Release-Identifikation.
Nutzen
Damit kann bei einer Störung über das Konfigurations-Management eruiert werden, aus welchen Artefaktversionen das Softwarepaket zusammengesetzt ist, das beim Kunden installiert ist.
Ohne genau zu wissen, was installiert ist, ist das Reparieren von Fehlern immer gefährlich und bisweilen unmöglich. Diese Aufgabe ist bereits bei wenigen Modulen und ein paar wenigen Releases eine grosse Herausforderung, die viele Entwicklungsabteilungen nicht erfüllen.
Infrastruktur, Software
Die für das Konfigurations-Management eingesetzte Software muss die Definition von versionierbaren Baugruppen und Stücklisten (Konfigurationen) ermöglichen. Sie muss ausserdem den Zustand von Stücklisten «einfrieren» (Baseline) können und die Zuordnung eines Namens (Release) erlauben.
Möchten Sie mehr über das Configuration Management erfahren?
In unserem SCCM-Referenzmodell (PDF, 390 KB) erfahren Sie mehr über die Aufgaben, Ziele und Nutzen eines integrierten und automatisierten SCCM-Systems.



















Softwareentwicklungsprojekte sind fast immer Parallelentwicklungen, bei denen mehrere Entwickler Änderungen am Projekt vornehmen, die integriert werden müssen, um das Projekt zu kompilieren. Weiterhin müssen alle Änderungen in jedem Teil des Systems erfasst werden, um Probleme zu identifizieren und zu lösen. Aus diesem Grund ist es wichtig, ein Software-Konfigurationsmanagementsystem (SCM) einzusetzen, um jede Änderung am Code strikt mit einer Versionsnummer zu versehen. Zudem muss natürlich alles, was zum Kompilieren des Systems benötigt wird, eingecheckt werden. Dazu gehören:
Externe Bibliotheken
Property-Dateien
Datenbankschemata
Testskripte
Installationsskripte
Jeder Entwickler sollte zudem mindestens Lesezugriff auf all die Dateien haben, die für das Kompilieren notwendig sind und sollte diese Dateien immer direkt aus dem SCM System ziehen. Dieser Ansatz garantiert, dass alle mit der neuesten Kompilierumgebung arbeiten und sollte dem landläufigen, aber fehleranfälligen Platzieren dieser Dateien auf einem freigegebenen Netzwerklaufwerk vorgezogen werden.
http://www.accurev.com/kontinuierliche-integration