Christian Vino, Software Developer bei pro.volution

Christian zeigt uns an einem komplexen Backend-System die Stärken einer Continous Integration und erklärt warum das State-Handling in ihrem Projekt für GS1 Germany eine besondere Herausforderung ist.

Hallo Christian, was ist dein offizieller Titel bei der pro.volution?

Mein offizieller Titel ist Software Developer. Aber auf Titel habe ich nie großen Wert gelegt. Ich bin hier einfach Dev. Vollblut-Dev.

Um welche Tickets kümmerst du dich bei der pro.volution?

Bei pro.volution entwickeln wir individuelle Applikationen im Web-Bereich. Dabei nutzen wir vor allem das Webframework Symfony. Ich kümmere mich also hauptsächlich um Dev-Tickets, zum Beispiel wenn es um die API oder das React-Frontend geht, aber auch um die Konzeption und die Bug-Tickets. Ich denke, das sind etwa sechzig Prozent Entwickler-Tickets und zwanzig Prozent Konzeption, was meiner Meinung nach aber noch immer zu wenig Konzeption ist.

Außerdem habe ich immer wieder auch mit Kundensupport zu tun. Durch meine Selbstständigen-Zeit ist das aber kein Problem für mich.

Inwiefern?

Es gibt zum Beispiel die Situation, bei der man sich als Entwickler denkt: Sag dem Kunden doch einfach, dass das gemacht werden muss und es nicht anders geht. Aus meiner Zeit als Selbstständiger weiß ich aber, dass das eine Frage der Kosten ist und der Kunde Abhängigkeiten hat, die sich nicht so einfach auflösen lassen. Die Selbstständigkeit lehrt einen, kaufmännischer zu denken und die Kundenseite besser zu verstehen. Darum finde ich, dass jeder Entwickler mal Erfahrungen als Selbstständiger gemacht haben sollte.

Ich finde, jeder Entwickler muss mal Erfahrungen als Selbstständiger gemacht haben.

Wie lange warst du selbstständig?

Vier Jahre.

War deine Selbstständigkeit Teil des Plans oder wie hat sich deine berufliche Karriere entwickelt?

Mein Plan war, irgendwas mit Computern zu machen. Erst hatte ich einen Amiga, auf dem ich nur gespielt habe. Dann einen Pentium 200 MMX, auf dem ich angefangen habe, ein paar Kleinigkeiten zu programmieren. Damit ging es eigentlich los. Ich bin kein Typ für ein Studium. Darum sagte ich mir, ich gehe zum Bund und bewerbe mich parallel für eine Ausbildung. Die Ausbildung war schneller. So fing ich bei einem IT-Systemhaus in Bonn, einer Tochterfirma der Telekom, meine Ausbildung zum Software Engineer an.

Dann ging es zum Bund?

Nein, ich hatte Glück. Das war genau zu der Zeit, zu der der Wehrdienst abgeschafft wurde.

Wie ging es dann weiter?

Meine nächste Station war Sipgate in Düsseldorf. Das waren die Anfänge von Scrum. Sipgate war im Vergleich zur Telekom superspannend für mich, weil es ganz andere Strukturen waren. Ich lernte Scrum kennen und war in der Mobilfunk-Core-Netzentwicklung und da im Backend involviert. Da ging es darum, zu lernen, wie das GSM-Netz funktioniert.

Dann kamen zwei Freunde auf mich zu und wollten was starten. Meistens, wenn einem eine Idee vorgetragen wird, dann ist die Idee eher halbherzig und nicht zu Ende gedacht. Ich bin ja eigentlich nicht so risikobereit. Aber die beiden haben mich dann überzeugt. Es ging um eine App, LikeYou hieß die, mit der du mit GPS Studenten in deiner Nähe finden konntest.

Ich habe mir Urlaub genommen und wir testeten ein bisschen rum. Und dann hieß es All-in und wir haben eine Firma gegründet.

Was waren deine Learnings aus der Startup-Zeit?

Das Wichtigste war tatsächlich: einfach machen. Für mich habe ich gelernt: Man muss reden können. Ich glaube, ein Dev, der nicht redet, muss viel Glück haben, etwas zu schaffen. Ich habe gelernt, aus meiner Rolle herauszugehen und mit Investoren über Finanzierung zu sprechen. Das ist schon der Wahnsinn, welchen Outcome, welche Vorteile und Opportunities sich daraus ergeben.

Wie bist du dann zu pro.volution gekommen?

Gegen Ende des Startups haben wir viel als Agentur gearbeitet und da war ich in einem Projekt hier bei pro.volution involviert. Als Gero Duppel, der Geschäftsführer, mich dann fragte, ob ich nicht hier anfangen möchte, war die Sache klar. Ich war von Anfang an gut integriert.

In welches Projekt bist du aktuell involviert?

Ich bin so gut wie hundert Prozent bei unserem Kunden GS1 Germany involviert. Um zu verstehen, was wir für GS1 Germany machen, muss man verstehen, was deren Geschäft ist. Die GS1 Germany ist eine akkreditierte Agentur der GLEIF, um in Deutschland LEIs auszugeben. Das sind Legal Entity Identifier, eine eindeutige Kennung, könnte man sagen, mit der man sich weltweit als Unternehmen für Finanz-Transaktionen authentifizieren kann.

Wir bauen das System, mit dem Unternehmen sich eine LEI bestellen und verwalten können. Dies ist bei der GS1 ein neuer Geschäftsbereich, der gerade im Aufbau ist. Die meisten kennen GS1 Germany als Dienstleister für den Handel, sie verwalten die EAN Code Vergabe.

Wie ist das System aufgebaut?

Das Frontend wird mit Typo3 und einer React App betrieben. Mit einem Formular bestellen Kunden eine LEI. Davon gibt es eine Verbindung zu unserer API, die aus einer Symfony-Applikation besteht, dem Kernsystem, das alle Systeme miteinander verbindet. Von der Applikation gibt es dann eine Anbindung an das CRM-System von GS1. Wir haben da eine MySQL-Datenbank und eine Elasticsearch-Instanz, um die Suche ein wenig schneller zu gestalten. Und dann gibt es noch den Export an die GLEIF beziehungsweise den Import von der GLEIF. Denn über GS1 Germany kann global nach LEIs gesucht werden. Das Formular selbst ist ja relativ einfach. Aber die Deployments werden durch die Prozesse dahinter und die States recht komplex.

Wie oft deployed ihr?

Schon so zweimal am Tag. Aber es kommt immer auf die Anforderung an. Wir versuchen zu deployen, ohne dass etwas kaputt geht. Darum geht es erst mal auf die Testumgebung, auf die auch der Kunde Zugriff hat. Wir nutzen dabei für das Typo3-System mit den React-Formularen ein eigenes Repo und für die API in Symfony auch ein eigenes. Bei Letzterem haben wir auch eine CI angeschlossen.

Was meinst du mit CI?

Das bedeutet Continuous Integration. Der Zweck davon ist die Anwendung bei jeder Änderung zu testen, ob sie noch so funktioniert wie erwartet. Das läuft automatisiert ab. Ich bin damit auch erst hier bei pro.volution in Berührung gekommen. Früher habe ich nie so komplexe Systeme betreut, dass wir das gebraucht hätten. Für das System der GS1 macht das aber Sinn, denn mittlerweile sind die Workflows im System komplex. So eine LEI hat Laufzeiten, geht durch verschiedene States und muss am Ende richtig formatiert in der XML für die GLEIF zur Verfügung stehen. Es kann zum Beispiel sein, dass eine LEI nicht direkt durchgeht, sondern der Kunde der GS1 Germany noch mal etwas ändern muss.

Beim Deployment gehen wir so vor: Wir machen also einen Git-Push auf die Versionierungsverwaltung, das Git-Repository. Wir nutzen dafür Gitlab. Damit triggern wir die CI, was bedeutet, dass verschiedene Tests durchlaufen werden, bevor der Code gemerged wird. Zum Beispiel machen wir Unit-Tests, Integrationtest und prüfen den Code mit verschiedenen Tools auf Fehler und Code Style. Dazu benutzen wir PHP Mess Detector, PHP Code Sniffer und den Security Checker von SensioLabs.

Gehen die Tests durch, dann wird das Deployment durchgeführt. Wenn nicht, bekommt man eine Fehlermeldung und man muss noch mal ran. Bei uns ist es jetzt so, dass wir das CI nicht ganz so hart eingestellt haben und das Deployment auch noch händisch machen, wenn die Tests durchgehen. Dafür nutzen wir dann Capistrano. Dabei werden neue Verzeichnisse erstellt, in denen die neue Version liegt, und wenn das Deployment erfolgreich war, verweist man dann darauf. So hat man immer eine laufende Version parat und kann, falls es Fehler gibt, die alte Version wieder herstellen.

Wie sieht das dann genau aus, wenn ihr ein Feature entwickelt?

Ein Projekt war die Implementierung eines Payment-Prozesses. Vorher wurde das Payment komplett von der GS1 selbst gehandled. Das sollte jetzt über das System geschehen. Uns war sofort klar, dass das eine Herausforderung wird, weil es das State-Handling noch mal komplexer macht.

Welche Schritte durchläuft so ein Projekt in der Agentur?

Neue Anforderungen nimmt eigentlich immer unser Product Owner entgegen. Er arbeitet die Anforderungen erst in Google Docs ein und später dann in unser Projektverwaltungstool Troi. Es ist jetzt nicht das beste Tool, aber zur Ressourcenplanung und zum Schreiben von Angeboten reicht es.

Wenn das Go vom Kunden kommt, gibt es ein Team-Kick-off, gefolgt von einem groben Breakdown, was aber auch schon vorher in Teilen gemacht wurde. Daraufhin erstellen die Entwickler mit dem Product Owner eine grobe Schätzung. Dann geht es noch mal feiner an die Tickets und wir pflegen sie ins Ticketsystem ein. Wir nutzen dafür intern Redmine. GS1 Germany benutzt ein anderes System, nämlich Jira. Wir haben hierzu eigene Zugänge bekommen und sie erstellen darin auch das Epic, in das wir unsere Stories schreiben können. Die Tickets kommen dann auch an unser Board, das hier im Office hängt.

Ihr macht eher Kanban als Scrum, richtig?

Genau. Im Agenturgeschäft bietet sich Scrum eigentlich nur in großen Projekten an, bei dem konstant dieselben Personen in einem Team arbeiten. Auch muss der Kunde da entsprechend mitarbeiten und Zeit für die regelmäßigen Sprint Reviews und Plannings haben. Oft wartet man aber auch auf Material oder Informationen vom Kunden. Das führt dann schon mal dazu, dass die Sprintziele deshalb nicht erreicht werden. Das frustriert das Team, Kanban ist da in der Prioritätensetzung flexibler.

Im Agenturgeschäft bietet sich Scrum eigentlich nur in großen Projekten an

Was war bei diesem Projekt die Herausforderung?

Das ganze State-Handling. Durch das Payment müssen wir Schritte dazu nehmen, bevor die eigentliche Verarbeitung passiert. Mit Ingenico nutzen wir einen Anbieter, der uns das Payment insofern abnimmt, als wir uns auf die API von Ingenico aufsetzen, und wenn eine Bezahlung stattfand, das wieder zurückbekommen. Ähnlich wie bei Paypal konnten wir die Implementierung erst mal in ihrer Sandbox testen.

Wie lange habt ihr für das Projekt gebraucht?

Die eigentliche Herausforderung bestand in der konzeptionellen Vorarbeit. Als wir das hatten, gab es lediglich ein paar Spezialfälle, die wir aber dank unserer Tests sicher im Griff hatten. Insgesamt hat das Projekt dann doch einen Monat gedauert.

Hast du einen Tipp für andere Developer, wie man so ein Projekt gut umsetzt?

Ich glaube, man kommt nicht um so ein State-Pattern herum. Es gibt ja verschiedene Vorgehensweisen. Zum Beispiel Command-Query-Responsibility-Segregation, bei der man sich das State-Handling eher wie in einer relationalen Datenbank vorstellen muss. Bei unserem Vorgehen verliert man leider ein wenig die Historie. Wenn ihr euch also überlegt, etwas mit States zu bauen, versucht so weit in die Zukunft zu denken, wie es geht, und architektonisch vorzubauen.

In unserer aktuellen Situation hilft das natürlich nicht weiter, denn man stellt nicht eben mal sein komplettes System um. Wir müssen jetzt damit leben und haben bei der Implementierung des Payment zwei States hinzugenommen.

Wie viele aus dem Team haben daran gearbeitet?

Ich werde hier viel von einem Kollegen beim Backend unterstützt. Das Frontend habe ich selbst gebaut. Da galt es zum Beispiel diesen Zwischenschritt mit dem Payment einzubauen. Insgesamt sind wir 13 Leute bei pro.volution.

Welche Software-Tools nutzt du noch?

Ich nutze PhpStorm als IDE, um an der API zu arbeiten. Das Tool Postman ist supergeil, denn damit kann man http- und API-Calls speichern und ausführen. Im Front-End kommt dann noch yarn und webpack zum Einsatz, um die React-App zubauen.

Was nutzt ihr für Calls und Meetings?

Dafür nutzen wir meistens Slack. Damit kann man mittlerweile telefonieren und Screen-Sharing machen. Oft kommt aber auch Goto Meeting, Skype oder das “normale” Telefon zum Einsatz.

Was sind momentan aktuelle Themen in deinem Bereich?

React ist sicher ein wichtiges Thema, besonders im mobilen Bereich. React-Native wird zum Beispiel in der offiziellen Facebook-App oder Instagram genutzt. Es öffnet besonders Webentwicklern neue Türen und bringt Entwickler dazu, sich mehr Gedanken um Performance mit begrenzten Resourcen zu machen. Ein anderes spannendes Thema sind Sprachassistenten wie Google Home und Alexa von Amazon. Hier muss man ganz andere Ansätze gehen, als bei Applikationen mit einer Oberfläche.

Wie hältst du dich auf dem Laufenden? Welche Blogs kannst du empfehlen?

Ich halte mich hauptsächlich mit Golem und Heise.de auf dem Laufenden. Außerdem höre ich sehr gerne den Working-Draft-Podcast.

Wenn du andere Developer oder auch Unternehmen siehst, fällt dir da etwas auf, was immer wieder falsch gemacht wird?

Dass sie zu wenig miteinander reden und zu wenig reflektieren. Ich habe das damals in der Telekom gemerkt zu einer Zeit, wo das mit dem agilen Projektmanagement gerade erst angefangen hat. Aber auch in Startups, mit denen ich in den letzten Jahren in Berührung gekommen bin, war es ähnlich. Man muss manchmal über Sachen sprechen, insbesondere über das, was in der Vergangenheit passiert ist, welche Entscheidungen getroffen wurden und was davon ein Fail war. Da gehört es dann aber auch dazu, dass man über die Erfolge spricht und auch angemessen feiert.

 

Vielen Dank für das Interview!

Dieses Interview wurde am 12. Dezember 2017 in den Räumlichkeiten von pro.volution geführt.

Webseite: pro.volution