Von der Beta-Phase in die Production
![](http://www.drupalcenter.de/files/noavatar_mini.gif)
am 22.07.2009 - 13:54 Uhr in
Ich habe u.a. eine DB für beta und eine für Produktion. Auf dem Server habe ich mir auch entsprechend Ordner angelegt und auch entsprechend subdomains. Nun aktuell zeigt die beta.domain.de auf dem ftp-Server auf den Ordner ..\beta\.
Nun möchte man ja mal von der Beta in die Produktion switchen.
Dazu kann ich dann die kompletten Files aus "beta" einfach in den ordner "production", so dass auch production.domain.de bedient wird. Mein Verständnisproblem liegt nun in den Datenbanken. Wenn ich einfach die DB "production" durch "beta" tausche (also struktur und content) dann ist dies totaler unsinn. Die Daten aus der Beta-Phase will ich aber auch nicht in der Produktion haben, sondern letztendlich die Produktion benutzen, die ich DBseitig schon habe. Nur hat diese DB Production Ebene noch nicht ein Update durchlaufen, wnen ich zum Beispiel ein Update von Drupal fahre.
Wie macht ihr so etwas?
Beispiel:
Ich hätte in Production aktuell Drupal 6.12 laufen und möchte auf Drupal 6.13 updaten. Meine Idee wäre es nun, über FTP den Ordner "..\beta\" mit den neuen Daten zu überschreiben. Danach führe ich ein Update.php durch. Das Update der Datenbank erfolgt ja in meiner DB "beta". Dann würde ich über beta.domain.de die Sachen testen und Testdaten anlegen. Irgendwann kommt der Punkt, da möchte ich den Switch durchführen. Ich dachte mir, ich schalte in den Wartungsmodus. Danach nehme ich die Update-Dateien und spiele Sie per FTP in den Ordner "..\production\". Dann fahre ich ein Update.php. Nach meinem Verständnis müsste dies dann auf der DB Production laufen. Daten würde ich ja somit nicht rüberziehen.
Wäre das so in Ordnung? Ich müsste doch dann immer nur in meinen FTP-Umgebungen die entsprechenden Settings für die DB in der settings.php vornehmen. Oder wie würdet ihr es machen.
Ich versuche mit da gerade hineinzudenken. Denn ich habe vier Umgebungen (je FTP, Subdomain und Datenban:
- Develop
- Beta
- Production
- Backup
Die Backup-Umgebung soll vor dem Switch von Beta auf Production gefüllt werden. Die DB-Daten + Struktur soll gelöscht werden und per Script durch die von Production befüllt werden. Per FTP elbiges. Und per Domain kann man dann über das Backup auch auf die Production gehen. Dann switche ich um, wie oben beschrieben, und habe die neue Umgebung unter "Production".
- Anmelden oder Registrieren um Kommentare zu schreiben
Hallo, das Thema
am 22.07.2009 - 16:01 Uhr
Hallo,
das Thema interessiert mich zur Zeit auch brennend und es wäre toll zu erfahren, wie andere das managen...
Viele Grüße,
Tobias
Präsentiert voller Stolz sein erstes Drupal-Projekt: http://www.diaet-clique.de
Man nehme zwei Systeme (dev,
am 22.07.2009 - 16:06 Uhr
Man nehme zwei Systeme (dev, live) und trenne sie so gut es geht (kein Verzeihniswirrwarr innerhalb eines Webs und solche Scherze).
Dann entwickelt man im dev, während das live normal läuft. Änderungen am Code (Upgrades, Theming, Module) dokumentiert man. Beim Switch nimmt man das Live-System offline, führt Upgrades durch, vollzieht die gemachten übrigen Schritte nach, testet durch und knipst das System dann wieder online. Das geupdatete Live-System kopiert man dann inkl. Datenbank und benutzt es als neues Dev-System, so hat man halbwegs aktuelle Echtdaten im Testsystem.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
ok, also so wie ich
am 22.07.2009 - 17:55 Uhr
ok, also so wie ich beschrieben habe oder magst du meine Ordnerstruktur nicht :)?
Alexander Langer
am 30.07.2009 - 07:00 Uhr
Man nehme zwei Systeme (dev, live) und trenne sie so gut es geht (kein Verzeihniswirrwarr innerhalb eines Webs und solche Scherze).
Dann entwickelt man im dev, während das live normal läuft. Änderungen am Code (Upgrades, Theming, Module) dokumentiert man. Beim Switch nimmt man das Live-System offline, führt Upgrades durch, vollzieht die gemachten übrigen Schritte nach, testet durch und knipst das System dann wieder online. Das geupdatete Live-System kopiert man dann inkl. Datenbank und benutzt es als neues Dev-System, so hat man halbwegs aktuelle Echtdaten im Testsystem.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Für die gemachten Änderungen empfiehlt sich http://drupal.org/project/journal sehr. Damit kann man direkt in Drupal die Änderungen mitloggen die man macht.
PS: Für die Experimentalisten unter uns: Context, Spaces und Features.
Damit kann man den ganzen Kram von Views, CCK, Panels(bin mir da nicht sicher), Blöcke, {variables} usw. so konfigurieren, dass man sie später in ein Modul exportieren kann. Hat man seine Veränderung an einem Feature fertig, kann man einfach das neue Modul auf den Live Server spielen, caches leeren usw. und es hat sich verändert.
--------------
Blog www.freeblogger.org: Deutscher IRC-Channel: irc.freenode.net #drupal.de ... Jabber-me: dwehner@im.calug.de
SirFiChi ist auch dein Halbgott.
Beta Version
am 30.07.2009 - 08:55 Uhr
Wenn Du Beta und Produktion mischt, machst Du es Dir besonders schwer bei Update oder ähnlichen Problemen.
Warum packst Du die Beta nicht in ein Unterverzeichnis. Dann hast Du eine Kopie Deines Originals und kannst immer neue Module und Updates testen, bevor Du Sie in der Produktion benutzt. Notfalls kannst Du hier dann auch ein Backup wiederaufspielen und Daten rekonstruieren.
Die Idee mit verschiedenen Datenbanken greift nicht richtig, da die Probleme auch in den Files liegen können.
Gruss
Katasun