phpStorm / mehrere Repositories / mehrere Entwickler / idea-Ordner

Deutsches Forum
1

Als Team (Programmierer, Templater) suchen wir noch nach optimalen Arbeitsweisen und Grund-Einstellungen unserer PHPStorm-IDEs. Im Moment leidet unsere Produktivität an dem Wildwuchs aus verschiedenen Ansätzen. Darum hier die Frage nach den Best Practice im Zusammenhang mit der PhpStorm-IDE

1) Wo arbeiten?

Wir haben einen zentralen internen Linux-Develop-Server. Der ist nicht der Schnellste. Die Arbeitsrechner sind schnelle Windows-Rechner. Der Linux-Server ist zusätzlich mit einer Sambafreigabe als Windows-Laufwerk bei allen Mitarbeitern eingebunden.

Alle Mitarbeiter haben den Shop auf dem internen Linux-Develop-Server per SSH installiert.

Einige haben Ihre IDE so eingerichtet, das sie direkt auf der langsamen Samba-Freigabe arbeiten. Andere arbeiten lieber auf Ihrem lokalen SSD-Laufwerk.

Um die Dateien initial auf Ihr SSD-Laufwerk zu bekommen, haben einige vom Develop-Server zuerst 1:1 synchronisiert. Andere haben ein PHP+Composer auf Windows installiert, um dort eine zweite “Datei”-Installation der Shops zu haben, also ohne DB und lauffähige Installation. Anschließend haben sie dann in phpStorm ein Permanent-Deployment auf den Develop-Server eingerichtet und lassen so Ihr System zwischen SSD und Linux-Develop-Server synchron.

Die SSD-Fraktion profitiert natürlich von der schnellen SSD.

Wie und wo arbeitet Ihr?

2) Repositories

Alle betrachten mit Ihrem phpStorm Ihre Shopinstallation (sei es direkt auf dem Linux-Dev-Server oder auf der SSD) als ein phpStorm-Projekt. Und alle sind nun mit dem Problem konfrontiert mit mehr als einem GIT-Repository (Shop-Repo, Template-Repo, mindestens 1 Modul-Repo) in dem Projekt zu arbeiten.

phpStorm fühlt sich zuerst für das “unwichtigste” GIT-Shop-Repo verantwortlich. Dort haben wir ja faktisch nur die composer.json und die composer.lock der Shop Installation drin. vendor und source sind in der .gitignore ausgeklammert.

Durch die Shop-Installation sind unter “vendor” auch die Repositories der Module und des Templates angelegt worden.

Unser Modulentwickler würde gern direkt im vendor-Ordner arbeiten und dann live bei Anpassungen sich das Modul in Shop-Modulverzeichnis synchronisieren lassen und fragt nun, wie er die Syncs (auch mehrerer Module gleichzeitig) sinnvoll und automatisiert in phpStorm eingerichtet bekommt.

Nun hat er die Anpassungen in seinem vendor-Modul drin und will phpStorm dazu bekommen die dort enthaltene composer.json als weiteres GIT-Repo einzubinden. Im Moment sieht das GIT im phpStorm seine Anpassungen nicht, da der vendor-Ordner insgesamt ja durch das Hauptprojekt ignoriert wird.

Und auch hier braucht er am liebsten wieder eine Lösung für mehrere Module (die einander bedingen) gleichzeitig. Im Moment löst er das je Modul mit einer GIT-Kommandozeilen-Orgie, die aber irgendwie sinnlos wirkt, wenn man mit einer großen IDE arbeitet.

Der Theme-Entwickler hat neben dem oben genannten Problem noch ein weiteres Problem. In seinem Vendor hat er npm installiert. Sein Grunt-Build-Prozess ist so eingerichtet, das er erst einmal die fertigen Resourcen im vendor-Modul ablegt, damit sein Theme-Repo vollständig ist. Ein weiterer Grunt-Build-Prozess legt die Resourcen direkt im out-Ordner des Develop-Shops ab.

Aber ihm fehlen automatische Syncs die ihm die Inhalte des de-, en- und tpl- vendor-Ordners in seine Develop-Installation bringen. Hier passiert im Moment auch noch zu viel Handarbeit.

Wie löst Ihr das Problem?

3) Idea-Ordner

PhpStorm legt in die Root seiner Projekte einen .idea-Ordner ab. Dort sind sehr nützliche Informationen für PhpStorm drin (u.a. Pfade, Zugänge usw.). Zu Beginn haben wir die mit in das GIT-Repo rein genommen. Dann aber festgestellt, das die Dateien bei jedem Mitarbeiter sich permanent ändern und wir uns jedes mal mit den Änderungen auseinandersetzen müssen.

Was macht Ihr mit dem Ordner? Checkt Ihr den ein? Nutzt Ihr evtl. nur Teile im Repo?

2

Moin, ich bin zwar nur eine Oneman Firma arbeite auch mit PhpStorm und lokal auf einer SSL Festplatte.

Seit ich Laragon als lokalem Server für mich entdeckt habe, funktioniert das auch reibungslos und sehr schnell. So schnell habe ich noch nie lokal einen OXID Shop installiert!

Steffen Winde

3

@windes: Mir geht es nicht primär um die Basis (WAMP, LAMP, Laragon, Dev-Server), sondern wie Du Dein phpStorm auf diese Basis aufsetzt. Also wie gehst Du mit Deinem phpStorm in Deiner Laragon-Umgebung um. Wie managst und arbeitest Du effektiv in Deinen Modul- und Theme-Reposities.

4

Hallo Mario,

ich bin mir bewusst, das ich sich nur 20% von dem benutze was PhpStorm kann! Ich benutze für jede Installation in Laragon ein Projekt.

5

Das .idea-Verzeichnis sollte nicht in git sein, weil jeder Entwickler i.d.R. etwas andere Einstellungen verwendet.

Ich arbeite mit lokalen vagrant-Maschinen, auf deren Dateien ich über einen Samba-Mount mit PhpStorm zugreife. Das geht auf meiner Maschine (i9900, 32GB, SSD) mit oft 4-5 gleichzeitig laufenden VMs völlig problemlos.

Mit einem einfachen shell-Provisioning kann ich für ein neues Projekt schnell eine neue VM konfigurieren.

Jeglicher Dateiaustausch erfolgt über das zentrale git-Repository. Mit git push schiebt man seine Änderungen in das zentrale git, mit git pull kann sich jeder Entwickler die Änderungen der anderen reinziehen. Sollte es Konflikte geben, sieht man die sofort klar und deutlich.

Den zentralen Server würde ich nur als git-Repository und für die Test-Instanz des Shops verwenden. Auf keinen Fall würde ich via Samba auf die Dateien dieses Servers zugreifen, weil sich Änderungen mehrerer Entwickler überschneiden könnten, ohne daß man es klar sieht, und auch wegen der Performance.

Mit git arbeite ich lieber auf der Commandline als in PhpStorm. Ich finde das wesentlich einfacher und transparenter. Das ist natürlich Geschmackssache.

Das Deployment in die Test-Instanz sollte einer einzigen Person zugewiesen werden. Die Entwickler sollten dort keine Änderungen machen. Alternativ könnte mabn natürlich einen automatischen Build-Prozess einrichten.

just my 2 cents…

6

Noch einmal zum Verständnis:

Also Du hast Deinen/Ihr habt Euren kompletten Shop nach der Installation in einem großen gemeinsamen git-Repo? Also so wie früher mit OXID4? Und mit allen Vendor-Bibliotheken?

Gut das löst das “mehrere GIT-Repositories”-phpStorm-Problem während der Arbeit. Aber dann hat man einen nachgelagertes Problem, wenn ich die fertigen Module und das Child-Theme wieder publizieren will. Oder richtest Du für das Child-Theme und das Projekt-Modul keine Extra Repos ein? Das würde ich mir bei immer wiederkehrenden Modulen schwierig vorstellen. Ich empfand es schon als eine Befreiung, die Module nicht mehr zusammen im Shop-Repository haben zu müssen wie bei OXID4.

7

Ich habe bis jetzt noch den kompletten OXID6 in einem einzigen git-Repo ohne das vendor-Verzeichnis, weil das ja vom Composer verwaltet wird.

Ich werde das aber auch so ändern (müssen), daß Module und Themes in einem eigenen git-Repo liegen. Mit git submodules sollte das funktionieren. Wie gesagt, ich arbeite mit git auf der Commandline, nicht aus PhpStorm.

Eine fertige Lösung habe ich aber noch nicht.

8

wo arbeiten:
ich hatte eine Zeit lang eine Workstation mit genügend Power, da hatte ich einige Hyper-V Systeme drauf. Docker würde sich dafür auch gut eignen.
Jetzt habe ich ein Laptop und nach 4 Chrome Tabs ist der RAM voll, deswegen habe ich immer Dev-Shops auf dem jeweiligen Server. Das erspart mir die entsprechende Einrichtung des Systems inkl PHP Versionen etc. Für Sync habe ich lokal git scm, das ist eigentlich unverzichtbar.

repos:
oxid6 vendor Ordner kann man eigentlich weglassen, wenn man dafür composer.lock mitnimmt. Darüber kann man den Stand exakt wiederherstellen. Und an den Vendor Bibliotheken sollte man sowieso keine Änderungen machen.

Ich mache es generell so, dass nur das nötigste in die Repository kommt. D.h. keine Produktbilder, Banner, PDFs aus dem Export Ordner etc. (wir haben hier aber auch schon mal 60gb Produktbilder :smiley: )
Bei lokalen Dev-Shops kann man dann den live Shop als externen Bilderserver eintragen, damit es nicht so leer aussieht.

Module sind mit Composer jetzt ein kompliziertes Thema geworden, da habe ich selber noch keine Ahnung, wie ich das machen werde.

9

Wir sind inzwischen wieder ein gutes Stück weiter.

Hier ein paar Tipps fürs Templateing (also noch nicht für Module ;):

Wir sind beim Ansatz geblieben, das wir direkt im vendor arbeiten. Unser Shop-Repository besteht ja nur aus der composer.json und der composer.lock. vendor und source stehen in der .gitignore.
Im Vendor-Verzeichnis haben wir das theme-Repository als weitere “Resource Root” definiert (File > Settings > Directories) und das GIT-Repository im Projekt als zweites Repository eingebunden (File > Settings > Version Control > “+” …). Sobald wir jetzt im Theme arbeiten erkennt phpStorm, das die Anpassungen auch zu dem Theme-Repository gehören und nicht in das Shop-Repository. Das war unsere erste Hürde.

npm ließ sich im vendor auch problemlos installieren. Wir hatten schon vorher unsere Grunt-Tasks etwas aufgebohrt. Wir lassen den Watcher und allen anderen Tasks weiterhin direkt in das Theme-Repository schreiben. Wir haben uns aber einen weiteren Sync-Task angelegt, der nichts anderes macht als die fertig erstellten Resourcen permanent aus dem Repository in den source-Ordner zu kopieren. So bedienen wir ordnungsgemäß das Repository und bekommen gleichzeitig frische Resourcen.

Am Ende des Tages können wir final den Production-Task starten und alles einchecken. Am Folgetag können sich alle anderen Beteiligten den aktuellen Stand per composer holen.

10

Der Ansatz direkt im Vendor zu arbeiten ist doch nicht zu empfehlen. Denn durch ein composer update wird der vendor ordner richtigerweise komplett gelöscht. Dadurch verliert Ihr die node-Installation.
Unsere jetztige Lösung sieht vor, unsere eigenen Module ausserhalb der Shop-Installation zu halten und sie als weitere content-root in phpStorm einzubinden (File > Settings > Directories > Add Content Root)

Ein npm-watch-task compiliiert nun die erstellten resourcen in das theme-repository, ein weiterer npm-watch-task kopiert die resourcen von dort in den Shop-Pfad.

Am Abend pushen wir das theme-repository und mit einem composer update bekommt der shop eine frische theme-Installation. Alle während des Tages temporär dort hin kopierten Dateien werden dann überschrieben.

11

ich arbeite auf einer lokalen linux vm, auf dem mehrere shops parallel laufem als eigene vhosts. shop1.localhost shop2.localhost etc. ich habe vendor und source mit im repro, da auf den systemen wo es letzendlich läuft nicht unbedingt der composer vorhanden ist. so kann ich das zur Not auch per FTP irgendwohin laden und fertig. bei modulen unterscheide ich zwischen eigenen kundenspezifischen modulen, die lege ich direkt mit ins kunden repro. module die bei mehreren kunden installiert sind entwickle ich in einem eigenen shop, bei dem nur source/modules/meinkuerzel ein repro ist. aus diesem repro erzeuge ich dann automatisiert zips die ich dann per composer und eigenem repro bei allen kunden, die diese module brauchen installiere. somit weiss ich immer welcher kunde welche version hatte. module von drittanbietern packe ich auch ins kundenrepro. im vendor Verzeichniss arbeitet man nicht, das wird vom composer verwaltet. Bilder und Median Dateien hab ich auch nicht im Repro.
Bei einigen Kunden haben wir dann ein automatisiertes Deployment in eine Testing Umgebung, hier wird dann nur das komplette Git Repro ausgecheckt. So hat man immer einen Stand zum herzeigen.

12

@Jb123: Danke!

Vendor ist wie gesagt nach dem einen Versuch bei uns auch tabu. Aber kannst Du noch etwas zu Euren/Deinen Automatisierungen schreiben?

Mit den Modul-Versionen der mehrfach verwendeten Module bei Kunden, löse ich das wie OXID mit Versionnummern in den git-Tags. So kann ich gezielt die Version in die zentrale composer.json des Kundenprojektes eintragen (bzw. sehen, welche ich dort nutze).

13

Zips erzeugen:
Bash Script + https://github.com/composer/satis

Deployment: Hier wird geprüft, ob sich was im Repro geändert hat, danach wird ausgecheckt und tmp geleert. Ausserdem wird eine Nachricht an einen Slack Channel gepostet.