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.

Vita

Christian schließt 2009 seine Ausbildung zum Anwendungsentwickler bei der Deutschen Telekom ab. 2011 kommt er in DĂŒsseldorf bei Sipgate mit Scrum und Echtzeit-Backendsystemen in BerĂŒhrung und grĂŒndet zwei Jahre spĂ€ter mit Freunden das Startup LikeYou, woraus spĂ€ter die BNTB-Agency in Berlin entsteht. Hier arbeitet Christian erstmals fĂŒr die pro.volution, weitere AuftrĂ€ge folgen. Heute arbeitet er als Software Developer bei der Kölner Agentur pro.volution.

Tools

  • PhpStorm, Postman
  • yarn, webpack
  • Redmine, Jira, Troi
  • Slack, GoToMeeting
  • PHP Mess Detector, PHP Code Sniffer, Security Checker, Capistrano

 

Empfehlungen

  • Blog: Golem, heise.de
  • Podcast: Working Draft

Social

1800px__img_6725

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.

840px__img_6502

840px__img_6509

840px__img_6758

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.

1800px__img_6512

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.

Maker:S,Date:2017-9-19,Ver:6,Lens:Kan03,Act:Lar02,E-ve

Maker:S,Date:2017-9-19,Ver:6,Lens:Kan03,Act:Lar02,E-ve

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.

840px__img_6558

840px__img_6556

840px__img_6562

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.

840px__img_6540

840px__img_6550

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.

840px__img_6566

840px__img_6581

840px__img_6595

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.

840px__img_6648

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.

840px__img_6698-bearbeitet

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