Ich hab' zwar jemandem versprochen, mich hier nicht mehr über rein technische und hinter den Kulissen ablaufende Sachen zu äußern, aber in den letzten Tagen hab' ich ein paar Mal das Bedürfnis gehabt, auf den Text, den ich jetzt schreibe, verweisen zu können.
Es wird wahrscheinlich für die Mehrzahl von euch völlig unwichtig sein.

Also, das ist so:

• Es gibt einmal die laufende, produktive Umgebung. Das ist, was die Mehrzahl von euch benutzt - http://naturfotografen-forum.de nämlich. Nennen wir die mal "L".
• Dann gibt es die Betaversion. Nennen wir die mal "B".
  
• Und dann gibt's noch die, in der ich entwickle. Ich nenne sie "alpha" und verlinke sie hier nicht. Sie sei "A".

Alle drei greifen auf dieselben Bilddateien und dieselbe Datenbank zu. Das hat den schönen Vorteil, daß man alpha und beta auch tatsächlich ernsthaft benutzen kann - ein Bildupload da zeigt sich auch in der produktiven Umgebung. Der Vorteil schlägt manchmal in einen Nachteil um, gestern war so ein Tag.

Softwareänderung

Die Sache ist noch ein wenig komplizierter - jede der Umgebungen besteht aus zwei Softwareteilen, einmal dem Grundsystem und dann dem speziellen Code für das Forum. Das kann man aber für praktisch alle Zwecke ignorieren und als ein Softwaresystem ansehen, aber beim Softwareupdate sorgt diese Eigenschaft gelegentlich für Ärger.

Typischerweise laufen Softwareänderungen so:

1. ich ändere etwas in der Alphaversion, teste es durch.
2. dann sag' ich der Betaversion, sie soll sich die Änderungen der Alpha holen. Da können und sollen die dann ein paar andere Leute ausprobieren.
3. und irgendwann später soll sich die produktive Umgebung die Änderungen der Beta holen.

Oft ist das so, daß in der Beta ein paar Sachen drin sind, die noch nicht fehlerfrei oder fertig sind.
Wenn das der Fall ist, und irgendeine Änderung dringend in die produktive Umgebung muß, kann ich bei kurzen Sachen entweder direkt in der p.U. etwas ändern, oder eine vierte Umgebung nutzen.

Egal welche Variante ich wähle, das grundlegende Problem ist dasselbe: Wenn später dann die produktive Umgebung die Änderungen aus der Beta übernehmen soll, geht der Prozess möglicherweise schief - nicht immer, aber zu oft.

Das Versionskontrollsystem (eine Software zur Erfassung von Änderungen an Software), das ich benutze, bricht nämlich in dem Fall gerne ein Update ab, was vielen Fällen auch richtig ist, in anderen aber unsinnig ist. Es tut es nur auf eine ziemlich dämliche Art, es liefert nämlich keinen sauberen Fehlerstatus.

Und dann kann es passieren, daß das Update des Grundsystems fehlgeschlagen ist, aber der forumsspezifische Code aktualisiert wird. Das muß nicht immer schlimm sein, aber es kann: Es kann nämlich sein, daß der neuere forumsspezfische Code auf ein neueres Grundsystem angewiesen ist. Und wenn das nicht da ist, naja, dann knallt es, und es kommen unter Umständen sehr interessante Zeiten auf denjenigen zu, der das wieder flicken darf.

Das könnte man mit erhöhter Sorgfalt oder mit einer weiteren Umgebung vermeiden, aber... das ist im Grunde viel zu viel Aufwand für eine Sache, die in einem von 25 Fällen wichtig ist.

Also habe ich mich für Variante 3 entschieden: An der Betaumgebung vorbei wird nur bei wirklich absolut kritischen Problem gearbeitet. Problem gelöst.

Gelöst? Naja, ein Problem bleibt: Die Reaktionszeiten ändern sich. Eine kleine Änderung zur Behebung eines Problems wartet dann mit den großen Änderungen zusammen in der Betaumgebung darauf, daß der ganze Kram insgesamt brauchbar scheint.

Manchmal geht's schnell, wenn nämlich keine Änderungen in der Betaversion sind, manchmal dauert's dagegen Monate.

Nein, optimal ist das nicht wirklich, aber ein relativ effizienter Einsatz meiner Zeit ist es.

Praktisch ist das übrigens noch etwas komplizierter, Änderungen am Grundsystem kommen gelegentlich auch von außen.

Datenbankänderungen

Manchmal reicht es, nur etwas an der Datenbank zu ändern, ohne daß irgendwelche Änderungen an der Software erforderlich sind.

Die EBV-Sache gestern war so ein Fall. Richtig, das Desaster...

Im Idealfall macht man das so:

1. Forum abschalten
2. Datenbankbackup machen
3. Änderungen durchführen
4. Forum wieder anschalten

Yeah. Ideal. Bis auf die Zeit, in der es abgeschaltet ist, und bis auf die Tatsache, daß es nicht getestet werden kann, bevor es live geht.

Die zweitidealste Vorgehensweise:

1. neue Datenbank anlegen
2. das nachts automatisch erzeugte Datenbankbackup dort einspielen
3. Änderungen durchführen
4. Testumgebung aufsetzen (alpha und beta scheiden für den Zweck momentan aus)
5. austesten
6. Änderungen dann an der wirklichen Datenbank durchführen

Deutlich mehr Aufwand (grob geschätzt 3h), aber keine Ausfallzeit. Und genauso gut im Ergebnis.

Theoretisch.

Praktisch ist das natürlich ganz anders ausgegangen.

1. aus irgendeinem Grund war das Backup einfach noch nicht fertig. Sonst lief es in 14 Minuten in der Nacht durch, gestern brauchte es mal eben etwas über 4 Stunden. Nein, ich weiß nicht warum, die Kiste war längst nicht ausgelastet.
2. Daher hab' ich ein unvollständiges Backup verwenden, und mich dann beim Testen gewundert, warum so wenig Bilder in der Datenbank sind (erste Reaktion: "wie in aller Welt habe ich 50000 Datensätze gelöscht? Das geht doch nicht so schnell.").
3. Dann hab' ich etwas gewartet, bis das Backup fertig war.
4. Und alles sah gut aus.

Wieso dann die Sache mit der Montage nicht aufgefallen ist? Weil ich übersehen hatte, daß in der Testumgebung den Cache der laufenden Umgebung verwendete... alles sah gut aus, aber das hauptsächlich deshalb, weil die *alten* unveränderten Daten verwendet wurden.

Oops.

Das nächste Problem lies nicht lange auf sich warten: Eigentlich sollte die Bearbeitungsziel-Sache aus drei Radiobuttons bestehen. Das klappt auch, aber ich hätte das besser mal auf kleineren Bildschirmen getestet, denn auf denen brach das ausgesprochen häßlich um. Daher hab' ich das dann auf ein Auswahlfeld umgestellt. Ok, damit kann man leben, sieht so wahrscheinlich besser aus.

Und dann kam die nächste Überraschung: Eigentlich wollte ich die drei neuen Ebv-Felder HDR, Gestempelt und Tiefenschärfe in eine Zeile tun.

Nun, eigentlich ist das trivial und einfach zu machen - man stellt in der Datenbank ein, daß die drei Felder zusammen gruppiert werden. Und eigentlich funktioniert das auch, jedenfalls anderswo. Folglich hab' ich die Kleinigkeit, nachdem es gestern sowieso schon viel zu lange gedauert hat, nicht noch extra getestet.

Genau, ich hätte es testen sollen. Es funktioniert nämlich diesmal nicht, weil die Software es nicht mag, wenn zu wenige Checkboxen zusammen gruppiert werden (zu wenig = weniger als 8). Und bei der Eingabe gab's auch einige Besonderheiten... folglich hab' ich die Gruppierung erst mal abgeschaltet.

Software- und Datenbankänderungen

Manchmal muß man auch beides ändern, um ein Ziel zu erreichen. Diesmal zum Beispiel muß ich erst mal den Code für die Gruppierung in Ordnung bringen, und auf die produktive Umgebung spielen, bevor ich die Umstellung in der Datenbank machen kann.

Und damit dauert das eine Weile.



Gruß, Uwe