ich will Webshops für Kunden entwickeln und finde bis jetzt diese Vorgehensweise gut:
Der Shop steht direkt im Internet, er wurde ohne Demodaten installiert und die Artikel etc. sind in der dortigen Datenbank.
Es gibt zwei Shop-Installationen lokal auf dem Rechner, eine mit und eine ohne Demodaten.
Ich schraube nun an einem von Azure abgeleiteten Theme fuer den Shop und wenn ich mit diesem lokal zufrieden bin, dann lade ich das Theme hoch. Generell ist es also ein oftmaliges Aktualisieren des MeinKundenThemeName-Ordners.
Macht ihr das auch so, oder hat meine Strategie Schwächen?
Da gibt es sicherlich die verschiedensten Vorgehensweisen.
Ich habe eine lokale Installation, die ich immer vor irgendwelchen Anpassungen auf den aktuellen produktiven Stand bringe. Hier arbeite ich am Template, an eventuellen Codeanpassungen und “übe” die Updates. Ist also meine Entwicklungsumgebung.
Dann habe ich noch eine Vorproduktionsumgebung, die sich auf dem Server innerhalb eines geschützten (auch vor Suchmaschinenzugriffen) Verzeichnisses befindet. Von der Entwicklungsumgebung wird also der letzte Stand immer erst auf die Vorproduktion gebracht. Hier kann ich ggf. Dritte auf meine Anpassungen schauen lassen und kann prüfen, ob die Anpassungen auch in der Server-Umgebung korrekt laufen.
Von der Vorproduktion bringe ich die Anpassungen nach ausführlichen Tests dann in den produktiven Shop.
Ich habe also eine lokale Entwicklungsumgebung, eine Vorproduktion auf dem Server und die produktive Umgebung.
Kompliziert? Vielleicht. Ich bin allerdings auch sehr vorsichtig ;).
lokale und Vorproduktion klingt gut vor der Liveversion und macht ja auch sinn. Ich bastel grad an einer liveversion rum und baue einen oxid auf. Die URL kenn ja noch keiner und wird dann irgendwann an die richtige stelle umgezogen. Von daher kann ich das live machen. Jedoch wird irgendwann der Moment kommen, an dem man ja den Shop kommuniziert und dann möchte ich gerade was das Ausbauen des Shops angeht nichts mehr am liveshop testen. (module, mobile etc.)
Wo befinden sich eure Vorversionen? www.xyzabcd.de (liveversion) www.vor.xyzabcd.de (vorversion) -also auf einer subdomain des liveservers?
Was das lokale betrifft, bin ich hier nur auf etwas ältere Posts gestossen. XAMPP und apache und und und. Das wäre alles neuland für mich.
Was ich habe ist eine domain bei DF, dann Software DW, Transmit, TextMate und arbeite lokal grundsätzlich auf Macsystemen und bislang nutze ich auch lediglich bootcamp für windowsanwendungen und keine Virtuelle Maschine.
Wie kann ich denn einen Oxidshop lokal sehen und bearbeiten? (ähnlich dreamweaver) ?
Ich weiss, es sind für den einen und/oder anderen teilweise recht dumme fragen dabei, aber ich würde mir gern erstmal recht grob einen Überblick bezüglich Logik und Aufbau/Zusammenhang von Lokal zu vorversion und lifeversion verschaffen und vor allem recht sinnvoll das ganze aufbauen (mit kleinen und leisen schritten) und möglichst viele Fehler vermeiden. Da werden ohnehin so einige ungeladene Gäste aufkreuzen
Also ich habe meistens eine Entwicklungsversion (stage) auf dem Server unter irgend einer Subdomain.
Am Stage direkt arbeite ich mir Dreamweaver, dort ist der Shop als Web angelegt und Optionen wie beim speichern hoch laden etc. sind an. So lässt sich relativ einfach und schnell arbeiten.
Wenn die Änderungen soweit stehen habe ich dort auch ein selbst gebautes Script das die Änderungen per rsync oder FTP dann in die Liveumgebung übernimmt (abzüglich Config und einiger Development Helper Module natürlich), im Live den TMP leert und alles ist gut. Das Script läuft ja lokal auf dem Server und ist daher sehr schnell, den Liveshop beeinflusst das nicht.
Für das erstellen der Stage Umgebung bzw. zum Deployment nutze ich ein single File PHP Script (Sputnik) das in der Lage ist mit zwei Klicks Shopkopien zu erstellen oder Neuinstallationen schnell und einfach durchzuführen. Bei Interesse kann ich das mal aufräumen und bereitstellen.
@ Hebsacker: zu spät, die 39 okken werden ja für irgendetwas gut sein und haben mich zwar nicht umgebracht und dennoch doof, wenn man sie hätte sparen können.
@ acpi: na klar hab ich interesse an allem, was einem die Arbeit ein wenig sinnvoll erleichtert oder abnimmt. so wie du das beschreibst, macht das ja richtig sinn. Dreamweaver hatte ich seit einem Jahr wieder beiseite gelegt und mich mal mit Aptana beschäftigt. Damals hatte Dreamweaver (weiss gar nicht mehr genau was) irgendwelche zeichen vertauscht, was dann zu fehlern führte. Aber dann werde ich mal DW wieder reaktivieren und auch die webeinstellungen vornehmen.
guter input hier!
Das MAMPP läuft bei mir auch gut und auch wenn ich grad bis donnerstag nur mit nem lappy unterwegs bin, wollte ich das dann auch mal gleich testen und oxid runterladen und installieren, nur gibts ja mittlerweile die 4.7.4. Auf dem Server ist ja die 4.7.3 installiert und da ich noch nicht weiss, was sich geändert hat, hab ich das erstmal gelassen und warte bis ich das getrost am Freitag zu hause testen kann.
So, wenn ich das richtig verstehe kreiert MAMPP eine Umgebung in der man lokal dann oxid installieren kann und testen kann und die einzelnen Templateseiten kann ich dann mit DW bearbeiten. Klingt so ganz schick, nur muss ich mal schauen, inwiefern da php versionen usw. eine rolle spielen. (ich glaub auf dem server läuft noch die 5.2.)
hier nochmal unser Vorgehen, vielleicht hilfts ja auch:
Wir haben grundsätzlich
Liveversion
Staging / Testsystem auf dem/den gleichen oder identisch konfigurierten Server/n
Entwicklungssystem lokal
Das Entwicklungssystemhaben wir inzwischen angefangen mit vagrant in einer VM zu bauen, so dass wir lokal möglichst einen ähnlichen Server haben (zumindest PHP-Version, MySQL, etc.)
Da wir alles mit Git versionieren deployen wir im Moment mit einem kleinen Script, was entsprechend die neueste Version ausrollt: https://github.com/jkrug/marmDeployment
Auf dem eCommerceCamp in Jena gab es eine schöne Session zum Thema Deployment. Fazit: Capistrano, eine Software auf Ruby-Basis ist wohl das gängiste und ausgereiteste Tool dafür. Das werden wir uns als nächstes anschauen, da es auch einen schnellen RollBack ermöglicht, indem mit SymLinks gearbeitet wird.
[QUOTE=jkrug;120715]
Auf dem eCommerceCamp in Jena gab es eine schöne Session zum Thema Deployment. Fazit: Capistrano, eine Software auf Ruby-Basis ist wohl das gängiste und ausgereiteste Tool dafür. Das werden wir uns als nächstes anschauen, da es auch einen schnellen RollBack ermöglicht, indem mit SymLinks gearbeitet wird.
[/QUOTE]
Wenn Du möchtest dann können wir Dir das bereitstellen und auch für die Updates bzw. das Deployment der Umgebung sorgen.
Das was Du brauchst ist mit einem HOST Server und drei VSERVERN auf dem Host einfach umsetzbar.
Wir für Dich managen:
das gesamte Deployment der Server (Betriebssystem inkl. Applikationen) mit einem Chef Server so könnten wir für Dich versch. Umgebungen managen z.B. wie
als Entwicklungsumgebung können wir Dir GitLab allein oder in Verbindung mit Redmine anbieten.
Capistrano, Jenkins etc.
wir können Dir auch UnitTest ermöglichen, die Du mit Jenkins automatisch steuerst und bei Fehlern den Code nicht zum Stage Server liefert. Du würdest dann vom System benachrichtigt und könntest den Code fixen.
Es geht bei einem anständigen Deployment auch nicht nur um Änderungen oder neue Dateien - auch Änderungen an der MySQL müssen sicher erfolgen - genau da trennt sich oft die Spreu vom Weizen.
Die gesamte Umgebung läuft auf Basis von gentoo Linux, nur dies gibt uns die nötige Freiheit eine anständige Umgebung zu realisieren und auf die neusten Techniken zuzugreifen. Das fertige Paket gefrickel mit den normalen Linux Distributionen ist wenig geeignet für eine zukunftsorientierte Entwicklungsumgebung.
[B]VM[/B]:
Aktuell testen wir auch eine VM mit VirtualBox auf Basis gentoo. Ein Entwickler kann die VM starten und dann mit CHEF ganz bequem seine gewünschte Umgebung deployen. Es fehlt aktuell noch die Einbindung des OXID Shops, den man sich dann auch immer in der aktuellsten Version von OXID ziehen kann.
PS: Mein Kollege ist auch im gentoo Core Team - es werden aktuell über 100 Server von namhaften Firmen individuell gemanagt.
wegen Anfragen per Mail und PN, wir realisieren eine Entwicklungsumgebung für Agenturen z.B. mit
HOST System
– Development VServer
– Stage VServer
– Live VServer
inkl. Installation des Betriebssystems gentoo Linux, GitLab. Redmine, Capistrano, Jenkins etc. (alles nötige nach Absprache)
für einen Preis zwischen 800 - 1500 Euro zzgl. UST.
Es muss z.B. geklärt werden welcher Webserver gewünscht ist, viele wollen den Nginx, andere den Apache2, dann gibt es auch die Option der Kombination aus beiden. Auch andere Entwicklerwerkzeuge sind möglich wie xDebug - aber das muss dann alles genau besprochen werden.
Die Entwicklungsumgebung kann im Web sein oder auch im Büro der Agentur - wir müssen nur zur Einrichtung und Wartung zugreifen können.
Die ständige Betreuung z.B. Update der Entwicklungsumgebung und der Betriebssysteme des HOST und der VServer übernehmen wir pro HOST Server für 100 Euro zzgl. UST im Monat.
Für diesen Preis muss sich kein Mitarbeiter der Agentur mit der Entwicklungsumgebung beschäftigen - die Zeit kann genutzt werden um Aufträge zu erfüllen.
PS: Ja wir machen mit Agenturen einen NDA, wir wollen keine Entwicklungen von deren Entwicklungsumgebungen ziehen
Timo - ganz im Ernst, wir sind hier doch keine Litfass-Säule. Nichts gegen ein wenig Werbung in eigener Sache, jeder darf gerne hin und wieder auf seine Services und Angebote hinweisen. “Hinweisen” - und nicht ständig rausposaunen!
Vorrangig sind wir hier ein Community-Forum, bieten Hilfen für Anfänger, tauschen Ansichten und Meinungen bezüglich der Shopsoftware aus und helfen auch bei fortgeschrittenen Problemchen mit dem einen oder anderen Snippet oder Best-Practise Info.
Ich bitte Dich also, in Zukunft die großen Werbeplakate stecken zu lassen, die Werbetrommel beiseite zu lassen.
Back To Topic:
Wie Ihr vielleicht wisst, hat OXID eShop eine der letzten zweiwöchentlichen Abstimmungen bei BitNami gewonnen. In Kürze wird OXID eShop also auch bei BitNami angeboten werden.
Vor dem Livegang wurden uns die Installer-Packs als Beta zum Testen zur Verfügung gestellt. Schaut sie Euch an und lasst uns Bugs, Hinweise und Anregungen wissen!
@ Hebsacker: Ich nehme an, dass Bitnami sowas ähnliches wie das eXchange ist? Wenn ja, kann man dann beides nutzen? Mich interessiert natürlich gerade die Thematik bezüglich des Threads hier, wie man efire bei einem stageserver einrichtet, wenn man nur einen efire zugang hat. einen 2. account möchte ich wegen den 50€ nicht registrieren.
Nein, BitNami ist ein Anbieter von Anwendungspaketen - als fertige Installer, mit wenigen Klicks installiert. Ausserdem bieten sie gehostete VirtualServer für verschiedenste Anwendungen mit One-Click-Installation, oder ein gehosteter Virtual Server in der Amazon Cloud.
Kennst Du XAMPP? Ist das gleiche Prinzip, ein Paket mit allen notwendigen Bestandteilen zum Betrieb einer bestimmten Anwendung. Im Falle von OXID gibts also einen Apache Webserver und einen MySQL Server inklusive dem Shop selbst, installierbar direkt lokal unter Windows oder Mac (zum Beispiel).
Eine eFire-Sandbox ist mir nicht bekannt - aber die 50 Euro bekommst Du bei Auflösung des Accounts ja auch wieder zurück (wenn Du sie nicht verbraucht hast).
ah! habs mal installiert und schon gesehen, dass dies meinem MAMPP entspricht. die automatische oxidinstallation und phpMyAdmin ist natürlich schön. Werde das mal weitertesten.
ich werde morgen den oxid auf dem liveserver und auf einer subdomain installieren. endlich nägel mit köpfen, hihi…
ich bin noch ein wenig verunsichert bezüglich php version, da muss ich nochmal schauen bezüglich paypal, cleverreach usw. oder gibt es eine bedenkenlose stabile version nach der 5.2.17?
also für das testen von modulen auf dem stage ist ein zweiter efire zugang notwendig… hmmm
hab da noch ein paar fragen bezüglich infrastruktur und vorgehen.
nun habe ich oxid 4.7.4 auf dem liveserver und dem stage installiert (manuell) und ebenso das 6vC als erstes Modul. Sonst bislang nur demodaten. oxchkversion lief bei beiden ohne problem durch. daher stellen sich mir ein paar fragen, da ich das system sicher und stabil halten möchte.
Beispiel:
ich teste manuell mal was (templateänderungen oder module) auf dem stagesystem. Wenn es funktioniert, stellt sich mir die Frage, welches vorgehen am meisten sinn macht…
kopiert ihr den shop (die änderungen) einfach über ftp auf den liveserver und die datenbank wird überschrieben (vorher ein replacebackup vom stage gesichert) oder macht ihr das dann auf dem liveserver auch manuell?
Du könntest eine Versionsverwaltung verwenden, z.B. SVN oder Git etc. So kannst du mit einem Befehl die Änderungen speicher, übernehmen lassen und auch rückgängig machen.
Oder sonst gibts im Internet genug Beispiele, Vorgehensweisen und Erklärungen zum Thema Deployment.
