Hallo Hellmut,

ich arbeite seit über 40 Jahren in der EDV einer Versicherung. Deswegen vertrete ich vielleicht einen sehr konservativen Standpunkt.

Und der lautet: Softwareentwicklung am Live-System ist grobe Fahrlässigkeit. Es gibt genau einen Fall, der das rechtfertigt: Irgendwie hat es ein fataler Bug ins Live-System geschafft, muss unverzüglichst eliminiert werden und Du weißt genau, was Du tun musst.

Bei regulärer Weiterentwicklung tut man das nicht. Selbst wenn Du es schaffst, deine Änderungen so zu erstellen, dass sie nur für Dich und ggf. ein paar Tester sichtbar sind, besteht jederzeit das Risiko, dass ein Softwarefehler die produktiven Daten verfälscht. Das fällt dann möglicherweise erst auf, wenn die beschädigten Datensätze bereits mehrere Backup-Generationen vergiftet haben.

ich soll eine größere Internetanwendung übernehmen, aktualisieren und erweitern.

Dieser Satz sagt mir: Du arbeitest in einem professionellen Umfeld und nicht in einer Hobbyklitsche - wie es bspw. Selfhtml ist.

Und selbst Selfhtml betreibt außer dem regulären Wiki ein Testwiki, in dem wir Codeänderungen verproben, bevor sie ins Hauptwiki kommen. Das aktuelle Projekt "Makeover des Selfhtml-Skins" wurde im Testwiki begonnen und findet nun allerdings im Hauptwiki statt, aber in einer Kopie des produktiven Skins (die man nach Wunsch aktivieren kann). Das hat einen Grund: die Datenbasis des Testwikis ist nicht hinreichend bzw. nicht alle Vorlagen sind identisch, so dass die Testzuverlässigkeit im Testwiki nicht gegeben ist.

Wenn Dir jemand in einem professionellen Umfeld verweigern will, professionell zu arbeiten, dann ist das ein Sparen am falschen Ende. Gerade bei einer größeren Anwendung können sich Änderungen unvermutet an Stellen auswirken, die man nicht bedacht hat, und ein „erfolgreicher Test“ (also einer, der einen Fehler nachweist) kann dann teuer werden.

Sicherlich gibt es Möglichkeiten, mit parallelen Codeversionen zu arbeiten. Man kann Schalter einbauen (wer bekommt alten und wer neuen Code), das ist lösbar. Das Hauptproblem ist jedoch, dass Du mit Code, der nicht oder nicht fertig getestet ist, auf produktiven Datenbeständen operierst. Und das tut man nicht.

Apache auf dem Server (beim Provider) kann ich nicht konfigurieren.

Jein. Euer Hoster sollte einige Einstellungen per .htaccess möglich machen.

Ich kann nur meine Dateien hochladen (z.B. mit Filezilla). Dorthin habe ich sie jetzt in ein eigenes Verzeichnis geladen.

Aber die eigenen Dateien operieren auf der produktiven Datenbank?

Ich habe mich für eine Subdomain entschieden.
Wie aber stelle ich sicher, dass beim Aufruf der Subdomain dieses Verzeichnis herangezogen wird?

Wenn die Verwaltungsoberfläche, die der Hoster bereitstellt, die Einrichtung von Subdomains ermöglicht, dann sollte dazu auch die Möglichkeit gehören, dieser Subdomain einen eigenen Ordner zuzuordnen. Bei dem früheren Hoster meiner privaten Website war es sogar so, dass das automatisch geschah. foo.example.com und example.com/foo zeigten auf den gleichen Ordner, ohne dass ich etwas konfigurieren musste.

Nachdem one.com die Preisschraube per Akkuschrauber betätigt hatte, bin ich zum Selfhtml-Hoster Manitu gewechselt und dort lege ich Subdomains in der Verwaltungsoberfläche fest und gebe an, auf welchen Ordner meines Webspace sie zeigen soll. Dort kann ich auch Datenbanken erzeugen, für eine Testkopie der Produktionsdatenbank beispielsweise.

Sag jetzt nicht, euer Webauftritt kann nur eine Datenbank. Dann wären wir doch wieder bei der Hobbyklitsche und nicht bei professionellem Umfeld. Ein größeres Hostingpaket ist nicht so viel teurer, und die zusätzliche Sicherheit einer vollständigen Testinstanz ist unbezahlbar.

Rolf