Die Installation

Codeception kann hier via Composer installiert werden. Jedoch wird davon in unserem Beispiel kein Gebrauch gemacht, da wir den sofortigen Einsatz von Codeception auf einer frischen VM realisieren, und somit keinen Composer installiert haben.

Mac/Linux:
Auf dem Mac bzw Linux und Unix derivaten kann Codeception auch per Command-line installiert werden.

wget http://codeception.com/codecept.phar && php codeception.phar bootstrap

mit diesem beidem Befehlen wird Codeception installiert und dessen Ordnerstruktur erstellt.

Windows:
Auf Windows muss das installationsarchiv hier manuell heruntergeladen werden von:

Nach der Installation auf Windows hat Codeception die benötigte Ordnerstruktur erstellt.

Sollte das Frontend-Testing mit Google Chrome, Firefox oder anderen Browsern durchgeführt werden, wird auch Selenium benötigt. Die Installation kann auf einem Mac/Linux per Kommandozeile mit folgenden Befehlen geschehen.

Mac:

brew install selenium-server

Linux:

apt-get install selenium-server

Auf Windows muss der Selenium Server von http://selenium.org heruntergeladen und installiert werden.

Nachdem Selenium und Codeception installiert sind, gestaltet sich der Rest der Konfiguration relativ einfach. Zunächst können im „_env“ Verzeichnis von Codeception sogenannte Testumgebungen angelegt werden, welche der Reihe nach von Codeception durchlaufen und abgearbeitet werden. Ein Beispiel für einen solche Datei sieht wie folgt aus.

In diesem .yml file wird festgelegt, dass der zu testende Browser Google Chrome sein wird.
Des Weiteren wird festgelegt, dass wir in der Auflösung 1920×1080 testen werden.
Die URL kann pro Testumgebung jeweils eine URL beinhalten, welche in unserem Testszenario momentan auf einen unserer Testserver zeigt.

Vorbereitungen für das Frontend-Testing

Nachdem wir unsere Umgebungsvariablen festgelegt haben, können wir uns der nächsten wichtigen Datei widmen. Die Datei __bootstrap.php aus dem Verzeichnis „acceptance“ wird vor jedem Test aufgerufen und erlaubt es, Variablen zu deklarieren die dann in den jeweiligen Testszenarien verwendet werden können. Diese Variablen bestehen den ganzen Test über und können von den verschiedenen Szenarien gemeinsam benutzt werden. Eine sinnvolle Verwendung dieser Datei wäre zum Beispiel eine Funktion zum erkennen des benutzten Browsers, um in den Tests darauf entsprechend reagieren zu können und die Tests für den jeweiligen Browser besser anzupassen.

Beispiel: Sollte die Funktion in __bootstrap.php ein mobiles Endgerät entdecken, kann der darauf folgende Test in seinem Testszenario darauf reagieren und zum Beispiel die mobile Navigation anstatt die normale Navigation Testen.

Hinweis: Bevor die Testszenarien durchlaufen werden können, muss Selenium entweder auf Windows mit einem Doppelklick, oder auf Mac bzw Linux/Unix derivaten mit dem Konsolenbefehl „selenium-server -p 4444“ gestartet werden.

Das Testszenario

Kommen wir nun zu den eigentlichen Tests. Jedes Testszenario das wir anlegen wollen, muss sich im „acceptance“ Verzeichnis befinden. Jede PHP datei außer __bootstrap.php wird dort für jede einzelne Testumgebung die wir im „_env“ Verzeichnis liegen haben durchlaufen. Haben wir zum Beispiel ein Testszenario wie „Navigation.php“ im „acceptance“ folder, wird dieses Szenario für chrome_1920x1080.yml aufgerufen.
Ein Beispiel eines solchen Tests sieht wie folgt aus.

amOnPage("/");
    $I->wantTo("test elements of the navigation (upper categories)");
    $I->click(".menu-button");
    $I->click("#nav-wide .level0.nav-1 a span");
    $I->moveMouseOver("#nav-wide .level0.nav-1 a span");
    $I->click(".level1.nav-1-1  a span");
?>

Der obrige test wurde mit dem Befehl „php codecept.phar run acceptance –env chrome_1920x1080“ aufgerufen. Für jede weitere Testumgebung die in die Testszenarien eingebunden werden soll, wird eine weitere –env Direktive benötigt.

Beispiel 2 Browser:

php codecept.phar run acceptance --env chrome_1920x1080 --env firefox_1920x1080

Hint: Während eines Tests der Funktionen wie $i->moveMouseOver() enthält darf die Maus nicht bewegt werden!

Je nach Generalisierung der Tests wie Beispielsweise oben beschrieben, lässt dich der Test für mehrere Anwendungszwecke verwenden. In unserem Fall ist der oben zu sehende Test für jegliches Login-Formular einer Magento-Shop Webseite einsetzbar.

Nachdem Codeception die Tests erfolgreich (oder auch nicht) beendet hat, wenden wir uns dem Verzeichnis „records“ zu. Im Verzeichnis „records“ befinden sich Screenshots von jedem einzelnen Schritt unserer Tests und dem Ergebnis. Es bleibt einem die Möglichkeit entweder die Datei „index.html“ zu öffnen und sich in einem minimalistisch gestalteten Web-interface durch die Ergebnisse zu klicken oder sich die einzelnen Fehlgeschlagenen Tests heraus zu suchen. Fehlgeschlagene Tests haben eine „.fail.“-Endung im Dateiname und sind direkt in „records“ Ordner zu finden.

Hint: Der Befehl $i->wait() veranlasst Codeception dazu, eine gewisse Zeit zu warten und einen neuen Screenshot zu erstellen.

Fazit:

Codeception ist ein effizient einsetzbares Tool mit noch kleinen Schönheitsfehlern, wie zum Beispiel das unnötige Erstellen eines Screenshots nach Verwendung des $i->wait() Befehls, die einen Entwickler jedoch keinesfalls am produktiven Einsatz des Frameworks hindern. Es stellt mit seiner einfachen Syntax und leichten Bedienbarkeit eine effektive Methode für das Frontend-Testing dar.

Der Beitrag Frontend-Testing mit Codeception erschien zuerst auf Entwicklungshilfe NRW.

Mein Plan als Magento-Entwickler für das Wochenende

Mein Plan war es eigentlich, für mein bestehendes Projekt und die darin schon gefundenen Stolpersteine Hilfe zu finden. Aus Entwickler-Sicht ist das Projekt relativ klein, da es sich lediglich um eine Migration von Magento 1.x auf 2.x ohne aktivierte Einkaufsmöglichkeit handelt. Damit entfällt die ganze Warenkorb/Checkout/AfterSales-Funktionalität. Auch E-Mail-Templates sind nicht großartig zu beachten. Das Projekt enthält jedoch ein komplettes Redesign. Damit kam es mir als Einstiegsprojekt für eine Migration sehr gelegen.

Die Stolpersteine, die sich so auftaten, während ich mich alleine mit den Dokus ans Projekt machte, tauchten an diesem Wochenende auch bei anderen auf – puuh, ich war also nicht alleine.

Da wäre zum Beispiel die einfache Aufgabe, Nummer 2 erstmal ans Laufen zu kriegen. Der Umstieg der anwesenden, durch die Bank erfahrenen alten Magento-Hasen auf das Neue-und-Alles-ist-besser-Magento gelang nicht ganz so flüssig, wie die Magento-Marketingler das gerne auf allen Kanälen hinausschreien. Beim ersten Anlegen des Projektes damals liefen bei mir die Installation und auch alles andere reibungslos. Beim Anlegen der neuen Installation für das Wochenende aber hatte ich dann Probleme damit und habe mir nebenbei mit einem Update von Version 2.0.0 auf 2.0.1 das oben beschriebene Projekt so zerschossen, dass nur noch ein Backup half.

Auch die ersten Schritte eines eigenen Templates mit der Frage „Wie bekomme ich jetzt Magento dazu, meinen Style auszuliefern?“ kamen mir seltsam bekannt vor.

Was wirklich geschah am Wochenende

Nun ja, was soll ich sagen …? Ich habe zum ersten Mal eine Pre-Party verpasst und bin erst morgens am Tag der Veranstaltung angereist. Man wird halt nicht jünger. Da ich wegen meiner Diplomarbeit letztes Jahr recht selten auf Firegento-Events war, musste man auch erstmal ordentlich netzwerken und persönlich werden. Da das aber einer der Hauptgründe für mich ist, solche Events zu besuchen, fing ich damit an. Also MacBook auf, Magento 2 laden und anfangen zu quatschen. Alibimäßig hatte ich mich deswegen auch in die Gruppe „Ist Magento 2 Mist?“ geschmissen. Das ging so den ganzen Samstag: Versuchen Magento zu installieren, quatschen über das letzte halbe Jahr, auf den Bildschirm gucken, ob die Kiste vorankommt, essen, quatschen. Zack war abends, und man saß noch in einer kleinen Runde im Brauhaus. Man ahnt es: quatschen.

Der nächste Tag sollte produktiver werden, und ich gesellte mich direkt zum Team „Migration von Firegento-PDF auf Magento 2“, dem ich samstags schon ein wenig helfen konnte.

Der Sonntag verlief dann recht flüssig mit richtiger Arbeit an Magento 2. Bis zum Versuch, die Abschlusspräsentation per Videokonferenz mit gleich zwei Ablegern des Hackathons zu halten. Am Ende gelang es irgendwie, und es ging für mich zurück nach Köln (Notiz an mich: App entwickeln, die für Events Fahrgemeinschaften erzwingt).

Schönen Dank an dieser Stelle an code-x fürs Gastgeben und an die Sponsoren!

Was ich über Magento 2 gelernt habe

Zusammenfassend lässt sich sagen: Nicht alles läuft glatt am Anfang jeder neuen Version – das ist das tägliche Brot für uns PHP-Entwickler. Ich war nicht alleine mit meinen Problemen und habe Trost und Hilfe bekommen. Da ich schon etwas tiefer in der Materie drin war, konnte ich auch selbst ein paar Mal helfen. Schönes Gefühl.

Magento 2 ist schon ein ausgereifteres Softwareprodukt als die damalige Frühversion von Magento 1 – aber aus meiner Sicht noch nicht wirklich startklar als Shop-System-Lösung für deutsche Kunden. Zudem sind bisher zu wenige Module portiert. In welchem Zeitrahmen sich das ändert, bleibt abzuwarten und zu beobachten. Die Neugierde und der Wille, mit Magento 2 zu arbeiten, war an dem Wochenende jedoch deutlich spürbar.

Der Beitrag Besuch beim Magento 2 Hackathon in Paderborn erschien zuerst auf Entwicklungshilfe NRW.

Legacy-Code-Probleme sind überall bekannt

„Nirgends werden tote Pferde so weit geritten wie in der Software-Entwicklung“ heißt es auf meiner Website. Nicht von ungefähr. Denn als Trainer und Dozent im Bereich der Software-Qualität kann ich infrage kommende Code-Stellen, die nach Robert C. Martin gerne als „Code smells“ bezeichnet werden, auch ohne die Unterstützung von Software sehr schnell ausfindig machen. Zudem sind sie unter Webdevelopern durchaus bekannt. Aber sie werden aus Zeitgründen umschifft.

Dabei ist Legacy Code längst kein Problem mehr, welches nur auf den Backend-PHP-Teil betrifft. Denn da heute Webapplikationen geschrieben werden, ist der Anteil von Javascript beträchtlich – und in den kommenden Jahren wird sich das noch weiter verschieben: API-Schnittstellen, Webservices und Microservices werden den Teil des Backends in der Applikation darstellen und unterschiedlichste Clients im Frontend die bereitgestellten Daten verarbeiten. Mit Technologien wie React und AngularJS zeichnet sich hier ein sehr klares Bild des zukünftigen Webdevelopments ab.

Legacy-Code-Nester in Webdevelopment-Projekten

Bei den Frontend-Teilen eines Webprojekts braucht man gar nicht lange zu suchen. Große Ansammlungen sind hier z. B. main.css, style.css und natürlich script.js und app.js. Das sind große und historisch gewachsene Files, die immer nur erweitert werden und selten ein Code-Refactoring gesehen haben. Auch im Bereich der Backend-Entwicklung wird trotz Software-Design und Patterns oft nicht sauber gearbeitet.

Eben dort ist PhpStorm eine große Hilfe: Code, der offensichtlich nicht verwendet wird, wird farbig ausgegraut und kann so recht zuverlässig entfernt werden. Aber auch hier ist große Vorsicht geboten: Ohne automatisierte Tests ist es nahezu unmöglich, effektiv zu arbeiten. Fakt aber ist, dass durch die gewachsene Komplexität und die schlechte Lesbarkeit viel Zeit und Motivation verloren gehen. Wenn man da überhaupt noch durchsteigt. Dann wird gerne kapituliert, was sogar bis zur Krankmeldung gehen kann. Hier Licht reinzubringen, ist, wenn man es nicht regelmäßig macht, ein immenser, unausweichlicher und stetig wachsender Kostenfaktor.

Legacy Code verursacht weitaus höhere Projektkosten

Webdevelopment-Projekte sind in einem schlechten Software-Zustand nicht mehr wartbar, zumal nach und nach immer mehr Bugs ans Tageslicht kommen. Das richtet großen Schaden in sämtlichen Bereichen einer Firma an und kann diese sogar in den Ruin treiben.

Auch Kunden ist das mittlerweile klar geworden: Rund 30 Prozent Mehrkosten sind als On-Top-Budget für Software-Qualität längst eine feste kalkulatorische Größe. Damit werden dann beispielsweise automatisierte Tests eingeführt, um den Entwicklungsprozess optimieren zu können.

Legacy Code verhindert die Weiterentwicklung der Berufssparte

Wenn die verfügbaren Ressourcen eines Webdevelopment-Teams völlig aufgebraucht werden, leiden darunter Weiterbildung und Motivation sowie die Bereitschaft, sich mit Herzblut in seine Arbeit einzubringen. Code wird dann sprichwörtlich hingerotzt. Dabei ist gerade bei der heutigen Programmierung ein enorm hohes und komplexes Wissen gefragt. Das kann nicht mal eben mit einer einzelnen PHP-Schulung abgebildet werden.

Zudem wird es Junior-Webdevelopern auf diese Weise nahezu unmöglich gemacht, sich in die vorhandenen Strukturen zu integrieren. Hinzu kommt die vertane Zeit. Denn sich mit Problemen aus einer „anderen technischen Epoche“ auseinandersetzen zu müssen, ist nicht zielführend. Innovationen und Sprünge in der Entwicklung sind so nicht machbar. Man steckt im Sumpf der Legacy-Projekte fest.

Refactoring ist der Anfang vom Ende des Legacy Codes

Software-Qualität entsteht durch Refactoring von Quellcode. Man spricht hier auch von „Aushärten“. In allen Arbeitsbereichen wird dabei noch einmal über die bestehende Arbeit geschaut, um diese zu korrigieren und zu verbessern. Sogar ein einfacher Blog-Artikel wie dieser hier bekommt dadurch mehr als zehn Revisionen.

Betrachtet man hingegen Code-Stellen, bleibt man im unteren einstelligen Bereich. Hier muss wesentlich mehr Zeit investiert und eingeplant werden. Dies ist dann zugleich eine Investition in das eigene Webdevelopment-Team. Denn warum sollte man sich schwieriger und langsamer in Projekten bewegen, bloß weil der Kunde an diesem Punkt keinen Bedarf sieht …? Schließlich geht es nicht zuletzt um die eigene Software-Qualität – und damit letztlich auch um Lebensqualität.

Wir können Software-Projekte nicht neu schreiben

Noch immer gibt es die Illusion, dass eine Website alle paar Jahre komplett neu gemacht werden muss. Selbst auf Internetseiten, die an Werbekampagnen gebunden sind, soll dies zutreffen. Doch in „Wegwerf-Seiten“ wurde in aller Regel keine aufwendige Business-Logik implementiert – wie etwa in Bereichen des E-Commerce. Insofern ist es purer Wahnsinn, zu denken, man könne mit den vorhandenen personellen Ressourcen parallel einfach mal eine neue Seite entwickeln. Das ist der falsche Weg.

„Same old thinking – same old result“ ist hier ein Problem an sich. Es verhindert, dass sich Entwickler mit neuem Wissen frisch ans Werk machen können, zumal dadurch alte Probleme am Ende nur neu verpackt werden. Zudem ergeben sich beträchtliche Spannungen, wenn ein Teil des Teams neue Software schreiben muss, während der andere Teil den bestehenden Teil weiterpflegt. So kommt nur unnötige Unruhe auf, die dem Teamgeist schadet und das Projekt behindert. Allerdings ist es ohne Weiteres möglich, bestimmte Routen eines Projekts neu zu erstellen und somit sukzessiv Teile zu erneuern. Zu diesem Thema beraten wir gerne.

Mit Pair Programming Probleme erkennen und lösen

Vor allem Refactoring im Team bietet eine hervorragende Möglichkeit, mit Pair-Programming anzufangen. Nutzt man diese Chance, so bildet man gleich auch das Webdevelopment-Team weiter und spart eine ganze Menge Zeit, die sonst für Absprachen und Konventionen nötig wäre. Gerade der „doppelte Blick“ ist ja der Schlüssel dafür, Probleme zu erkennen und aus einem anderen Blickwinkel betrachten zu können. Wir bieten Schulungen mit genau diesem Ziel an. Da der Start mit Pair Programming jedoch nicht immer ganz einfach ist, ist eine externe Meinung umso wichtiger, damit es hier nicht zum Kompetenzgerangel kommt.

Legacy Code und der innere Schweinehund

Sport ist gut für die Gesundheit, gesunde Ernährung ohnehin, und Bewegung tut ihr Übriges. Ein gesunder Körper kann am Ende immer auf einen gesunden Geist zählen. Und halten wir zur Genüge daran? Nein. Wir verfügen über einen regelrechten Ausreden-Katalog, der von täglichen Problemen bis hin zum Wetter immer eine passende Ausrede für uns parat hält. Und dabei ist es doch einfach nur eine Kopfsache.

So ist es auch in der Software-Entwicklung. Hier verhalten wir uns aus mehreren Gründen unvernünftig. Wobei oft gar nicht erst nach Gründen gesucht, sondern ebenso wie beim Thema Sport & Gesundheit bei jeder Gelegenheit der „Keine-Zeit-Joker“ ausgespielt wird. Einfach mal mit einem festen Termin über zwei Stunden in der Woche freitags ab 16 Uhr starten! Das kommt auch erstmal gut an. Aber hier sind Ausdauer und Disziplin gefragt!

Wenn der Budget-Plan keine Software-Qualität zulässt

Investitionen in die Software-Qualität und in das Personal sind dringend notwendig. Aber oft lässt der Budget-Plan dies nicht zu. Doch wie weit kommt man mit einem Auto mit brennender Motorleuchte, ohne einen Motorschaden zu riskieren …? Schlimmstenfalls bis zum Totalschaden. Gleichermaßen riskant ist ein solch „blindes“ Vorgehen in der Software-Entwicklung. Und noch einmal: Darunter leidet immer auch die Stimmung in der gesamten Firma.

In puncto Software-Qualität muss also die richtige Entscheidung getroffen werden! Es gilt, konsequent Ziele zu beschließen und zu erreichen. Der Prozess muss kontrolliert und überwacht werden.

Mit zu viel Legacy Code werden Entwickler verheizt

Als Webentwickler mit Berufserfahrung findet man derzeit in jeder Stadt Arbeitgeber und kann sofort eine Stelle besetzen. Die Stellen selbst sind dabei, auch wenn die Gehälter einander entsprechen, höchst unterschiedlich. Wird der Entwickler gefordert und gefördert – oder doch nur verheizt? Etwa durch zu viel Legacy Code. Letzteres findet man überall. Ersteres vielleicht in den vier großen Städten. Vor allem Berlin zeigt, wie es geht. Und gerade deshalb gibt es dort auch so tolle Erfolgsstories.

Der Ruf der Entwicklungsabteilung und der Software-Qualität im Unternehmen ist ein zunehmend wichtiges Entscheidungskriterium für die Karriere. Daher gilt auch hier: Ist der Ruf erst ruiniert … Treffen Unternehmen indes die richtigen Entscheidungen, so festigt man die bestehenden Strukturen und macht sich attraktiv für neue Bewerber.

Mein Fazit zum Thema Legacy Code

Legacy Code ist nach wie vor ein großes Problem, das sich nur mit Arbeit lösen lässt. Doch ist man diesen Weg einmal gegangen, dann lohnt er sich. Denn klar ist:

• Die Software-Qualität steigt.
• Die Kunden sind zufriedener.
• Die Abteilungen können effektiv arbeiten.
• Der Spaß kehrt zurück an den Arbeitsplatz.

So betrachtet ist die gezielte und intensive Beschäftigung mit Legacy Code ein notwendiges Übel. Denn niemand mag es, ständig aufzuräumen und Ordnung zu halten. Für Profis gehört aber genau das nun einmal dazu.

Welche Erfahrungen hast du mit Legacy Code gemacht? Du kannst gerne das Kommentarfeld unter diesem Beitrag nutzen, um deine Erfahrungen mit anderen zu teilen.

Der Beitrag Legacy Code – Entstehung, Ursache und Auswirkung erschien zuerst auf Entwicklungshilfe NRW.

Continuous what?

Als Dozent für die PHP-Schulungen von Entwicklungshilfe NRW interessiere ich mich über die reine PHP-Entwicklung hinaus für das Thema Continuous Integration (CI). Neben der lokalen Entwicklung mit Tools wie Vagrant und PhpStorm zur schnellen und guten Programmierung an PHP-Applikationen ist eine stabile Pipeline zum Testen und Ausliefern (Deployment) des Codes Gold wert. Funktionierende Automatisierung spart immer Zeit und Geld. Wenn zusätzlich dabei noch getestet wird, schlafe ich als Entwickler direkt ruhiger. CI-Tools machen genau das: Sie testen in einer Entwicklungsumgebung euren Code. Jeder Durchlauf eines Prozesses wird dabei „Build“ genannt. Ziel ist es, durch automatisierte Tests und die vorherige saubere Entwicklung einen fehlerfreien Build auszuliefern.

Vielen Entwicklern wird Jenkins (bzw. Hudson) ein Begriff sein. Wer andere Erfahrungen mit ähnlichen Tools gemacht hat, kann das gerne als Kommentar hier mit einbringen.

PHPCI als Continuous Integration Tool

Heute gebe ich eine kleine Einführung in PHP Continuous Integration, kurz PHPCI. Als PHP-Entwickler habe ich zwar gute Erfahrungen mit Jenkins gemacht – ich finde aber den Ansatz von PHPCI besser, als CI-Tool für PHP-Projekte in PHP geschrieben zu sein. So verstehe ich als Entwickler das Tool besser. Obwohl PHPCI noch ein recht junges Projekt ist, finde ich die derzeitige Funktion schon brauchbar, und es macht Spaß, damit zu experimentieren. Das Github-Projekt findet ihr hier. Doch vor dem Vergnügen kommt erstmal kurz die Arbeit, sprich die Installation. Als Voraussetzung wird hier von einem Debian-basierten Webserver mit installiertem Apache und MySQL-Server ausgegangen. Paketinstallationen auf einem Server sowie das Tool composer sollten euch geläufig sein.

Installation von PHPCI

Zunächst wechseln wir in das Webverzeichnis des Servers (default /var/www):

cd /var/www

Nun erstellen wir per composer das PHPCI-Projekt. Bei dem letzten Befehl solltet ihr eure Datenbank-Zugangsdaten zur Hand haben.

composer create-project block8/phpci phpci --keep-vcs --no-dev
cd phpci && composer install
./console phpci:install

Das Ergebnis sollte so aussehen:

Eine einfache Vhost-Konfigurationsdatei, die dem Apache hinzugefügt und aktiviert wird, reicht zum Aufrufen unseres neuen Tools zur Continuous Integration:

    ServerAdmin __ADMIN__@__SERVER__
    ServerName phpci.__SERVER__
    DocumentRoot /var/www/phpci/public
    
        DirectoryIndex index.php
        Options Indexes FollowSymlinks MultiViews
        Require all granted
        AllowOverride All
        
    LogLevel warn

Solltet ihr nicht mit einer Seite wie dieser hier empfangen werden, schaut bitte in die Installationshilfe auf der PHPCI-Seite nach oder schreibt uns hier.

Wenn ihr jetzt die eingetragene URL aufruft, seht ihr die Startseite eures neuen CI-Tools, und ihr könnt euch einloggen.

Dieser komplette Installationsvorgang dauert keine 30 Minuten. PHPCI ist eine kostenlose, quelloffene Variante, die euch in die Lage versetzt, sehr schnell eine eigene Build-Pipeline als Grundlage für eine Continuous-Integration-, Continuous-Delivery- oder Continuous-Deployment-Strategie aufzubauen. Um die beiden letztgenannten Punkte geht es an dieser Stelle allerdings nicht.

Weitere Posts zum Thema Continuous Integration

Ich versuche, hier so schnell wie möglich weitere Anleitungen über PHPCI zu posten. Geplant sind derzeit auf jeden Fall:

• Aufsetzen eines versionskontrollebasierten PHP-Projektes in PHPCI
• Unit-Tests mit PHPCI
• Acceptance-Tests mit Codeception in PHPCI
• Weitere Tests wie Mess Detection und Code Coverage

Ich hoffe, meine kurze Anleitung war hilfreich für euch. Wenn ihr noch Fragen dazu habt, könnt ihr diese gerne unter Verwendung der Kommentarfunktion stellen. Ansonsten verlinke ich relevante Posts hier.

Einen detaillierten Überblick über unsere PHP-Schulungen für Webentwickler findet ihr übrigens auf der Website von Entwicklungshilfe NRW.

Der Beitrag Continuous Integration: Eine Einführung in PHPCI erschien zuerst auf Entwicklungshilfe NRW.