Heute gibt es ganz im Sinne von Weihnachten ein dickes Danke schön! an Travis CI. Ich hatte gestern über Unit Tests gesprochen und außerdem habe ich angedeutet, dass der Multisite Language Switcher ein wenig Liebe braucht. Falls ihr – wie ich – auch ein paar Projekte auf GitHub habt, kennt ihr die Continous-Integration-Lösung vermutlich schon. Und falls nicht, ändert sich das hoffentlich ab heute.
Der Artikel ist veraltet. Ich benutze Travis seit einiger Zeit nicht mehr. Genauer gesagt, seit dem GitHub Actions eingeführt hat, mit denen man ganz ähnliche Dinge ohne einen weiteren Service erledigen kann.
GitHub hat ja den Vorteil, dass andere Entwickler sich sehr einfach in bestehende Projekte einbringen können und man im besten Fall schnell Korrekturen und wertvolle Erweiterungen für die eigenen Projekte bekommt. Travis gliedert sich da sehr schön in den ganzen Prozess ein. Continuous Integration (CI) mag zwar zuerst nur wie ein Buzzword daher kommen. Tatsächlich ist der praktische Nutzen sofort erkennbar, wenn man das Setup erst einmal stehen hat.
Travis CI testet nicht nur beim Hochladen (git push) in das Repository des Multisite Language Switchers automatisch gegen die älteste und die jüngste akzeptierte PHP-Version, sondern tut das auch bei sogenannten Pull Requests von anderen Entwicklern, die an der Codebase meines Plugins mitarbeiten wollen. Das passiert keineswegs durch externe Vorgaben, sondern weil ich das in der Konfiguration .travis.yml so eingestellt habe.
Im master-Branch kann noch die Konfiguration eingesehen werden, welche Travis CI instruiert, WordPress mit Datenbank zu installieren und dann das Plugin gegen die Installation zu testen. Im dev-Branch hingegen wird composer benötigt, um WP_Mock zu installieren und den Autoloader der beliebten Paketverwaltung zu aktualisieren. Der kleine aber feine Unterschied findet sich im durch den install– erzetzten before_script-Part.