Kürzlich stellten wir bei der Situationsanaylse bei einem Outsourcer fest, dass dieser die grössten Schwierigkeiten hat, Fehlerkorrekturen bei seinen Kunden einzuspielen, weil es ihm nur mit grösstem Aufwand gelingt, das Release wiederherzustellen, das beim Kunden installiert ist.

(Für Uttam Nasru ist die Wiederherstellbarkeit eine der Best Practices, die ein heutiges SCCM-System beherrschen muss. Siehe dazu unseren früheren Blogeintrag.)

Ob Outsourcer oder interne Entwicklungsabteilung, Fehlerkorrekturen an Software gibt es immer, und damit die Notwendigkeit, ein früheres Release wiederherzustellen. Zu einem Release gehören alle Artefakte und – das geht gerne vergessen – auch alle Werkzeuge, um das Release zu erstellen und zu betreiben: Programmierwerkzeuge, Compiler, Linker, DBMS usw.

Die Wiederherstellbarkeit ist das oberste und schwierigste Ziel, das ein SCCM-System erreichen muss, damit ein Software-Lieferant – ob intern oder extern – seine Aufgabe erfüllen kann. Kann er es nicht, steht es schlecht um die Ordnungsmässigkeit seiner Software-Buchhaltung.

Hand aufs Herz: Wie viele Entwicklungsabteilungen können von sich behaupten, dass sie dieser Prüfung standhalten?

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

«Man würde meinen», das Anlegen privater Arbeitsbereiche (Sandboxes, Workspaces) in der Entwicklung wäre eine Selbstverständlichkeit. (Uttam Narsu sieht sie als eine der Best Practices, wie in einem früheren Blogeintrag zu lesen ist.) Man ist aber bass erstaunt, dass dem nicht überall so ist, wie wir letzthin bei einer SCCM-Situationsanalyse festgestellt haben. In dieser Mainframe-Umgebung haben die Entwickler keine Privatsphäre: Es gibt nur eine öffentliche Bibliothek, wo Abertausende von Artefakten liegen.

Wenn Sandboxes fehlen, kann keiner für sich allein «im stillen Kämmerlein» seine Programme testen. Er muss es im öffentlichen Bereich tun, wodurch er die anderen stört und sie ihn. Anstatt dass die Infrastruktur dazu beiträgt, sich die Arbeit gegenseitig zu erleichtern, bewirkt sie das Gegenteil.

Wenn beim Testen ein Fehler auftaucht, sucht natürlich jeder Entwickler in seinem Programm. Nur, wenn keine privaten Workspaces da sind, ist diese Suche oftmals vergeblich, wenn nämlich der Fehler durch Änderungen anderer Entwickler in anderen Modulen verursacht worden ist. Da kommt es vor, dass zwei Entwickler an derselben Schnittstellenbeschreibung etwas ändern. Beide machen nichts falsch, und doch behindern sie sich gegenseitig. Jeder vergeudet Zeit mit vermeidbarer Fehlersuche. Das sind teure, unproduktive Stunden, die durch private Workspaces leicht vermieden werden.

Erst wenn die Tests in den privaten Entwicklungsbereichen erfolgreich verlaufen sind, erst dann befördert der Entwickler die getesteten Artefakte auf die nächsthöhere, öffentliche Stufe.

Der Entwickler muss also im privaten Arbeitsbereich Programme compilieren und ausführen können, mit Zugriff auf Datenbanken und Testdaten. Das Einrichten solcher Umgebungen kostet, aber es ist günstiger als die Behebung der Probleme, die fehlende Workspaces nach sich ziehen.

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

Was Marco Gerussi unter dem Titel «Lohnt sich werkzeuggestütztes Test-Management» schreibt, können wir in allen Teilen unterschreiben. Zudem gelten die Argumente für die Automation nicht nur für das Test-Management, sondern generell für das Software -Engineering und -Management.

Den ganzen Beitrag lesen »

Unseres Wissen ist dieses der einzige deutschsprachige Blog zu SCCM, abgesehen von Blogs zu SCCM-Produkten. Das hat damit zu tun, dass das Bewusstsein, dass SCCM notwendig und sinnvoll ist, im deutschsprachigen Raum nicht so ausgeprägt ist wie im englischen. Wenn es so läuft wie auf anderen Gebieten, dann ist es nur eine Frage der Zeit, bis auch SCCM bei uns stärker ins Gespräch kommt. Grund genug, drei amerikanische Blogs vorzustellen.

Brad Appleton schreibt in «Brad Appleton’s ACME Blog» über das SCCM aus der Sicht der agilen Entwicklung. Ja, auch oder gerade die Vertreter der agilen Entwicklung kümmern sich ganz besonders um das SCCM: Denn wie sollte man agil entwickeln können, wenn die stabile SCCM-Basis im Form von Ordnung, Strukturen und Abläufen nicht gegeben ist? Brad Appleton ist zusammen mit Steve Berzcuk Co-Autor des Buches «Software Configuration Management Patterns: Effective Teamwork, Practical Integration», das Sie auf seiner Web-Site auch finden. Stöbern auf der Site lohnt sich, denn Brad Appleton hat im ACME-Blog, seiner persönlichen Website und auf der ACME-Seite eine Menge von Links zum Software Engineering übersichtlich zusammengetragen.

CM Crossraods ist eine reichhaltige Website zu Configuration Management, u.a. mit Links auf Blogs. Das Thema ist hier nicht eingeschränkt auf Software Configuration Mangement sondern ausgedehnt auf Configuration Management im allgemeinen. Entsprechend gross ist das Angebot an Information.

Planet SCM ist ein SCCM-Feed-Aggregator von Andrew Wheeler, der rund zwei Dutzend Blogs zusammenführt, bei denenen SCCM auch ein Thema ist – eines unter anderen aus dem Software-Engineering.