Dann erzähl ich mal ein bisschen von unserer Struktur in der Firma.
Als ich 2010 hier angefangen hatte, wurde mit VS2008 und SourceSafe entwickelt. Allerdings letzterer in Version 6, sprich, Nutzer mussten eine Datei einchecken, damit ein anderer sie auschecken und bearbeiten konnte. Eincheckkommentare gab es überhaupt nicht und auch Branches etc. wurden schlichtweg nicht genutzt. Alles auf einem Haufen, unübersichtlicher ging es gar nicht. Dazu Regalweise Ordner mit Softwarefehlern, tausende Zeilen auskommentiertem Code (kann man ja vielleicht mal wieder brauchen), ebenso tausende Zeilen, die einfach mit if(FALSE) aus dem Spiel genommen wurden.
Es dauerte etwa 2 Jahre voll meiner subtilen Beschwerden, bis man überhaupt mal einen Bugtracker eingeführt hatte. Dieser wird inzwischen allerdings auch für jede eingegangene Mail, Anrufe etc. missbraucht, weshalb er quasi unbrauchbar geworden ist, wenn man nicht mit eigenen Filtern arbeitet.
Es dauerte schließlich bis Mitte 2015, bis ich in Eigeninitiative das Projekt TFS gestartet habe. Nach einem sorgfältig ausgearbeiteten Migrationsplan bekam ich grünes Licht der Geschäftsleitung und nach einem durchgearbeiteten Wochenende konnten wir mit dem TFS arbeiten. Alles auf dem lokalen Server aufgrund des sehr starken Misstrauens der Cloud gegenüber in der Firma. Ich habe lange argumentiert, aber nur Freigabe für eine OnPremise-Installation bekommen. Seis drum.
Endlich war es also möglich, gleichzeitig am gesamten Code zu arbeiten. Gleichzeitig habe ich unseren Workflow um schon lange notwendige Code-Reviews erweitert. Ebenso gab es eine schöne Einstellung, die Code-Checkin-Kommentare zur Pflicht machte. Einmal aktiviert, 2 Wochen das Gemecker der Kollegen ignorieren ("Wenn man jetzt aber mal ganz schnell was einchecken muss, will ich mir nicht erst einen Kommentar überlegen müssen" - und ähnliche Perlen) und schon funktioniert das.
Man merkt schon, in so einem konservativen Umfeld sind Änderungen nur sehr langsam - wenn überhaupt - möglich.
Massiv angekekst hat es mich schon seit meinem Einstieg, dass einige Kollegen es immer wieder geschafft haben, broken Code einzuchecken. Sei es, weil Ressourcen vergessen wurden oder sogar der Code selbst gar nicht kompiliert hatte. Mal den aktuellen Code abholen und darauf einen neuen Teil entwickeln konnte dazu führen, dass man erst mal ne Stunde damit zugebracht hatte, den Code wieder lauffähig zu bekommen.
Die Einführung des TFS und dieses Dauerproblem waren der Initiator zu sagen "So geht es nicht weiter". 1-2 weitere durchgearbeitete Wochenenden später haben wir ein Buildsystem eingeführt, das bei jedem Checkin prüft, ob das überhaupt kompiliert. Falls nicht -> Checkin abgelehnt. Eine schöne Sache. Das haben wir jetzt seit Anfang 2017 im Einsatz und sind sehr glücklich damit. Es folgten im Mai die Nightly-Builds für unser internes Testsystem. Vollautomatisch täglich aktuelle Kompilate auf dem Testsystem, großartig.
In der Umfrage habe ich das Releasesystem noch verneint, weil das erst jetzt so langsam als nächster Schritt ansteht. Diese ständige Verwirrung, wer jetzt welchem Kunden welche Programmversion übergeben kann ist ein Graus. Kurz zusammengefasst weiß die Rechte nicht, was die Linke tut. Das Releasesystem soll hier Abhilfe schaffen. Da ich derzeit aber auch privat enorm eingespannt bin, tu ich mir gerade etwas schwer, mir das Wissen anzueignen, zumal nicht jede Literatur in Form von Blogs und Büchern die entsprechend brauchbare Qualität aufweist. Ich will nicht wissen, welche Buttons in welchen Dialogen in welcher Reihenfolge geklickt werden müssen, ich will wissen, WARUM ich diesen oder jenen Schritt gehen muss. Das verschlingt Zeit und dementsprechend plane ich mit dem Releasesystem erst auf den Herbst.
Es ist eine ständige Transformation im Betrieb. Es geht langsam vorran, aber doch vorran. Es ist nur manchmal frustrierend, wenn von manchen Kollegen immer wieder kommt, dass "man das schon immer so gemacht hat". Man weiß genau, dass manches in den frühen 90ern steckengeblieben ist, will es besser machen, aber weil es halt anders ist, wird es abgelehnt. Ich habe lernen müssen, dass man in so einem Unternehmen die Leute ganz langsam an Änderungen heranführen muss und die Leute selber erlernen müssen, wie viel besser es in Neu sein kann. Dann wird es auch eher akzeptiert. Aber auch das, sehr zeit- und nervenaufwändig.
Ich kann aber nur aus eigener Erfahrung sagen: Ein Buildsystem lohnt sich quasi immer. Die Zeit um Code wieder lauffähig zu bekommen war firmenweit bei uns im Bereich von 4-5 Stunden pro Woche. Das ist der halbe Tag eines ganzen Entwicklers jede Woche! Diese Zeit ist inzwischen völlig entfallen. Man kann davon ausgehen, dass der Code im TFS IMMER kompiliert und läuft, egal, wann man ihn abholt. Super Sache. Und vom Releasesystem verspreche ich mir sogar noch größere Zeiteinsparungen, wenn nicht fast im Stundentakt im ganzen Haus geklärt werden muss, welche Version des Programms verteilt werden kann.
Auf jeden Fall, schöne Umfrageergebnisse. Oder zumindest interessante, manches ist ja doch eher unschön. 😉