Auf dem Code Fellas Meetup in Leipzig gab es diesmal ein Continuous Integration PHP-Training mit einer GitLab Pipeline. Die Entwicklungshilfe NRW hat sich seit Jahren auf PHP-Trainings im Bereich Continuous Integration mit dem Codeception PHP-Testing Framework spezialisiert.
Continuous Integration PHP-Training mit GitLab und Docker als Live Coding Session
Live Coding ist das beste PHP-Training und der effektivste Know-How-Transfer für Entwickler. Neben den eigentlichen Thema werden hier auch jede Menge Softskills vermittelt. Wie debuggt man in einer Applikation und was ist der richtige Einsatz von Xdebug, PhpStorm Shortcuts und Live-templates, die Command Line in Verbindung mit oh-my-zsh und natürlich viel Clean Code Best Practice für PHP-Projekte.
10 Minuten vom Scratch – Stern.de-Suche als Live Coding PHP-Training
„Wir haben einfach keine Zeit auch noch Tests zu schreiben“. Roland Golla ist seit 3 Jahren als PHP-Consultant und PHP-Trainer unterwegs und hat für Ausreden im Bezug auf Softwarequalität und bessere Arbeitsbedingungen nicht viel übrig. Er geht offen mit seinem Nervenzusammenbruch um und fordert die Entwickler deutlich auf, sich für bessere Arbeitsbedingungen einzusetzen. Das Softwarequalität nicht bezahlt wird ist in seinen Augen auch nur eine These, denn automatisierte Prozesse und Continuous Integration bringen für ihn sehr viel Zeit, die wieder in sinnvolle Tasks, wie dem Refactoring von Legacy Code, investiert werden kann. In der Live-Coding Session hat er in einem leeren Ordner von Null einen Acceptance Frontend Test für die Suche auf Stern.de geschrieben und als GitHub Projekt veröffentlicht. Dadurch ist jeder der Teilnehmer jetzt schon in der Lage Tests für die eigenen Anwendungen zu schreiben, die lokal ausgeführt werden können und die ganzen zeit fressenden Klick-Tests im Alltag 8mal so schnell und viel zuverlässiger ausführt. Und wenn das dann andere Kollegen sehen, wollen die das sicher auch haben. Und so bringt man ein Team dazu von selber Tests zu schreiben, weil sie es als Werkzeug verstehen und wollen.
Händlerbund setzt auf automatisierte Prozesse für eigene Innovationen und gute Arbeitsbedingungen
Michael Opre ist seit fast 3 Jahren Jahren Director of IT beim der Händlerbund AG und hatte letztes Jahr bereits ein Meetup vom Roland Golla besucht. Da hat er gezeigt, wie man die Tests schreibt und die Teilnehmer mit der Funktastatur direkt in den Vortrag integriert. Ein erfrischendes, anderes und vor allem lehrreiches Format. Seitdem setzt der Händlerbund intern und für externe Unternehmen auf das Codeception Framework und ist begeistert. „Wir können uns auf unsere Software verlassen und das hat hier alles wirklich stark verbessert. Es ist wirklich eine nachhaltige Investition in die Software und das Team. Am Ende haben wirklich alle was davon und vor allem sind unsere Entwickler glücklich“, freut sich Michael Opre. Auf dem Meetup waren natürlich auch andere Teilnehmer und so wusste ein Entwickler von seinem Wechsel zu CHECK24 zu berichten und hat seinen ehemaligen Arbeitgeber am letzten Tag und auch vorher deutlich darauf hingewiesen, ohne Tests und Softwarequalität das Unternehmen zu verlassen. In Leipzig gibt es viele wachsende Unternehmen und auch Startups im Bereich Web Development und kaum neue erfahrene Bewerber. Das ist dann schon ein herber Verlust und Rückschritt. Das Motto der Entwicklungshilfe NRW ist seit der Gründung 2015 „20% mehr Entwickler werden gesucht, macht euer Team doch einfach 20% effektiver“. Mit Tool Handling, Continuous Integration und dem daraus resultierenden Teamspirit kann der Wert auch tatsächlich schnell erreicht werden.
Codeception-Tests mit steigender Nachfrage als PHP-Training
Roland Golla ist eng verbunden mit der TYPO3-Community, hat dort seine Wurzeln und auch viele Community-Freunde. Vor Jahren hat er das Codeception Framework mit Acceptance Tests in den TYPO3 Core integriert und es so zu einem festen Bestandteil des bekannten Enterprise CMS gemacht. Gerade unterstützt er auch die Core Entwickler des Open Source E-Commerce Anbieters OXID bei der Integration mit Best Practice Know-How. Das Codeception Framework verbindet unterschiedliche Testverfahren und kann, da es in PHP geschrieben ist, sehr individuell durch PHP-Entwickler auf aktuelle Projektanforderungen angepasst werden. Es ist kein Know-How aus einer anderen Technologie, wie z.B. Javascript für den Einsatz notwendig. PHP-Team setzen zunehmend auf automatisierte Deployments und landen hier schnell bei der Suche nach der geeigneten Technologie beim Codeception-Framework. Es zeichnet sich durch eine extrem einfach Syntax aus und ist dabei sehr gut mit modernen PHP-Entwicklungsstandards und Modulen erweiterbar. Dadurch können immer auch Komponenten der eigentlichen Software wiederverwendet werden.
Die Mischung findet Bugs – PHP-Training für Codeception Tests
Fälschlicherweise wird häufig in Projektanforderungen auf eine möglichste hohe Code Coverage bei Tests gepocht. Solche Tests bringen allerdings ausser grüne Übersichtsstatistiken rein gar nichts und sie sind auf keinen Fall in der Lage, zuverlässig Bugs zu finden. Das zerstört das Vertrauen in Tests und damit bleiben sie auf der Strecke. Rafal W. sagte auf dem Never Code Alone Hall of Fame Event passend „du musst da testen, wo der Kunde dir auf die Fresse haut, wenn es kaputt geht“.
Automate All the Things – PHP-Training – in 4 Tagen zur Build Pipeline mit Gitlab und Docker
In Kooperation mit der Entwicklungshilfe NRW bietet Never Code Alone ein praktisches PHP-Training gezielt für Teams an. Gemeinsam implementiert Roland Golla Acceptance-, API- und PHPUnit-Tests in ein aktuelles und bestehendes Projekt. Das passiert mit Hilfe der Funktastatur oder der Live-Sharing-Funktion in Visual Studio Code. Dadurch werden auch sehr viele Soft Skills im Bereich Tool Handling und Debugging vermittelt. Das macht die Schulung sehr abwechslungsreich. Nach zwei Tagen haben so alle Teilnehmer fundiertes Wissen zum Thema Testing und eine “Best Practice”-Ausgangsbasis für automatisierte Tests. Am dritten Tag setzte sich dann Andreas Mautz, DevOp mit dem Schwerpunkt E-Commerce, mit einem Admin zusammen und baut mit diesem die Infrastruktur für automatisierte Deployments mit GitLab und Docker auf. Hier werden dann direkt die neuen Tests genutzt. Am vierten Tag kommt dann noch einmal Roland und verbessert mit dem Team die neuen eigenen Tests. Das Training ist also nicht zusammenhängend in vier Tagen, sondern kann über einen Zeitraum verteilt werden. Das hat viele organisatorische und praktische Vorteile. Das Schulungsprogramm hat schon einige Teams erfolgreich zur Build Pipeline gebracht. Bei Fragenzu der CITT-Schulung (Continuous Integration Training und seTup) geht es hier zum Kontakt.
Gründe gegen Continuous Integration
Leider gibt es gegenüber automatisierten Tests viele Vorbehalte. Immer wieder werden hier hohe Kosten aufgeführt. Die Infrastruktur und das fehlende Know How der Entwickler stehen bei Diskussionen schnell im Mittelpunkt. Immer wieder wird aber auch die fehlende Investitionsbereitschaft der Kunden in professionelle Strukturen aufgeführt. Das ist sicherlich ein streitbares und polarisierendes Thema. In meinen Augen hat das Thema vor allem auch etwas mit Arbeitsschutz zu tun. Wenn ein Kunde wüsste, dass PHP5.3 mehr Kopfschmerzen als PHP7.4 macht, dann kann ich mir nicht immer vorstellen, dass er hier auf Kosten der Gesundheit einen möglichst niedrigen Preis erzielen möchte. Schlechte Softwarequalität macht krank und richtet nachweislich seelischen Schaden bei Entwicklern an. Die Folgen für Betroffene und auch für das familiäre und berufliche Umfeld sind katastrophal. Es ist das genaue Gegenteil einer nachhaltigen und gesunden Software-Entwicklung. Vielleicht ist das ein Gedankenanstoß, den wir einmal gemeinsam aufnehmen sollten. Vielleicht können wir uns ja mal im Sommer mit PHP7-Fahnen zu einer gemeinsamen Demo verabreden.
Das fehlende Know-How der Entwickler und wie lange dauert es eigentlich, einen Test zu schreiben
Ich kann einen Acceptance Test mit ausgelagertem HTML Markup für ein Suchformular mit Klick, Ergebnisvalidierung und Kontrolle der URL-Struktur in 10 Minuten aufsetzen. Ein solcher Test läuft automatisiert 7 mal so schnell, wie ein manueller Test. Die Testabdeckung über Applikation und Infrastruktur ist dabei gewaltig. HTML, CSS, Javascript, Backend, Routing, Datenbank und auch eventuelle Elasticsearch-Indexe werden hier mit einem Test kontrolliert. In einer deutlich geringeren Zeit lässt sich ein Unit Test für die Methode einer Klasse und in der gleichen Zeit auch schon ein komplexerer API Test realisieren. Acceptance und API-Tests können hier auch als Integrationstests sofort Formulareingaben in der Datenbank kontrollieren. Das würde manuell keiner machen, sondern als „funktioniert schon“ voraussetzen. In Talks erinnere ich da gerne an ein Megamenu, dass über zwei Wochen weg war und der Bug nur per Zufall entdeckt wurde. Das hat eben keiner gemerkt auch nicht an den Kennzahlen. Alle drei Testverfahren habe ich vom Scratch einmal bei dem Web Engineering Meetup in Düsseldorf in 30 Minuten umgesetzt. Das war den Teilnehmern allerdings ein wenig zu schnell. Das Know-How für Integration Tests ist auch wirklich minimal und absolut selbsterklärend. Hier kann man sofort einsteigen und hat keine hohen Lernkurven. Das sieht bei Unit Tests allerdings schon etwas anders aus. Code sollte den Tests schon entgegenkommen um testbarer zu sein. Mit dem richtigen Refactoring kann man allerdings Teile sehr gut testbar machen und hier schnell einen guten Ansatz finden um Tests zu implementieren. Es gibt nachweislich Teams, die nur durch meine Artikel im PHP-Magazin und durch meine Talks erfolgreich mit Tests angefangen haben.
Infrastruktur und der gefürchtete Kundenserver
In Zeiten von Docker und Kubernetes braucht man längst keine physischen Server mehr auf die irgendwelche Dateien hochgeladen werden. Tatsächlich kann das Setup parallel auf einer bestehenden Struktur betrieben werden oder auch einfach auf einem neuen Server. Anforderungen und Kosten sind hier also absolut überschaubar. GitLab steht auch als Open Source Software zum Download bereit und kann ohne Probleme auf einem eigenen Server installiert werden. Es ist eine hervorragende Software, die dadurch auch das künftige Git-Repository abbildet und sich auch sehr gut für Code Reviews durch die Merge Requests eignet. Darüber Hinaus ist es auch mit der Atlassian-Produktpalette und vor allem mit Jira kompatibel. Was den Kundenserver angeht, gibt es hier natürlich unterschiedliche Voraussetzungen. Generell kann aber auch hier der Deployment-Prozess automatisiert werden. Dateien können beispielsweise als Tar-Balls komprimiert via SSH übertragen und entpackt werden. Vielleicht muß man diesen letzten Schritt aber nicht in dem ersten Moment automatisieren, sondern kann so erstmal Test- und Staging-Umgebungen aktualisieren. Hier sind bedeutend mehr Iterationen notwendig und man spart hier schon genug Zeit, um den Prozess insgesamt innovativ auszubauen und auch angespannte Ressourcen zu entlasten.
Web Development ist mehr als nur Dateien von A nach B zu bekommen
Die Anforderungen an Projekte werden immer komplexer und in diesem Kontext wird viel mehr auf passende Komponenten, sogenannte Libraries, zurückgegriffen. Die Komponenten haben in der Regel auch eigene Abhängigkeiten. Man spricht hier im allgemeinen von einem Dependency Management. Das Betrifft sowohl das Backend mit Composer, sowie auch das Frontend beispielsweise mit Webpack. Hier gibt es allerdings auch noch weitere bekannte Tools, wie beispielsweise Grunt. Die Sources, also die physischen Files, dieser Abhängigkeiten werden in Build-Prozessen runtergeladen und der Applikation zur Verfügung gestellt. Das sind insgesamt sehr komplexe Vorgänge, die viele Dateien betreffen. Dazu kommt auch, daß sich im Gegensatz zur Entwicklung vor wenigen Jahren, auch immer mehr Dateien ändern, um ein neues Feature zu realisieren. Manuell ist es nicht mehr möglich diese Änderungen nachzuhalten, geschweige denn eine Differenz manuell in ein Live System zu bringen. Am Ende nutzt man hier auch technische Hilfsmittel und genaue Abläufe, damit man ein Release durchführt. Diese Schritte können ohne weiteres auch in Bash-Scripten erfasst und ausgeführt werden. Das ist ein erster und wichtiger Schritt, denn dadurch ist es möglich den Prozess abzubilden und auch zu optimieren. Continuous Integration umfasst alle diese routinemäßigen Aufgaben und führt diese automatisiert durch. Man kann diese Technologie also immer schon nutzen und braucht keine Vollständigkeit zum Beginn. Aber ab der Einführung kann halt immer weiter optimiert werden. Dann geht es nach vorne und es wird einfach alles besser.
PHP-Training als Open-Source-Projekt für Community Events
Konferenzen und Barcamps haben ihr Angebot neuerdings auch immer mehr mit Workshops erweitert. Das ist gut, denn Community Events bringen gleichgesinnte, motivierte und gute Entwickler zusammen. Dieser Zielgruppe in diesem Rahmen konkretes Wissen zugänglich zu machen ist sehr gut. Hier ist die Nachfrage nach automatisierten Tests mit Codeception und auch zu den Themen GitLab und Continuous Integration sehr hoch. Hier hilft Never Code Alone in Kooperation mit der Entwicklungshilfe NRW sehr gerne mit. Dafür sind wir jetzt auf dem kommenden TYPO3-Barcamp in Venlo und waren bereits beim TYPO3-Barcamp Ruhr und auf der Froscon im Einsatz.
5 Kommentare
[…] Coding-Standards. Darunter fallen zum Beispiel Coding Guidelines, Test Driven Development, Continuous Integration aber auch Continuous Improvement,” erzählt uns Stefan Thema. “Improvement, weil bei uns neben […]
[…] Um was sollte es also gehen – kurz und knapp: Testing mit Codeception und Vorbereitung für GitLab Pipelines. Wir, das Entwickler-Team der RHEINPFALZ, nahmen mit unterschiedlichsten Kenntnisständen an der […]
[…] professionell vorbereiteten Präsentationen zu den Themen “Agiler Transformation” und “Continuous Integration” teil. Beide Talks haben mir auch sehr guten Input gebracht. Aber im Nachhinein hätte ich doch […]
[…] 3 Talks zu den Themen Codeception Website Testing, Gesundheit und Arbeitsschutz in der IT sowie Clean Code auf dem TYPO3 Camp präsentieren. Für mich selber konnte ich auch einiges zu den Themen GitLab […]
[…] nicht den ganzen Tag dumme Fragen stellen. Aber man kann sich über Best Practice informieren. Also Pipelines, Deployments, Upgrades, Hosting, Cookie Banner […]