Workshop. Nachhaltigkeit in der Entwicklung. Stefan Suchi. 1. Stud.IP Tagung September 2003

Transkript

1 Workshop 1. Stud.IP Tagung September 2003 Nachhaltigkeit in der Entwicklung

2 Weiterentwicklung? Arbeitsprogramm Ziele und Probleme der Weiterentwicklung Verteilte Entwicklung Wie können externe Entwickler partizipieren? Release Wann gibt es eine stabile Version? Updates Wie kommen die neuen Funktionen auf das Produktivsystem? Werkzeuge

3 Ziele Weiterentwicklung? Erweiterung des allgemeinen Funktionsumfangs Berücksichtigung von Spezialitäten der einzelnen Universitäten Verbesserung von Bedienbarkeit, Navigation und Design Verbesserung der Code-Qualität Verbesserte Installation und Update-Fähigkeit

4 Probleme Weiterentwicklung? Abstimmung der Konzeption Qualitätssicherung des Codes/Designs Aktuelle Dokumentation, Übersetzung und Hilfe Support für das Gesamtprodukt

5 Verteilte Entwicklung In welcher Form können sich externe Entwickler beteiligen? Konzeption Testen / Bugreports Bugfixes Dokumentation und Hilfe Eigene Entwicklungsstränge Problem: Updatefähigkeit Neue Funktionen im Hauptstrang Problem: Qualitätssicherung

6 Verteilte Entwicklung Modell Entwicklungsvertrag Beliebige Module CVS-Schreibrecht Garantierte Aufnahme in das nächste Release Pflege und Fortführung der Funktionen Abrechnung auf Stundenbasis Zielgruppe: Größere Institutionen, die kontinuierlich eigene Funktionen implementieren wollen

7 Verteilte Entwicklung Modell Patches Beliebige Module Kein CVS-Schreibrecht; DIFFs gegen den aktuellen CVS-Stand oder Dateien des aktuellen CVS-Standes mit eingebauten Änderungen Keine Garantie, ob und wann die Änderungen aufgenommen werden Pflege und Fortführung der Funktionen nicht garantiert unentgeltlich Zielgruppe: Institutionen mit wenig Eigenentwicklungen; Privatpersonen

8 Modell Maintainer Verteilte Entwicklung Ein genau definiertes Modul CVS-Schreibrecht Maintainer muss Bugfixes, Pflege und Fortführung der Funktionen garantierten Zielgruppe: engagierte Entwickler; Institutionen, die klar vom Kernsystem abgrenzbare Module entwickeln

9 Release Was läuft auf den Produktivsystemen? Modell kontinuierliche Entwicklung Erfüllt nicht die geforderten Qualitätsansprüche Modell stable/unstable Branch viel unangenehme Doppelarbeit bisher zu kleines Team Modell strukturierter Release-Zyklus bietet sich an, da alle Uni's und FH s ungefähr denselben Turnus haben wie sollen die Zeitpunkte aussehen?

10 Ablauf- / Zeitplan Release Programmierungsphase Table- und Feature-Freeze 1. August Code-Freeze 1. September Update des Produktiv-Systems 1. Oktober Release, Trennung Testserver und Produktivsystem Mitte November

11 Updates Das bisher genutzte Verfahren Während der Entwicklung Sammeln der Datenbank-Änderungen als SQL-Befehle Sammeln von eventuell nötigen Konvertierungsroutinen als einzelne PHP-Scripte Tag des Updates Update des Quellcodes von Hand Ausführen der SQL-Befehle und Aufruf der Konvertierungsscripte in der richtigen Reihenfolge von Hand Update-Protokoll Produktivsystem Göttingen

12 Updates Vorschlag für einen Update-Assistenten Datenbank-Versionsnummer jede Strukturänderung, neue Tabelle und Konvertierungsscript bekommt eine kontinuierlich hochgezählte ID Update-Maschine für root Ermittelt die Version der Datenbank führt Update-Scripte nacheinander aus ändert bei Erfolg die Versionsnummer der Datenbank Änderungen an der Datenbank werden also via ins CVS eingecheckte Update-Skripte vorgenommen

13 Werkzeuge Welche Programme und Systeme nutzen wir? CVS Forum (Diskussion, Konzeption, Bugtracking) Wiki (Konzeption, Dokumentation) Dateibereich (Screenshots, Anleitungen) Terminkalender, News PHP-Sourcecode Struktur-Dump der Datenbank