GIT mit OXID-Shops

Deutsches Forum
1

Morgen liebe Leute,

ich hab eine Frage auf die ich aktuell leider keine Lösung finde, daher wollte ich mal fragen, wie ihr das handhabt:

Aktuell versionieren wir mittels SVN sämtliche Shops (zur Nachverfolgung, falls Kunden etwas falsch gemacht haben, zur Entwicklung neuer Features und natürlich für Tests).

Jetzt switchen wir gerade auf eine GIT-lösung (gitlab).

Allerdings fällt es mir schwer, einen Ansatz zu finden, wie man das am sinnvollsten handhabt.

Sollte der gesamte Shop (inkl. Core) versioniert werden? Macht es sinn, den “core” aus einem anderem Repo zu ziehen und nur seinen Theme zu versionieren? Wie geht ihr mit Datenbanken um? Teilweise sind die Einträge in der DB ja essentiell um eine korrekte Darstellung zu gewährleisten (blocks etc…).

Folgendes Szenario:

Kunde A hat einen Shop auf seinem Server. (noch nicht unter Versionskontrolle).
Er möchte nun eine neue Extension haben.
Wir laden also via FTP einmal den gesamten Shop runter, legen ein neues Repo an und versionieren alle Dateien. Änderungen und neue Entwicklungen werden dann lokal entwickelt. Nach fertigstellung wird also commit + push durchgeführt. Damit ist die “neue Version” im Repo.

Nachdem also Tests abgeschlossen sind, soll dieser Stand auf einen Testserver ausgecheckt werden. Es wird also von diesem Repo ein checkout vorgenommen und die Dateien landen auf dem Testsystem (inkl. config-datei etc…) [<-- schonmal suboptimal]. Der Kunde überzeugt sich also jetzt und empfindet es für gut und sagt “jo, bitte live stellen”.

In der Zwischenzeit sind natürlich weitere Bestellungen (oder Übersetzungen) an der Live-Seite vorgenommen wurden. Ergo könnte ein Checkout da nicht stattfinden, ohne “seine” Änderungen zu überschreiben (vorausgesetzt, man versioniert die lang-files nicht). Gleiches gilt für die DB. Wir können keinen dump unserer DB erzeugen und auf den Live-server knallen, da wir seine Änderungen + Daten damit ja vernichten wrüden (Fatal bei Bestellungen…).

Danke für sämtliche Hinweise.

Frage also: Macht es nur sinn, ein Repo für einen Kunden anzulegen und dort die eigenentwicklungen (extensions, template…) zu versionieren?

2

Hi,
ich versioniere den ganzen Shop inkl core in git, da ich core hacks nicht ausschließen kann :wink:
Ist auch praktisch bei shop updates.

Datenbank versioniere ich nicht, da sehe ich noch Bedarf.
Da müssen zZt noch manuelle Migrations reichen.
Ist auch schwierig, wie du schon bemerkt hast, weil, die DB sich ja dauert ändert, zumindest von den Inhalten her.

Für den deploy benutze ich build scripte via gulp, die je nach dem live & stage configs kopieren, themes & assets bauen und den ganzen shop via rsync oder ftp syncen.
Da mache ich kein git-deploy.

Kunden die auch am Shop rumbauen, würde ich auch auf git “zwingen”, damit man eine “source of truth” hat.

3

Ich arbeite auch mit git und benutze zum Deployment das Tool “rocketeer”.

Mit rocketeer kannst du auf verschiedene Zielserver deployen (staging,production etc.). Config-Dateien usw. werden einmalig in einem shared-Ordner abgelegt und bleiben zwischen Deployments erhalten. Beim Deployment bleibt die aktuelle Installation bestehen und es wird aus dem festgelegten Branch in git eine komplett neue erstellt und mit symlinks eingehängt, so daß man im Notfall mit einem Kommando auf die vorherige Version zurückstellen kann. Also stressfreies Deployment.

Nach etwas Fummelei mit dem Setup läuft das nun seit ein paar Monaten reibungslos. Die Zeitersparnis und der Gewinn an Betriebssicherheit sind enorm.

(Ich weiß, klingt wie Werbung, aber das rocketeer ist open source, da gibts nix zu verdienen - ich finde das Ding einfach nur genial :slight_smile: )

4

@m431342 verwendest du noch Rocketeer? Hab mir das mal angesehen, gefällt mir gut aber wird anscheinend kaum noch weiterentwickelt.

5

Ja, ich benutze das nach wie vor. Der Deployment-Prozess ist sehr stabil, da ändert sich so gut wie nie etwas, deshalb braucht das Tool m.E. auch nicht viele Updates.

6

OK danke, bin nur gleich beim Testen an diesem Bug hängengeblieben: https://github.com/rocketeers/rocketeer/issues/755, es schaut irgendwie nicht so aus als ob das nochmal gefixt wird und da dachte ich vielleicht gibt’s ja mittlerweile eine Alternative.

7

Ich kenne dem Namen nach (selbst keine Erfahrung) noch Deployer:

1 Like
8

Vielen Dank, schau ich mir auch mal an!