Den Entwicklungsprozess automatisieren

Warum automatisieren? „Dafür haben wir in dieser Projektphase keine Zeit.“, “ Das Projekt ist zu klein dafür“ und “ Jeder Entwickler weiß, was zutun ist“ sind nur einige Ausreden Gründe, warum der Entwicklungsprozess nicht automatisiert wird. Wir haben es oft beobachtet, dass das Team tatsächlich keine Automatisierung benötigt: Es gibt den Entwickler X, der die neuen Software-Artefakte erstellt und auf den Servern verteilt und den Tester Y, der auf seinem zweiten Rechner unter dem Schreibtisch die Tests ausführt.

Doch was passiert, wenn eine der Personen im Urlaub ist oder krankheitsbedingt ausfällt? Dann stellt sich heraus, dass im Wiki auch nichts zu den Prozessen dokumentiert ist. Im Worst-Case ist das Team dann nicht in der Lage, eine neue Version der Software zu veröffentlichen. Wäre der Entwicklungsprozess automatisiert, wäre das Team auch ohne Entwickler X und Tester Y handlungsfähig, da die neue Version der Software vollkommen automatisch oder mit nur einem Klick erstellt und veröffentlicht werden könnte. Im Folgenden betrachten wir mehrere Ebenen, auf denen eine Automatisierung einen Mehrwert für das Unternehmen bringt.

Lokale Entwicklungsumgebung

Wann haben Sie das letzte mal einen neuen Mitarbeiter eingestellt? Errinnern Sie sich daran, wie die Einrichtung der lokalen Entwicklungsumgebung verlief? „Wo befindet sich das Git-Repository und woher bekomme ich einen Zugang?“, „Welche PHP-Version benötige ich?“, „Welches Encoding muss ich einstellen?“ und „Wie führe ich die Unit-Tests aus?“ sind nur ein paar Fragen, die man sich als Neuling während der Einrichtung des Rechners fragt. Es gibt Fälle, in denen die Einrichtung bis zu eine Woche gedauert hat.

Um den Aufwand für die Einrichtung auf ein Minimum zu reduzieren, gibt es unterschiedliche Hilfsmittel:

• LDAP-Anbindung der Werkzeuge (z.B. GitLab), um die Erstellung von separaten Zugängen zu vermeiden.
• Nutzung von Docker oder Vagrant, um die Plattformabhängigkeit zu lösen und die Frage nach der PHP-Version überflüssig zu machen. Der Webserver, der PHP-Interpreter und die MySQL-Datenbank sind dann bereits (z.B. in Form von Docker-Images) vorbereitet und müssten lediglich auf dem Computer des Entwicklers hochgefahren werden.
• Implementierung von Watch-Prozessen,die automatisch das Kompilieren und Unit-Testing durchführen, sobald etwas am Quellcode geändert wird. Dadurch wird vermieden, dass der Entwickler explizit das Ausführen der Unit-Tests anstoßen muss (Vielleicht weiß er zu dem Zeitpunkt auch noch gar nicht, dass die Ausführung von Unit-Tests vorgesehen ist).

Werfen Sie doch mal einen Blick auf die Zeit, die für die Einrichtung der Entwicklungsumgebung benötigt wird. Sie muss nicht > 1 Tag beanspruchen. Wenn Sie mit externen Entwicklern zusammenarbeiten und diese des öfteren mal wechseln, ist es umso wichtiger, dass die Einrichtung schnell vonstatten geht.

Continuous *-Pipeline

Nachdem die lokale Entwicklungsumgebung eingerichtet ist, muss noch das automatisiert werden, was nach dem Git-Commit und -Push passiert. Der manuell Weg ist, dass jemand ein Release erstellen möchte und dazu den aktuellen Quellcode aus dem Repository zieht, diesen kompiliert und anschließend auf die Server verteilt.

Mithilfe von Continuous Integration, Continuous Delivery und Continuous Deployment kann dies vollständig automatisiert werden. Dabei wird eine Pipeline entworfen, die automatisch gestartet wird, wenn z.B. neuer Quellcode in das Repository übertragen wird. Bei der Continuous Integration wird der Quellcode permanent übersetzt und mittels automatischen Tests und statischer Codeanalyse auf Qualität geprüft. Der Entwickler erhält somit ein schnelles Feedback, ob es bzgl. der Code-Qualität oder der Integration mit dem Hauptentwicklungszweig Probleme gibt. Continuous Delivery und -Deployment gehen noch weiter und veröffentlichen das erzeugte Software-Artefakt auch direkt auf internen bzw. Produktiv-Servern. Weitere Details und die genaue Abgrenzung zwischen den Continuous *-Varianten sind sehr gut im Artikel von Atlassian beschrieben.

Durch die Einrichtung einer entsprechenden Pipeline ist man vollkommen unabhängig von dem eingangs erwähnten „Entwickler X“ und „Tester Y“, sodass das Entwickler-Team selbstständig Software-Releases bauen und veröffentlichen kann.

Wie anfangen?

Verständlicherweise möchte man bei einem neuen Projekt möglichst schnell etwas programmieren und einen Prototypen fertigstellen. Zu dem Zeitpunkt hat man keine Zeit für Automatisierung und ist sich auch noch gar nicht sicher, ob das Projekt in dieser Konfiguration überhaupt weitergeführt wird. Für den Anfang ist es nicht wichtig, dass alles 100%ig automatisiert wird. Wird ein neues Projekt aufgesetzt, sollte man sich jedoch schon früh damit auseinander setzen, ob eine spätere Automatisierung möglich ist. Dazu gehören u.a. die Möglichkeiten, die Kompilierung und das Ausführen der Unit-Tests via CLI ausführen zu können (z.B. „npm build“ und „npm test“ bei einem Javascript-Projekt, das den Node Package Manager einsetzt). Diese Kommandos sollten schonmal gesammelt und dokumentiert werden, damit sie in eine spätere Pipeline integriert werden können.

Im nächsten Schritt können die gesammelten Kommandos dann in eine Continuous *-Pipeline gegossen werden, um sie automatisch (z.B. beim Check-In von Quellcode) ausgeführt werden können. Es ist inzwischen sehr einfach, dies z.B. mithilfe von GitLab CI oder anderen CI-Werkzeugen umzusetzen. Die Pipeline muss zum Projektbeginn nicht 100%ig durchkonzipiert sein. Es geht im ersten Schritt erstmal darum, die Werkzeuge und die Vorteile einer Automatisierung kennenzulernen.

Also, los geht’s!