16.10.2008
Best Practice (5): Change-Pakete bilden
In neuen Software-Verwaltungs- und in Informations-Systemen sorgen Transaktionsmechanismen mit der Alles-oder-nichts-Regel für konsistente Zustände: Eine Update-Transaktion wird vollständig oder gar nicht durchgeführt. Ältere SCCM-Systeme kennen den Transaktionsbegriff nicht und verlassen sich auf die ausführende Person, dass sie die Alles-oder-nichts-Regel einhält.
Das Einchecken in eine Entwicklungs-/Releasebibliothek ist ein Update, eine Veränderungstransaktion. Ob Check-in in eine Entwicklungsdatenbank oder ein Update in irgend einem Informationssystem, Update ist Update. In jedem Fall muss die Datenbasis von einem konsistenten Zustand zum nächsten überführt werden.
Die Garantie des konsistenten Zustands ist die Crux eines jeden Updates und kann manuell kaum gewährleistet werden. Die Lösung heisst Änderungen und Erweiterungen zu Paketen bündeln, sog. Tasks, so dass das SCCM-System die Vollständigkeit der Update-Transaktion über die gesamte Task garantierten kann.
In alten, aber immer noch im Betrieb stehenden Systemen wird Datei um Datei eingecheckt — man spricht von dateibasierter (file-based) Versionierung. Sie verlassen sich auf den für den Check-in verantwortlichen Entwickler, dass er die Alles-oder-nichts-Regel einhält. Es liegt an seiner Sorgfalt und Geduld, dass er alle zu einem Auftrag gehörenden Sources – mit der richtigen Version — in die Entwicklungsdatenbank lädt. Dass das selbst dem sorgfältigsten Mitarbeiter nicht immer gelingt, kennen wir zur Genüge. «Da habe ich das Element xy vergessen! Das habe ich ja auch noch ändern müssen, war fast nichts!», sind wohl die bekanntesten Sätze, wenn ein Fehler auftaucht, der auf ein unvollständiges Update zurückgeht. Das muss so nicht sein.
Neuere SCCM-Systeme kennen Transaktionen: Die zu einem Änderungs- oder Erweiterungsauftrag (Task) gehörenden Elemente werden dem Auftrag einmal zugeordnet, die Zuordnung wird festgehalten. Beim Check-in sorgt das System aufgrund dieser Liste (Change-Paket) automatisch und verlässlich dafür, dass kein Element beim Update vergessen geht. Wenn während der Auftragsausführung ein Element dazukommt, muss der Entwickler es der Auftragsliste hinzufügen, ehe er es bearbeiten kann, womit die Vollständigkeit des späteren Check-in gewährleistet ist. So arbeitende Systeme nennt man task-basiert.
Die Zuverlässigkeit des Automaten ersetzt die menschliche (Un)Sorgfalt des Entwicklers. Das auftragsbezogene Verfahren verhindert viele Fehler und verhilft damit zu einer beträchtlichen Qualitätssteigerung und Aufwandsminderung. Die Änderungen lassen sich vom Antrag (Request) bis zur Implementierung und zum Testen auftragsbezogen ausführen und verfolgen.
Weitere Beiträge in der Best-Practices-Reihe:
(9): Kennzahlen – Grundlage für Prozessverbesserungen
(8): Plan your environment carefully
(7): Structure for distributed development
(6): Baselines — die sichere Basis
(5): Change-Pakete bilden
(4): Merge and Integrate as often as possible
(3): Wiederherstellbarkeit
(2): Private Arbeitsbereiche
(1): Forget One-Size-Fits-All SCM / Design Scaleable Best Practices
