Drupal-Umgebung: best practice
am 19.12.2011 - 22:28 Uhr in
Hey!
Ich hab eine etwas komische Frage, es geht eher um den Plan einer guter Drupal-Umgebung.
Ich plane in naher Zukunft einige Projekte mit drupal umzusetzen, und möchte mir dafür eine möglichst gute Umgebung einrichten. Ich würd mich freuen, wenn ihr mir helfen, und eure Erfahrung teilen könnt.
Folgendes steht mir zur Verfügung:
- Ein Live-Server (VPS), nur für Drupal-Projekte
- Ein Development Server, incl. private git-repo-Server
- Lokaler Rechner
Ich stelle mir so eine Struktur vor:
- Es gibt eine Drupal-Installation, mit vielen Seiten (auf dem Live-Server), die per vhost unterschieden werden. Allgemeine Module können so von allen Seiten benutzt werden, private Module eben nur von einer Seite.
- Dann gibt es eine 1:1 Kopie dieser Seite am dev-Server, um Modul-Änderungen, u.s.w. zu testen.
Im Grunde würde ich gerne so einen Workflow erreichen:
Lokal entwickle ich / erweitere ich ein Modul, das ich mit Git verwalte. Dieses Modul wird dann nach eingehendem Offline-testen gepusht.
So weit so gut. Bis hierhin kann ich mir noch vorstellen, dass alles klappen würde :-)
Jetzt würde ich mit Capistrano (oder ähnlichem) mein Modul auf den dev-Server deployen, um dort dann mit einer Kopie der Live-Daten nochmal die Funktion zu testen bzw. zu überprüfen.
Ist das so eine ratsame Lösung?
Für das Live-System würde ich extrem gerne den eingebauten Updater verwenden, damit vielleicht auch nicht nur ich, sondern auch die Kund_innen direkt einzelne Module updaten können. Das Problem, vor dem ich dabei allerdings stehe ist, dass ich nicht nur OpenSource-Module verwenden kann, sondern manche Eigenentwicklungen ClosedSource sind, und somit nicht über drupal.org verwaltet werden können.
Lange Rede, kurzer Sinn. Meine Fragen sind:
- Ist es ratsam nur eine Drupal-Installation für mehrere Drupal-Seiten zu verwenden (Performance, Updates, ...)?
- Ist eine Entwicklungsumgebung so wie angegeben ratsam? Gibt es da bessere Alternativen / Ideen?
- Kann ich das Live-System irgendwie auch mit ClosedSource-Modulen updaten?
Vielen Dank fürs Lesen, ich bin schon auf Antworten gespannt.
lg.
- Anmelden oder Registrieren um Kommentare zu schreiben
hi killerpoke Zitat: Ist
am 20.12.2011 - 10:14 Uhr
hi killerpoke
Ist eine Entwicklungsumgebung so wie angegeben ratsam? Gibt es da bessere Alternativen / Ideen?
ja so (ähnlich) mache ich das auch
lokal = ich
testserver = team
liveserver
das dann mit git verwalten.
alles super.
problem dabei ja die datenbasis.
das muss dann über einen dump laufen
(auch wenn nur auf die 'inhalts' tabellen angelegt )
ist bekanntermassen ein bei versionierungen
mensch kann on das in drupal teilweise umgehen (zumindest von den daten struktur her)
unter verwendung von
http://drupal.org/project/features
damit kannst du zb contenttypen, views etc als code
exportieren und wieder importieren
das läßt sich dann auch gut versionieren (da ja source code und kein sql)
aber den datenbestand wie gesagt lässt sich nicht so einfach versionieren
Ist es ratsam nur eine Drupal-Installation für mehrere Drupal-Seiten zu verwenden (Performance, Updates, ...)?
ja besser als viele einzelne
das mit der performance ist ja dann drupal spezifisch und handlebar (caching etc)
Kann ich das Live-System irgendwie auch mit ClosedSource-Modulen updaten?
da verstehe ich nicht so genau was du meinst...
Capistrano kenne ich nicht, ich benutze netbeans das ist open source :)
besten gruss
stef
hey stef! Danke für deine
am 20.12.2011 - 11:17 Uhr
hey stef!
Danke für deine Anregungen.
Zu meinem ClousedSource-Ding: Die on-board-update-funktion des Drupal-Cores bietet ja die möglichkeit, Module upzudaten. Dabei wird mit dem drupal.org-Server kommuniziert, und die dort liegenden (opensource)-Module geladen. Gibt es da eine Alternative für ClosedSource-Module?
Capistrano ist ein Deployment-Tool, Ich kenn es eigentlich von Ruby on Rails, funktioniert aber auch mit drupal.
https://github.com/capistrano/capistrano/wiki/
lg.
killerpoke
huhu was meinst du
am 20.12.2011 - 14:32 Uhr
huhu
was meinst du mit
Gibt es da eine Alternative für ClosedSource-Module
du willst ClosedSource-Module in drupal einbinden?
bzw eingebundene über den updateprozess von drupal verwalten?
welche ClosedSource-Module gibt es denn?
gibts die üeberhaupt??
Naja ich kann leider nicht
am 20.12.2011 - 15:46 Uhr
Naja ich kann leider nicht alle selbstentwickelten Module frei zur Verfügung stellen, manche von denen müssen leider ClosedSource bleiben.
killerpoke schrieb Naja ich
am 21.12.2011 - 11:05 Uhr
Naja ich kann leider nicht alle selbstentwickelten Module frei zur Verfügung stellen, manche von denen müssen leider ClosedSource bleiben.
Du könntest diese auch als Features entwickeln - das Update würde dann über einen Feature Server laufen.
Müsstest noch schauen, ob du den Feature Server entsprechend absichern kannst, um deine Eigenentwicklung zu "schützen"..
Weitere Infos:
http://developmentseed.org/blog/2009/jun/24/distributed-feature-servers-...
http://drupal.org/project/features
http://drupal.org/project/fserver
SteffenR
http://www.twitter.com/_steffenr
Drupal-Initiative e.V.