Aug
17

Contao Konferenz 2017 - Recap Part 3 - Entwicklersicht - Tag 2

Aus Sicht des Entwicklers - Tag 2

Aug
17

Contao Konferenz 2017 - Recap Part 3 - Entwicklersicht - Tag 2

Aus Sicht des Entwicklers - Tag 2

Zum Frontend-Recap von unserem Designer Tom Muir siehe hier

Vorträge

Abhängigkeiten in PHP Projekten mit Composer verwalten von Nils Adermann

Der Tag startete mit einem Vortrag von Nils Adermann, dem Erfinder von Composer.

Im ersten Teil des Vortrages ging Nils auf die vergangen Workflows im Umgang mit Abhängigkeiten im Projekt ein.

Angefangen bei dem alten Weg - alle Abhängigkeiten, deren Kompatibilität zueinander und das Übertragen von Konfigurationen auf verschiedene Systeme manuell durchzuführen.

Von dort ging Nils über zu der Vereinfachung des Workflows, indem Systeme wie “Puppet” zum automatischen Einspielen von Konfiguration verwendet wurden, es war jedoch weiterhin nötig die Abhängigkeiten und deren Kompatibilitäten zueinander zu verwalten.

Da dies für die Reproduzierbarkeit von Systemen (z. B. bei der lokalen Fehlersuche) jedoch nicht ausreichend war und der Aufwand die Abhängigkeiten zu verwalten mit größer werdenden Projekten anteilig immer mehr Zeit verschlang, wurde “Composer” und mit ihm https://packagist.org/ geboren.

Composer sollte sich fortan darum kümmern, die Abhängigkeiten (und deren eigenen Abhängigkeiten) eines Projektes automatisiert aufzulösen um das System in einen definierten (also lauffähigen) Zustand zu versetzen (deshalb: composer.lock immer ins VCS speichern, ausser bei libraries 😉 ).

Composer ist mittlerweile eines der mitunter wichtigsten Tools bei uns in der Firma geworden. Unter anderem weil wir es für unseren CI – Build & Deploy Prozess verwenden (Bauen und hochladen des „fertigen“ Systems basierend auf der composer.lock)

Aus eigener Erfahrung muss ich betonen, dass ich Composer nicht mehr missen möchte - obwohl ich vor ein paar Jahren, als ich zum ersten mal von Composer hörte, noch skeptisch war was davon zu halten war.

Im Hinblick auf Symfony, dessem Ökosystem und dem Fakt das Contao auf dieses Framework aufbaut jedoch sehr nützlich. Besonders wenn man weg von eng verzahnten Komponenten in einem System zu austauschbaren / leicht erweiterbaren Komponenten möchte.

Das Einführen von Composer lief natürlich auch bei uns nicht direkt vom ersten Tag reibungslos.

Wir hatten Beispielsweise ein Projekt, bei dem der Build Prozess „composer update“ statt „composer install“ gemacht hat.

Was sich erstmal „trivial“ anhört ist ein wichtiger Unterschied:

Ein einfaches „composer update“ aktualisiert immer sämliche Abhängigkeiten die in der composer.json hinterlegt sind - unabhängig davon ob es ein composer.lock gibt oder nicht.

Ein „composer install“ macht nur ein Update, wenn es noch keine composer.lock gibt (die composer.lock wird nach dem "composer install" geschrieben). Gibt es schon eine composer.lock so installiert composer den im lockfile definierten Zustand.

Das ist wichtig da man in der Regel einen bestimmten Projektstand vom Kunden abnehmen lässt bzw. für Tests nutzt. Wenn sich bei jedem Deploy (sei es auf Entwicklungs-, Staging- oder Live-Systeme) noch was ändern könnte, können sich ebenso Bugs einschleichen die man vorher nicht gehabt hat und man Aufgrund unterschiedlicher Versionen ggf. erst gar nicht nachstellen kann.

Bei uns kam es glücklicherweise nicht zu Problemen, da uns das entsprechend früh aufgefallen war - durch nutzen des korrekten Befehls war es natürlich auch einfach zu beheben.

Zurück in Nils Vortrag ist für uns in Zukunft ein ggf. interessanter Punkt die „Private Repositories“.

Hier gibt es zwei Möglichkeiten – Private Packagist oder Satis.

Der Hauptgrund warum dies interessant für uns werden könnte:

Neuen Code in unserer internen Gitlab Community Instanz teilen wir, sofern sinnvoll, in Subgroups (unsere Bundles) auf.

Laut Nils ist es jedoch so, dass das direkte Einbinden von Git-Repositories weniger performant ist als wenn Composer Repositories genutzt werden. „Private Repositories“ wären ein Lösungsansatz, falls die Performance bei Auflösen / Installieren von internen Abhängigkeiten zu sehr leidet - was sich durch längere Buildzeiten bemerkbar machen würde.

Ein weiterer interessanter Punkt, den ich so noch nicht auf dem Schirm hatte war „Branch Aliases“. Details siehe https://getcomposer.org/doc/articles/aliases.md#require-inline-alias

Ich habe das vor kurzem zum Ersten mal benutzt - ich habe eines unserer Bundles um ein Feature erweitert das noch in einem Branch lag - wollte meine Anpassung aber schon in einem konkreten Projekt, wo dieses benötigt wird, testen.

Ich habe in der composer.json des Projektes dann explizit definiert das das Bundle mit der Angabe "dev-branchname as 1.6" zu laden ist. Dadurch wurde dann mein Branch im anderen Repository als Version 1.6 ausgegeben und ich konnte das neue Feature austesten ohne schon einen Merge im anderen Repository zu machen.

Das mache ich schon immer so - Ein Plädoyer an die stetige Weiterbildung von Joe Ray Gregory

Der Vortrag handelte im Grunde von Selbst-Management bezogen auf die Weiterbildung im Beruf und sprach dabei auch einige andere Themen an die im Bezug darauf helfen sollen.

Einige Punkte, die wir auch schon hier in der Firma hatten, waren “Coding Katas” - Joe gab dazu in seinen Folien auch einige Beispielseiten wo man solche Katas durchführen kann.

Was mir so noch nicht bewusst war, ist der Unterschied zwischen “Wichtig” und “Dringend” - ich habe beides Synonym verwendet & verstanden. Auf Seite 27 der Folien ist dazu eine gute Grafik.

Der Teil des Vortrags über "Komfortzonen" stimmt in dem Sinne was skepsis gegenüber neuen Technologien oder Tools betrifft - hauptsächlich im Hinblick auf die Wartung, wenn ein Projekt einmal fertig ist .

Unser Chef, welcher einzelne Symfony Projekte & DevOps umsetzt, eruiert auch neue Technologien und führt diese bei uns in das Tagesgeschäft ein. Innerhalb der letzten Jahre wäre da bspw.:

  • Gitlab (wir hatten jahrelang Trac mit SVN, dann haben wir verschiedene Git Services probiert und sind schlussendlich bei einer selbstgehosteten Gitlab CE Instance geblieben)
  • CI (via Gitlab / Docker Containern) inkl. QA, Test, Build und Deploy Stages
  • Docker-Setup um Features in Projekten lokal mit einem lauffähigen System zu entwickeln
  • Symfony als Teil unseres Spektrums (zusätzlich zu Magento / Contao & Individualentwicklung)
  • Unittesting
  • ...

Einer der Nachteile von sich schnell ändernden Technologien sind meiner Erfahrung nach wie oben erwähnt Altprojekte welche aber noch aktiv vom Kunden genutzt werden – viele von diesen lassen sich nicht ohne weiteres (sprich Aufwand → Budget vom Kunden) auf die neuen Systeme umstellen.

Selbst bei ausreichender Dokumentation ist es noch “undankbare” Arbeit, wenn man die verschiedensten alten Workflows basierend auf alten Versionen aufsetzen muss. Zum Beispiel wir haben mit sass, scss, less, bourbon, compass, … schon viele verschiedene Libraries/ Arten von CSS Generierung in unterschiedlichen Projekten eingesetzt bei denen wir teils auch spezielle Workflows hatten.

SIWECOS – Sichere Webseiten und Content Management Systeme von Markus Wortmann

Dieser Vortrag ließ mich Anfangs erst etwas grübeln, ob ich in einen anderen Vortrag wechseln sollte. Grund war, dass die 10-15 Minuten Vorstellung vom “CMS Garden e.V.” für mich den Eindruck erweckt hat, als wenn der Vortrag zum Teil als “Werbeveranstaltung” geplant war.

Die Vorurteile stellten sich aber als vorschnell gemacht heraus und der Vortrag wurde sehr interessant.

Angefangen damit, dass Markus Wortmann verschiedene Planungsmaßnahmen für verschiedene Szenarien vorbereiten sollte. Er fasste das unter dem Stichpunkt “Notfallplan” zusammen. Das erinnerte mich so ein bisschen an ein paar kleine Wiki Einträge bei uns falls ein Server ausfallen sollte (kein wirklicher Notfallplan, aber immerhin etwas 🙂 )

In diesem Zusammenhang sprach er von einer digitalen “Brandschutzübung” - bei dieser wird geprüft, ob die Notfallsysteme, die man einsetzt, im Notfall auch tatsächlich funktionieren würden. Dazu gehören unter anderem die Backupsysteme.

Das dies nicht nur eine “gute Idee” sondern auch wichtig ist, zeigen einem Vorfälle wie z.B. der von Gitlab Anfang diesen Jahres

So in other words, out of five backup/replication techniques deployed none are working reliably or set up in the first place. We ended up restoring a six-hour-old backup.” (https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/)

Mit einer digitalen Brandschutzübung würden solche Probleme im Vorfeld auffallen und können so proaktiv korrigiert werden, bevor problematische Situationen aufkommen.

Wenn man darüber nachdenkt natürlich ein völlig offensichtliches Konzept. Die digitale Brandschutzübung ist meiner Meinung nach etwas, das wir bei uns genauer definieren sollten. Ich habe zwar verteilt über die Jahre in denen ich hier arbeite schon Daten wiederhergestellt, aber das ist natürlich was anderes als z.B. einen "Health" Report von Systemen zu haben, den man auch periodisch prüft bzw. anlegt.

Von dort aus führte Markus über zu “SIWECOS” und einem kostenlos angebotenen Check, welcher sich noch in Entwicklung befindet. Später in diesem Jahr wollen die Entwickler hinter SIWECOS, soweit ich das verstanden habe, auch mit dem Contao Core-Entwicklern sprechen, was eine mögliche Zusammenarbeit für Plugin zwischen Contao und SIWECOS betrifft.

Der Plan bei diesen Plugins sieht vor, dem Endbenutzer möglichst einfach (zum Zeitpunkt der Konferenz war von einer Ampelform die Rede) klar zu machen, ob sein System nach aktuellem Stand sicher ist, ob es aktualisiert werden sollte oder ob das System in der aktuell vom Kunden genutzten Version als unsicher gilt.

Mit einem Account auf der SIWECOS Seite wird auch festgehalten, ob es bisher bekannte Sicherheitslücken zu dem System gibt und ob das System auf dem aktuellen Zustand ist - das kann z.B. laut Markus relevant sein wenn es um Haftungsansprüche gegebenüber dem Webseitenbetreiber geht - dieser aber darlegen kann das er das System aktuell gehalten hat.

Er kam im Zusammenhang mit SIWECOS auch auf “Initiative-S” zu sprechen.

Bei dieser wird die Seite in zeitlichen Abständen auf Schadcode überprüft. Soweit ich das verstanden habe gibt es auch einen Service, der Filterregeln für mod_security bereitstellt.

Beide Services sind etwas, womit wir uns in naher Zukunft auseinandersetzen sollten. Ich hatte keines dieser beiden Tools auf dem Radar - wenn ich nicht diesen Vortrag gesehen hätte.

Performance-Optimierung mit Contao 4 von Janosch Oltmanns

Es gab einige Themen, die interessant für uns wären:

Gulp “Critical” – dieses Tool ist in der Lage, anhand von HTML das CSS auf ein minimal-Set für “above the fold” Inhalte zu reduzieren.

Ich bin mir noch nicht ganz sicher, wie und ob wir das mit in unseren CI Prozess aufnehmen können, auch unter dem Gesichtspunkt, dass wir in der Regel im CI Prozess noch kein einlesbares HTML haben.

Weiterhin fand ich die Idee, ein “Performance Budget” im Projekt zu definieren, gut. Da wir vor kurzem begonnen haben, Services wie Tideways (https://tideways.io/) bei einigen Projekten zu nutzen, bietet sich es bei neuen Projekten an ein Performance Budget mit dem Kunden zu besprechen.

Für die Messbarkeit wurde dann die Developer Toolbar, Google Pagespeed, Webpagetest sowie Gulp Module vorgeschlagen.

Ich würde auch dazu tendieren, Performance Messungen die durchgeführt wurden in irgend einer Form zu archieven, damit man auch wirkliche Vergleiche ziehen kann.

Andererseits sollten natürlich genug Messungen zur Verfügung stehen, damit man keinen statistischen Schwankungen zum Opfer fällt.

Optimal wäre also so etwas wie Tideways, Blackfire oder in CI Prozessen integrierte Tests via den genannten Gulp Modulen, die die Ergebnisse archivieren und abrufbar ablegen. So kann man auch die Performance über das Projektleben verfolgen und ggf. auftretende Performanceeinbußen nachvollziehen.

Fazit zur Konferenz

Wie mein Kollege Tom Muir schon in seinem Recap erwähnte war der Konferenzort & Organisation wirklich gut -  ein Lob an das Team was das möglich gemacht hat.

Die Vorträge waren auch eine gute Mischung aus verschiedenen Themen, sodass sowohl für Frontend als auch Backend Entwickler etwas dabei war.

Was ich mir von der Konferenz wünschen würde wären ggf. etwas Contao spezifischere Entwicklerthemen - Beispielsweise im Hinblick auf Extension Entwicklung für Contao.

Wir versuchen z.B. aktuell einen Ansatz bei dem wir versuchen so viel wie Möglich aus Contao Hooks & Klassen in Services usw. auszulagern - mit dem Ziel nur nur minimalen Code in den Contao spezifischen Dateien zu haben (z.B. ein Frontend-Modul erinnert eher an einen "Controller") - mit dem Hintergrund Klassen einfacher Unittestbar zu machen, ohne das Contao Framework initialisieren zu müssen.

 

Links

Dieser Artikel teilen

Autor

Zurück

Kommentare

comments powered by Disqus