Build Performance als Web Development Agentur USP

Die Build Performance beim Web Development ist am aktuellen Markt ein echter USP. Denn Zeit ist Geld und eingesparte Zeit ist ein starker Wettbewerbsvorteil gegenüber den Mitbewerbern im Markt. Sehr viele Agenturen rollen neue Software Versionen immer noch ganz klassisch aus, in dem Sie Dateien manuell irgendwo hochladen oder sich einen aktuellen Stand einer Software mit einer Verwaltungssoftware, wie Git, auschecken. Beide Methoden brauchen manuell ausgeführt viele personelle Ressourcen und verursachen dadurch hohe Kosten. Das ist dann auch für jede Umgebung notwendig. Wenn man Staging Umgebungen zur Abnahme aktualisiert dauert das ebenfalls zusätzlich genauso lange und verdoppelt sogar die Zeit. Deshalb wird sparsam mit Releases und Rollouts umgegangen. Das ist überholt und peinlich. Features und andere Improvements müssen sofort und zuverlässig live gehen.

Von FTP Deployments, Git Checkouts und billigen Hosting Lösungen – Build Performance als Summe vieler Prozesse

“Bezahlt wird erst, wenn es live ist”, sagte Roland Golla – PHP Trainer – in seinem bekannten Talk Highlight auf den code.talks in Hamburg. Das bedeutet dann natürlich, daß man schneller bezahlt wird, wenn man Code schneller live bringt. Also spielt die Build Performance eine ganz entscheidende Rolle. Dabei gibt es viele unterschiedliche Wege, Dateien auf ein Live System zu bringen. Neben modernen Build Pipelines mit Docker, die eine komplette virtuelle Infrastruktur zur Verfügung stellen gibt es zwei sehr bekannte und etablierte Methoden. Bei der einen werden die Dateien mittels FTP oder SFTP Dateien hochgeladen und bei der anderen ein bestimmter Stand aus einer Versionsverwaltung Git auf dem Server ausgecheckt. Aber ganz egal welche Methode verwendet wird, es sind immer viele einzelne kleine Schritte nötig, die Zeit und Fachwissen benötigen. Dabei muß natürlich auch sehr sorgfältig gearbeitet werden. Einfacher und wesentlich effektiver ist es genau diesen Deployment Prozess automatisiert durchzuführen. Das hat gleich mehrere Vorteile auf die im nächsten Abschnitt eingegangen wird. Festzuhalten bleibt allerdings, daß professionelle Deployments nicht sehr verbreitet sind und sich dadurch eine Investition in Know How und Infrastruktur als echter Wettbewerbsvorteil und Innovation rentiert. Der Markt holt allerdings mit großen Schritten auf. Das liegt auch an den aktuellen Ansprüchen der Web Developer an Arbeitgeber und an den zahlreichen Vorträgen und Open Source Projekten von Never Code Alone.

Es ist mehr als nur Software live zu bringen – Es geht darum ein digitales Produkt zu verbessern

Bevor eine Software live gestellt wird erfolgt eine Abnahme durch einen Product Owner oder den Kunden selbst. Diese Preview oder Staging Umgebungen werden wesentlich öfter mit neuen Versionen beliefert, als sie am Ende live ausgerollt werden. Das liegt hier neben möglichen Fehlern oder Bugs auch an neuen Ideen durch das aktuelle User Feedback aufkommen. Hier gibt es also auf jeden Fall einen kontinuierlicher Entwicklungsprozess Die Zeit, die genau an dieser Stelle durch einen automatisierten Prozess eingespart wird, wirkt sich sehr positiv auf die Stimmung der Mitarbeiter und der Kunden aus.

Deployments passieren ständig – Wer will 2 Wochen auf etwas warten

Software entwickelt sich ständig weiter. Neben neuen Features, Bugfixes oder Komponenten, die aktualisiert werden, kommen eben immer auch neue Anforderungen dazu. Cookie Hinweise, DSGVO und auch neue Google Richtlinien spielen dabei genauso eine Rolle, wie neue Marketing Aktionen in Form von Kampagnen. Wenn man einmal hochrechnet, wie viele Deployments im Laufe eines Jahres durchgeführt werden, kommt hier schon eine beachtliche Menge auf. Dabei sind es hier immer wieder die gleichen Schritte, die ausgeführt werden müssen. Das darf also keine Ressourcen von Programmierern binden, denn die sollen ja auch programmieren. In der agilen Welt haben sich allerdings Releases alle zwei Wochen etabliert. Das finde ich persönlich nicht so gut. Vor allem die Scrum Methode mit ihren zweiwöchigen Sprints ist hier weit verbreitet. Falsch angewendet haben Entwickler hier allerdings alle zwei Wochen an den tagen vor dem Release mächtigen Druck. Das macht das Leben nicht einfacher. Hier bitte ich auch Rücksprache mit Entwicklern zu halten. Wenn die eher auf alle drei Wochen gehen wollen, um an der Infrastruktur zu arbeiten, dann ist das ein ganz sicheres Zeichen dafür, daß hier dringend etwas an der Build Performance werden muss.

Kunden kann man nicht auf ewig dumm halten – wir brauchen einen Turnaround und gute Build Performance

Es gibt Web Agenturen, die hier leicht verdientes Geld sehen. In meiner Zeit als Freelancer wurde beispielsweise ein Composer Update mit 1,5 PT abgerechnet. Das ist natürlich eine ganz schlimme Masche, die auch ordentlichen Schaden anrichtet. Einfache Updates bringen neue Features und beheben Bugs in den Bibliotheken von Drittanbietern, wie beispielsweise dem Symfony Framework oder auch bei TYPO3. Gerade im Bereich von Content Management Systemen werden hier auch immer sehr viele Sicherheitslücken geschlossen. Aber auch für Entwickler ist es natürlich wichtig neue Features zur Verfügung gestellt zu bekommen und im aktuellen Projekt zur Verfügung zu haben. Deshalb müssen Updates regelmäßig und effizient durchgeführt werden und die Aufwände dafür nicht künstlich aufgebläht vom Kunden gezahlt werden. Das bringt uns nicht weiter und wir brauchen hier einen Turnaround.

Wer soll das denn immer alles testen – Resignation macht sich breit – keine Build Performance === keine Stimmung

Manuell ist es gar nicht möglich alle Features von einer Webseite auf unterschiedlichen Browserauflösungen zu testen. Deshalb wird einfach nicht oder nur oberflächlich getestet. Auf Seiten der Agenturen hat sich da eine Resignation auch schon komplett vertieft. “Der Kunde will das nicht und solange er den Bug nicht findet oder sich beschwert werden wir hier auch nichts tun” hört man hier leider oft. Das ist in meinen Augen fahrlässig und rücksichtslos. Aber natürlich können Kunden auch nicht bei jeder Codeänderung ein mehrköpfiges Testteam über Stunden und Tage bezahlen, damit Dinge die selbstverständlich sind auch weiterhin funktionieren. Und das ist auch nicht nötig. Automatisierte Tests brauchen wenige Minuten für Dinge, die ein Mensch und echter User in Stunden ausführt und bringen die Build Performance richtig nach vorne. Gerade die Kontrolle von Formularfeldern ist so wichtig und muss bei Änderungen Sichergestellt werden.

Startseite läuft – 15% Budget für QA wird voll in Rechnung gestellt – Welcome to the real World

Die Anforderunge der Kunden ändern sich stark. Es wird wieder mehr Wert auf Qualität und zuverlässige Software gelegt. Das liegt vor allem daran, daß im Internet für viele Geschäftsfelder eine Menge Geld umgesetzt wird. Eigene E-Commerce Angebote lohnen sich wieder und längst spielen nicht nur noch Amazon und E-Bay hier die einzige Rolle. Ganz im Gegenteil. Alle Produkte, die man gerade im Bereich Handarbeit auf Facebook sieht und schön findet würde man am liebsten einfach “bestellen”. Das möchte man dann auch zu dem Zeitpunkt ganz einfach mit Paypal oder Sofortüberweisung machen. Leider werden zahlungswillige Kunden oft voll über den Tisch gezogen. Das heißt es wird gesagt, daß hohe Codequalität vorliegt und die wird auch abgerechnet. Im Projekt sieht es aber anders aus. Hier kann man gerne eine zweite Meinung und Sachverstand einholen.

Codeception Tests kommen schnell ans Ziel – bessere Build Performance durch automatisierte Tests

Webseiten haben ganz konkrete Ziele. Das reicht von Corporate Webdesign mit der Abbildung des Leistungsportfolios, Referenzen und einer klaren Call to Action über eine Telefonnummer oder ein Formular bis hin zu E-Commerce Applikationen mit aktuellen Angeboten oder gezielten Marketingaktionen. Zusammengefasst sind das einzelne Features, die in der aktuellen agilen Arbeitswelt auch gerne als User Stories zusammengefasst werden. Diese User Stories haben auch immer klare Akzeptanzkriterien. Dabei wird klar abgebildet auf welcher Url bestimmte Schritte vom User ausgeführt, damit ein bestimmtes Ziel erreicht wird. Akzeptanztests, als Frontend Tests, können das automatisiert mit realen Browsern simulieren und bei möglichen Fehlern auch direkt Screenshot und den aktuellen HTML Code zur Fehleranalyse ablegen. Komplexe Tests, beispielsweise für Suchen, brauchen hier nur wenige Zeilen und haben eine sehr hohe Codecoverage in der gesamten Applikation. Codeception kann allerdings noch viel mehr. PHPUnit-, Integration und API-Tests sind ebenfalls in das PHP-Testing Framework integriert. Dadurch ist es möglich unterschiedliche Testverfahren einzusetzen und das jeweils richtige Verfahren für ein bestimmtes Testziel einzusetzen. Automatisierte Acceptance Tests sind dabei mehr als 8 mal so schnell, wie manuelle Tests und viel präziser und eindeutiger.

In 4 Tagen zur Build Pipeline – PHP-Schulung im eigenen PHP-Projekt

Never Code Alone hat es sich zum Ziel gesetzt die Softwarequalität und Arbeitsbedingungen für Entwickler zu steigern. Dafür haben wir ganz praktische Schulungen, die direkt als Inhouse PHP-Schulung, im eigenen Projekt ausgeführt werden. Dadurch kommt das Wissen direkt an der richtigen Stelle an und ein Best Practice Fundament für kommende Projekte wird aufgebaut. Die Schulungen sind speziell für Teams entwickelt worden und setzen ganz innovativ eine Funktastatur ein.