Hier sind die Slides zu meinem Vortrag “Continuous Integration - Bei uns geht das nicht”, den ich am 20.10.2017 auf der SEROM 2.0 in Vechta gehalten habe. Vielen Dank noch einmal in Richtung Stefan Macke für die tolle Organisation und alle Teilnehmer für die gelungene Konferenz!
Ich bin der Meinung, dass Continuous Integration (CI) heutzutage Pflicht ist, wo professionell Software entwickelt wird. Das ist in vielen Teams aber (noch) nicht der Fall.
Im Austausch mit Entwicklern höre ich dazu häufig sowas wie „Bei uns geht das nicht!“. Es handelt sich dann in der Regel um Legacy-Projekte, oft im Windows-Umfeld, in denen CI nie “vorgesehen” wurde. Dem stehen jede Menge “moderne” Technologien, die das scheinbar schon “von Haus aus” können bzw. die nötigen Tools mitliefern.
Ich habe mir die Frage gestellt, was und ob da etwas dran ist.
Tatsächlich kann sich in älteren Umgebungen das Verwalten von Abhängigkeiten schwierig gestalten. Idealerweise hat man keine. Das ist in der Praxis, gerade in großen Projekten aber eigentlich nicht vermeidbar. Oft ist die vorliegende “Struktur” über die Zeit “so gewachsen” und schwer zu handhaben. Hier können z.B. Paketmanager, wie npm (Node.js) oder Bundler (Ruby), abhilfe schaffen. Wenn es keine Paketmanager für die eigene Umgebung gibt, kann man sich diese Tools zum Vorbild nehmen und in vereinfachter Form nachbauen: Manchmal reichen z.B. schon simple Scripts zum Auschecken von Repositories oder Kopieren von Dateien.
Dann stelle ich fest, dass viele Entwickler die Kommandozeile meiden. Ohne ist Automatisierung aber nicht machbar. Das heißt: Man sollte wenigstens die Tools die man alltäglich nutzt in der Kommandozeile beherrschen. Oder wenigstens die, die man während des Build-Prozesses einsetzt. Auch, wenn einem die Konsole - warum auch immer - nicht gefällt. Zum Vergleich: Wenn man sich im Umfeld moderner, “fancy” Web-Technologien umschaut, kommt man selten um die Kommandozeile herum.
Außerdem kann eine ordentliche Dokumentation (des Buildprozesses) die Umsetzung vereinfachen. Oder anders: Wenn man seine Hausaufgaben gemacht und den Buildprozess dokumentiert hat, dann ist das häufig schon die halbe Miete. Im besten Fall sollte man die Doku nehmen und in ein CI-System übertragen können, worauf man dann schließlich Continuous Integration aufbauen kann.
Meiner Erfahrung nach und auch aus vielen Gesprächen nehme ich mit, dass das Projekt “Continuous Integration” meistens an einem dieser Punkte oder ihrer Kombination scheitert. Also: Kein oder schlechtes Dependency Management, keine oder kaum vorhandene automatisierung des Buildprozesses (vorhandene Tools werden nicht genutzt) oder kein genügender Überblick darüber bzw. Dokumentation dessen.
Wie steht es in deinem Team um CI? Was hat euch bei der Umsetzung Probleme bereitet und wie habt ihr sie gelöst? Oder was hindert euch daran Continuous Integration zu betreiben?