tine podcast: 29 – Development-Setup

[pschuele]

https://www.tine-groupware.de/podcast/29-development-setup/

tine ist für einige auch ein DIY-Projekt. In dieser Episode gibt Philipp Schüle ein paar Tipps, was man braucht, wenn man selber mal an tine etwas mitentwickeln möchte und wie ein Development-Setup aussehen kann. An dieser Stelle darf natürlich der Aufruf nicht fehlen: Macht mit!

[lab-at-nohl]

Ich habe vielleicht nicht alles richtig gemacht. Hatte aber ein Problem, weil nicht alles in Containern kommt. Eigentlich braucht man auf dem Host zumindest PHP und composer, was es mir schwierig machte. Meine Überlegung war nämlich ein kleines Linux mit VirtualBox starten und dann darin die Container - war zwar klar getrennt aber halt nicht der richtige Weg ;-) Man lernt dazu.

Die Anwendung console konnte ich nie richtig benutzen, dafür braucht man - nach meinem Verständnis - das richtige PHP auf dem Host. Mir wäre eine Sammlung mit bash-Skripten daher lieber gewesen. Ich nutze meist podman, da läuft eh alles als Skript (gibt zwar auch podman-compose aber dann kann ich ja gleich docker benutzen).

Ich weiß jetzt, dass ein composer beim Webpack-Container dabei ist; das machte die Orientierung jedoch gleich schwerer, da man den ja eher mit der UI bzw. npm in Verbindung bringt. Aber es geht...

Ich werde Eurem System gerne nochmal eine Chance geben, bin gespannt auf den LDAP-Container. Brauche dafür aber ein Zeitfenster.
Und ich höre natürlich immer euren Podcast. Sehr interessant.

VG

[pschuele]

danke für dein feedback.

ja, wir haben uns für (symfony-)console entschieden, da wir sowieso mit php unterwegs sind und dmit erfahrung sammeln wollten. ggf. stellen wir die tine-cli auch irgendwann auf console um... einen abhängigkeits-tod muss man wohl sterben 😉
bash-skripte finde ich zumindest recht unhandlich...

[lab-at-nohl]

Ich hoffe, du hast das nicht als Kritik verstanden. Es sollte nur meine Herausforderung illustrieren... Ich sterbe immer einen Tod. Im Fall von Tine auch gerne, bin ja neugierig.

Um es etwas präziser zu formulieren: Meine Erwartung wäre gewesen, dass es für den CLI-Komfort einen "orchestrator"-Container gibt, in den ich mich via docker exec -v /home/johannes/tine-dev:/usr/src/tine -v /var/run/docker.sock:/var/run/docker.sock -it /usr/src/tine/tools/console dazu schalte. Dort ist das richtige PHP mit allem was man braucht (composer, git und ggf. npm), um am Source-Code zu arbeiten und auch, um weitere Container - gerne mittels console - zu starten (deshalb der Zugriff auf den socket). Ist aber alles Luxus, hätte jetzt keine Priorität.

Welches Tool verwendet ihr eigentlich um das Log-File mitzulesen? tail -f oder habt ihr was, z.B. um parallele Anfrage auszublenden o.ä.?

[pschuele]

ja, das mit dem orchestrator-container nehme ich mal mit in unser dev-setup meeting. wäre eine feine sache, das noch einfacher zu machen (nach dem motto "git clone && docker up").

Welches Tool verwendet ihr eigentlich um das Log-File mitzulesen? tail -f oder habt ihr was, z.B. um parallele Anfrage auszublenden o.ä.?

es ist tatsächlich noch oft "tail -f". hier hilft dann die "request id", um nur einen bestimmten request mitzulesen. bei einer größeren installation haben wir elk im einsatz (mit einem json logger).

weitere infos zum logging findest du in den docs: https://tine-docu.s3web.rz1.metaways.net/operators/Logging/ bzw. https://tine-docu.s3web.rz1.metaways.net/operators/docker/DOCKER-LOGS/