2.7 Versions- und Konfigurationsmanagement

Anforderung an ein Versions und Konfigurationsmanagement Warum so oft wie moeglich integrieren.

Versionierung:

• Entwickler haben i.a. neuere Versionen als die Anwender
• Wenn Anwender Fehler melden, sollte man den Fehler in der Version die der Anwender hat nachvollziehen.
• Jeder macht Fehler oder anderst ausgedrückt wer keine Fehler macht arbeitet nicht. Um erfolgreich zu sein braucht man den Mut Fehler zu machen. Wenn man versioniert hat, also leicht auf einen korrekten Stand zurückgehen kann; hat man auch den Mut ungewöhnliche Lösungen auszuprobieren.
• Es gibt i.a. nichts was sich nicht lohnt zu versionieren. Anforderungen, technische Konzepte, Testskripts, Besprechungsprotokolle und natürlich Source Code.
• Allgemeines Versionierungstool: CVS
• Versionierung von Datenbanken hat sich als sehr schwer erwiesen
• Hat man verschiedene Datenbanken (Test, Entwicklung, Produktion) so besteht die Gefahr, daß die bestehenden Datenbanken auseinanderlaufen.
• Erlaubt man Änderungen an den Datenbanken nur durch eine Person, so entsteht die Gefahr eines Flaschenhalses. Änderungen an Datenbank müssen beantragt werden.
• Hat jeder Zugriff auf jede Datenbank, so entsteht sehr schnell Chaos. Versionierung und Integration nur sehr schwer möglich.
• Mögliche Lösung zur Versionierung von Datenbanken:
• Änderungen an Datenbanken sollten nur durch Skripte erfolgen.
• Es gibt 3 Arten von Datenbanken: Gold, Silber und Bronze.
• Die goldene Datenbank ist die Produktionsdatenbank. Die goldene Datenbank wird i.a. nur von einer Person gewartet.
• Die silberne Datenbank entspricht einem einheitlichen Stand auf dem Weg zur goldenen Datenbank. Sie entspricht immer der letzten Integration der bronzenen Datenbanken. Die silberne Datenbank wird i.a. von nur einer Person gewartet.
• Jeder Entwickler hat seine eigene Bronze Datenbank. Dort kann er darin beliebig experimentieren. Einmal in der Woche werden die Bronze Datenbanken der Entwickler zu einer silbern Datenbank zusammengeführt. Danach bekommen die Entwickler eine Kopie der silbernen Datenbank als neue bronzene Datenbank.

Integration

• Wenn mehrere Personen an einem Projekt arbeiten, erhöht sich mit jeder Änderung die Gefahr; daß man auf alten Projektstand aufbaut.
• Ziel: So oft wie möglich die Arbeiten der Mitarbeiter integrieren; am besten täglich.
• Nach jeder Integration müssen alle Unittests erfolgreich laufen. Ggf. werden nach jeder Integration automisierte Qualitätskontrollen durchgeführt (Code Metriken). Diese Qualitätskontrollen sollten die Entwickler aber schon selber vor der Integration machen.
• Sind ein oder mehrere Unittests fehlerhaft, so muss zuerst der Fehler korrigiert werden, bevor jemand weiterentwickelt. Im Notfall muss man Code wegschmeissen; um wieder einen stabilen Stand zu bekommen.
• Nach jeder erfolgreichen Integration arbeiten die einzelnen Entwickler an einer Kopie der integrierten Version. Damit wird garantiert dass alle Entwickler am Anfang des Tages auf dem aktuellen Stand aufbauen.

Konfiguration

• Nicht jeder Anwender braucht alle Funktionalitäten des aktuellen Entwicklungsstand. Konfigurationsmanagement ermöglicht es aus dem Entwicklungsimage verschiedene RuntimeImage zu bauen. Es können gewisse Funktionalitäten eingebaut bzw. ausgebaut oder ausgetauscht werden
• Beispiele:
• Aus einem Entwicklungsimage werden für jedes Betriebssystem ein eigenes Runtime Image gebaut.
• Aus einem Entwicklunsgimage wird ein eigenes Runtime Image für Client und Server gebaut.
• Es werden je nach verwendeter Datenbank verschiedene Runtime Image benötigt (Ein Kunde hat Oracle der andere MySQL).
• Ohne durchdachte Softwarearchitektur ist i.a. keine Konfiguration möglich. Man muss wissen welche Softwarepakete voneinander abhängig sind; und es sollten keine gegenseitigen Abhängigkeiten zwischen Softwarepaketen sein.
• Konfigurations Tool fuer Java: ANT