Als ein Team mit verschiedenen Erfahrungen und Vorlieben war uns von Anfang an klar, dass ein jeder am liebsten auf "seinem" OS Arbeiten und leben möchte.
Wir hatten also die Wahl: Entweder ein einheitliches Setup schaffen, durch das für alle Beteiligten die Entwicklung identisch wird. Oder wir finden ein OS, mit dem alle gleichermaßen zufrieden sind. (bzw. auf das ein Teil des Teams einfach gezwungen wird.)
Wir entschieden uns dafür ein gemeinsames Setup zu nutzen, völlig unabhängig der persönlichen Vorlieben. Unser Anspruch sah vor den Zugang für alle Entwickler gleichermaßen zu vereinfachen, sodass keine Voraussetzungen an Erfahrungen und Skills gesetzt wurden.
Wir alle wussten von unseren vorherigen Stationen, wie divers Teams sein können und wie unterschiedlich jeder Entwickler arbeitet. Deshalb räumten wir der Thematik eine hohe Priorität ein und versuchten Einiges, um ein möglichst gutes und für uns Entwickler homogenes Ergebnis zu erhalten.
Aus der Unix-Welt nehmen wir einiges mit, theoretisch wäre auch Windows möglich. Aktuell nutzt keiner von uns dies zum Arbeiten. Vielleicht findet sich jemand mit Spaß am Ausprobieren? Man hört ja so einiges (Gutes) über WSL.
Als Pimcore-Agentur ist in jedem Projekt auf jeden Fall schon einmal das Backend weitestgehend definiert. Allerdings haben wir durch die Bandbreite an unterschiedlichen Projekten (alte, wie neue) auch mittlerweile eine ganze Reihe an verschiedenen Stacks beisammen.
Das Thema Frontend wird noch einen eigenen Artikel erhalten, aber soviel sei schon einmal gesagt: Unsere Frontends sind recht divers aufgestellt - immer ausgewählt nach den jeweiligen Kundenanforderungen.
Es gab im Prozess einige Probleme zu überwinden. Dabei definierten sie bei jeder internen Diskussion einen wichtigen Eckstein, der uns zeigte wo wir hin wollten bzw. was wir in der jeweiligen Situation vermeiden sollten.
Der Klassiker - ein Kunde oder Kollege bittet kurz einmal darum zur Unterstützung in ein Projekt zu schauen. Nicht ganz unbekannt ist, dass so etwas je nach Projekt schon einmal einen halben bis ganzen Tag dauern kann.
Unser eigener Anspruch war hier, dass wir nach dem Klonen des git repositorys innerhalb von 5-10 Minuten auch bereits arbeitsfähig sind.
Wie schon oben erwähnt, nutzen wir nicht alle die gleichen Systeme zum Arbeiten. Wichtig war uns hier nicht nur, dass alle Kollegen gleichermaßen arbeiten können, sondern auch, dass für alle die gleichen Regeln und Prozesse gelten. Das heißt in der Umsetzung, dass wir uns alle gegenseitig sehr stark unterstützen können. Auch dann, wenn der Mac-User keine Ahnung von Arch und vice versa hat.
Die Hürde mit unserem Setup zu arbeiten sollte für alle, unabhängig des persönlichen Erfahrungsschatzes, gleichermaßen niedrig sein. So kam es, dass alles Enwicklungsbezogene durch ein paar universelle Befehle vollziehbar ist.
Ein weiterer Klassiker - Entwickler können nur eine kleine Anzahl an Projekten gleichzeitig aufgesetzt haben und aktiv laufen lassen, da die Ressourcen der Maschinen nicht ausreichend sind.
Bei uns kann ein Backend-Entwickler lokal alle Projekte gleichzeitig laufen lassen und daran arbeiten, solange der RAM die vielen Instanzen der eigenen IDE überlebt. D.h. auf Deutsch: Ressourcenarmes Betreiben der eingesetzten Services.
Hier sind ein paar Beispiele, bevor wir uns in den Code begeben, die verdeutlichen sollen, wie einfach es für uns alle nun ist. Folgende Beispiele kommen quasi jeden Tag vor und gehen flott von der Hand. Fallen Euch hier noch weitere ein?
Kurz den link aus dem Repo suchen, klonen und fast fertig. Je nach Maschine kann der init etwas dauern, da hier auch direkt die Assets für das FE mit gebaut werden.
Wenn der (Mutagen) Sync noch "frisch" ist dauert es 5 Sekunden. Falls nicht, so können es 2 min sein.
Jeder Entwickler kennt es: Irgendetwas hat man gerade versucht und dann bekommt man das System / das Projekt nicht mehr gefixt. Nun könnte man stundenlang mit der Suche nach dem Fehler verbringen - oder einfach das zerlegte Projekt dezent beseitigen, neu aufsetzen und dort weitermachen, wo bis eben nichts funktionierte.
(wenn ganz schlimm: docker service neustarten: systemctl restart docker.service)
Auch wir gehen mal ins Bett und räumen hinter uns auf.
In der YAML wird ein ganzes Projekt für die lokale Entwicklung (backendseitig) komplett durch dekliniert. Neben den Standards, wie der Datenbank (maria), dem front-facing webserver (nginx) und dem Pimcore Container (php8.1-fpm) haben wir noch einen zweiten debug-container für die harten Fälle und optionale Komponenten. Aktuell setzen wir hier ein: redis, athena-pdf, elastic. Je nach Projektbedarf kann hier einfach hinzugefügt werden und tiefgreifender konfiguriert.
Wie schon erwähnt nutzen wir træfik für das Routing. Dies könnte in Zukunft noch ein eigener Artikel werden. Hier gibt es noch ein wenig zu beachten bei der Installation und Einrichtung.
Im letzten Teil definieren wir neben den Volumes und dem einen geteilten Netzwerk für træfik den Mutagen-sync. Das ist der eine Teil, welches es uns erlaubt komplett gleichartig auf allen Unix-oiden zu arbeiten. Ansonsten hatten (und hätten) wir Probleme mit der Docker-synchronisation auf dem Mac (auch nicht bei allen, wie es scheint).
Wie schon erwähnt ist das Makefile unser Arbeitspferd in der täglichen Entwicklung. Es nimmt gerade viele kleine (auf die Dauer sehr anstrengende) Themen ab und reduziert die Probleme miteinander.
So haben wir nur eine überschaubare Anzahl an Befehlen, welche alles backendseitige Aufzetzen und Warten entweder komplett abnehmen (für die FE'ler), oder zumindest stark vereinfachen für alle BE'ler.
Vielleicht fiel auf, dass wir eine gemeinsame Entwicklungsdatenbank haben, welche auch immer mit ins Repo eingechecked wird. Somit haben wir für alle nicht Admin, oder Backend-bezogenen auch direkt einen fertigen (funktionierenden) Stand mit Zugangsdaten und notwendigen Datenobjekten (Usern etc.).
Dies führt auch dazu, dass wir sehr schnell einen Stand löschen und komplett neu aufsetzen können, sollte man mal wieder (was ja mal vorkommt) seine Instanz komplett zerschossen haben.
Wir haben mit einigem Trial-and-Error eine Lösung gefunden, sodass alle unsere beteiligten Gewerke einfach und schnell miteinander, jeder an seinen Themen, arbeiten können. Weiter haben wir es geschafft uns zu öffnen für viele Möglichkeiten ohne potentielle neue Mitglieder unseres Teams einzuschränken.
Unser Onboarding wird damit massiv vereinfacht und verkürzt.
Einfach mal sprechen?
Mein Name ist Billy Thiemann, langjähriger Entwickler, Digitalisierungsexperte und Geschäftsführer von LEANATIC.
Lassen Sie mir Ihre E-Mail-Adresse oder Telefonnummer da – Ich freue mich darauf, Sie kennenzulernen.