31.10.2008
Best Practice (6): Baselines — die sichere Basis
Die Baseline ist der gesicherte Stand des letzten Releases, auf dem das neue Release aufbaut. Ohne diese sichere Basis ist geordnetes Entwickeln unmöglich. Sie muss im Laufe der Entwicklung hochgezogen werden, d.h. sie muss nach und nach gesicherte Weiterentwicklungen integrieren, denn sonst erfüllt sie ihre Aufgabe als Basis nicht mehr.
«Als Baseline bezeichnet man den Stand, den die Software bei der Definition des letzten Releases erreicht hat, und jetzt Basis — Baseline — für den neuen Release ist. Eine anscheinend banale Anforderung, die aber längst nicht überall erfüllt ist.» — Soweit unser Referenzmodell.
In den vorangehenden beiden Best-Practice-Beiträgen haben wir mit dem Anspruch auf
fortlaufende Integration und auf die Bildung von Change-Paketen nach vorne geschaut. Jetzt blicken wir zurück zum Ausgangspunkt der laufenden Entwicklung, zur Baseline.
Die Forderung nach fortlaufender Integration ist nur scheinbar ein Widerspruch zur Forderung nach einer Baseline. Im Gegenteil: Die Baseline ist Voraussetzung für die laufende Integration (Continuous Integration). Was geschieht, wenn es keine stabile Baseline gibt (und sonst noch ein paar Dinge nicht so laufen, wie sie nach Schulbüchlein sollten), illustriert unser Bericht über diesen Praxisfall.
Der Entwickler ist auf die Baseline angewiesen: Entwickelt oder ändert er ein Stück neue Software, muss er sicher sein, dass dieses zusammen mit dem bisherigen Artefakten läuft. Er muss es mit diesen zusammen — mit der Baseline — testen können. Die Baseline muss also über die ganze Entwicklungszeit hinweg erhalten bleiben. Wirklich über die ganze Zeit? Bei grösseren Systemerweiterungen und -änderungen kommt schlagartig ein Zeitpunkt, von dem an die ursprüngliche Baseline als Referenzpunkt nicht mehr verwendbar ist. Zum Beispiel dann, wenn mehrere zentrale, häufig verwendete Module geändert worden sind und das System nur noch mit den neuen Versionen betrieben werden kann. Dann muss eine neue Baseline gebildet werden. Dieser Sachverhalt in den Worten unseres Referenzmodells:
«Logisch zusammengehörende Teile eines neuen Releases können nach Bedarf als Paket (Stückliste) zu grösseren Konfigurationen zusammengesetzt werden. Das Paket muss so geschnürt sein, dass die darin enthaltenen Softwareteile 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 Candidate) versehen, wird sie als Einheit auf die nächst höhere Stufe transportiert (promote), als Einheit generiert und für die Tests freigegeben.»
Die Baseline ist der sichere Boden, auf dem der Software-Entwickler aufbaut. Das Bilden einer Baseline ist vergleichbar mit dem Buchhaltungsabschluss. Man kann nicht einfach irgendwann einmal «einen Strich ziehen» und meinen, so, das ist es jetzt. In der Buchhaltung braucht es Abgrenzungen und Abschlussbuchungen, damit das Ergebnis wirklich der Periode entspricht. Beim Bilden der Baseline muss entschieden werden, was alles einfliessen muss und darf, damit die Baseline ein in sich stimmiges Ganzes bildet.
Dazu braucht es Wissen über die Anwendung sowie über die laufenden Entwicklungen und deren gegenseitige Abhängigkeiten. Es ist eine Planungs- und Organisationsaufgabe, die bei den grossen Mengen an Artefakten nur mit einen integrierten Werkzeugsystem zu bewältigen ist.
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
