Meist kommen aus der Community konkrete Anfragen, die erfordern, dass jemand einen tief verschachtelten Teil leicht anpasst. Dabei muss man darauf achten, dass Bisheriges nicht kaputt geht und nachher alle glücklich sind. Es tut mir fast ein wenig leid: das hier wird kein verdientes Lob auf gute Architektur oder testgetriebene Entwicklung. Es ist eine leicht andere Geschichte, die dennoch erzählt werden möchte.
Eine Contribution als Startschuss
Viele Softwareprojekte haben das Problem, dass es mit der Zeit immer schwerer wird, auf dem eigenen Rechner eine Entwicklungsumgebung einzurichten. Gerade bei Webprojekten sind eine Menge Bestandteile vorhanden, die miteinander kommunizieren und aufeinander abgestimmt sein müssen. Mit Ruby on Rails ist das durch viele Konventionen und darauf aufbauende Tools meist noch recht leicht. Aber auch hier kommt man irgendwann an die Grenzen.
Im Falle von Hitobito haben wir im Jahre 2017 ein Procfile erhalten, das angibt, welche Dienste gestartet werden müssen. Es ist nicht alles darin enthalten, so kümmert es sich beispielsweise nicht um den Suchserver oder den Cache. Aber es war ein erster Schritt, alle nötigen Services mit einem einfachen Befehl zu starten.
Etwa zwei Jahre später, im Frühjahr 2019, kam wieder Bewegung in diesen erst teilweise erfüllten Wunsch. Mit docker kann man einzelne Programme gut isoliert laufen lassen, mit docker-compose kann man diese Solisten zu einem gemeinsamen Song animieren. Ein Pull Request hat dies teilweise umgesetzt. Es fehlten jedoch noch einige Teile, sodass es nicht direkt übernommen wurde.
Mit Docker und einem professionellen Partner einen Schritt weiter
Dann kam aus einer anderen, eher unerwarteten Ecke, weiterer Rückenwind für diese Idee. Puzzle hat mit nxt Engineering zusammen an Erweiterungen für Hitobito-insieme gearbeitet. Dort hat im Sommer 2019 der docker-compose-Ansatz sehr konkrete Formen angenommen und auch ein neues, eigenes Zuhause auf Github bekommen: nxt-engineering/hitobito-docker.
Nachdem wir intern immer mal wieder mit diesem Code gearbeitet und Erfahrungen gesammelt haben, haben wir dann im Juli 2020 das Repository auch offiziell in die Hitobito-Familie aufgenommen und schlicht und ergreifend development genannt.
Doch endet es da? Fast: Es wird von einigen Entwickler*innen verwendet und ist stabil. Es hat alles, was man zum Start braucht. Der Applikationsserver läuft, die Hintergrundjobs werden abgearbeitet, abgeschickte Mails werden aufgefangen und auch der Suchserver und der Cache laufen diesmal. Der komplizierte Teil ist jetzt, die richtigen Wagons auszuwählen, damit Hitobito der Kundin/ dem Kunden entspricht. Ein freundliches README lädt ein, Hitobito bei sich einzurichten und hilft durch diese ersten Schritte.
Gemeinsam zum einfachen Setup
Bisher wurde hier häufig der Integrationsserver genutzt, der für uns und Kund*innen das gemeinsame Testen ermöglicht. Jetzt kann man mit vorrangig inhaltlichem Wissen aber selbst eine Entwicklungsumgebung starten und so leichter Anpassungen vornehmen und beitragen. Die Trittleiter, die über die bisherigen Hürden hinweg hilft, wurde dabei nicht von einer Person alleine, sondern von vielen gemeinsam ausgesucht, beschafft, zusammengebaut, angepasst, hingestellt, mehrfach hinterfragt, verbessert und ausprobiert. Sicher, die verwendeten Verben entsprechen eher dem Vergleich mit einer Trittleiter und passen nicht zu 100% auf die jeweiligen Beiträge zu der aktuellen Lösung. Da man jetzt aber eine Einsteigshürde weniger bei der Entwicklung hat, will ich darüber mal hinwegsehen und einfach nur dankbar für die Beiträge aus der Community sein.