Werkzeugintegration
Die Tools zur Vermeidung technischer Schulden können auf verschiedenen Ebenen in die Entwicklung eingebunden werden.
Entwicklungsumgebung
In der Entwicklungsumgebung erhalten wir bei der täglichen Arbeit direkt Feedback zu Problemen. Beim Speichern und automatischen Kompilieren der Dateien werden Marker erstellt, die Probleme im Quellcode kennzeichnen. Durch dieses direkte Feedback können wir bei der Entwicklung umgehend Schulden vermeiden. In den IDEs gibt es verschiedene Varianten der Integration. In Eclipse laufen die meisten Prozesse kontinuierlich. Bei jedem Speichern oder auch beim “Builden” des Workspaces werden alle Prüfungen durchgeführt und direkt angezeigt. Dieses Vorgehen benötigt natürlich etwas Zeit, liefert aber auch die besten Informationen während der Entwicklung. Insbesondere wenn wir technische Schulden Abbauen wollen, ist so ein Gesamtüberblick sichergestellt. IntelliJ bzw. Android Studio verfolgen eher eine Pre-Commit Strategie. Die Prüfungen werden nicht permanent durchgeführt, sondern mit den Aktionen beim einchecken in das SCM.
SCM – Einchecken
Beim Einchecken in das Sourcecode-Managmentsystem können mit “pre-commit hooks” Aktionen durchgeführt werden. Auf dem Server können so Tools beim Einchecken ausgeführt und bei nicht eingehaltenen Regeln die Datenübernahme mit einen Fehler beenden werden. Durch das Ablehnen der Daten ist dies eine – im Gegensatz zu der mehr oder weniger “freiwilligen” Prüfung in der IDE – harte Grenze für nicht konformen Code. Erst wenn wir in der Entwicklung alle Fehler behoben haben gelangt der Code und das zugehörige Artefakt in den weiteren Build-Prozess.
CI-System
Bei der regelmäßigen Erzeugung der Builds werden z.B. während des Maven-Build-Prozesses die Analyseergebnisse verschiedener Tools abgelegt. Diese werden dann im CI-System (hier Jenkins) in der GUI oder in Dashboards angezeigt. Bei der Auswertung der Analysedaten kann Jenkins bei (neuen) Fehlern den Build-Prozess brechen und somit weitere Entwicklungsaktivitäten fordern. Wird Jenkins so konfiguriert, stellt dies eine weitere harte Grenze dar, die verhindert, dass nicht konformer Code in das System gelangt.
Anwendungen außerhalb des Build-Prozesses
Auch außerhalb des Builds können Prüfungen erfolgen. Werkzeuge des QS-Managements (z.B. SonarQube) können verschiedene Analysen kombinieren und auch weiterreichende Informationen wie Begründungen zu nicht korrigierten Fehlern speichern. Werkzeuge zur explorativen Code-Analyse wie jQAssistant ermöglichen interaktive Analysen der Softwarestruktur und sehr weitreichende Regeln (hierzu später mehr).
Jenkins – Werkzeugkonfiguration
In Jenkins können die im Folgenden beschriebenen Konfigurationen sowohl in der klassischen GUI basierten Job-Definition, als auch in den neuen “Pipeline as code” Builds erfolgen.
Post-Build-Aktionen
Post-Build-Aktionen sind der Kern des automatischen Prozesses. In Ihnen werden für die verschiedenen Werkzeuge Schwellwerte definiert,
- die den Gesundheitszustand des Builds beeinflussen.
- die sicherstellen, dass keine oder wenige technische Schulden entstehen.
Basirend auf den Werten wird dann der Build abgebrochen oder nur als “nicht gesund” gekennzeichnet.
Das ist ja ganz nett, aber ich habe kein Greenfield Projekt!!!
Wenn die QS nachträglich in das Projekt integriert wird, ist im Allgemeinen die Anzahl der Meldungen anfänglich sehr hoch. Diese können dann unmöglich in angemessener Zeit bearbeitet werden. Eine Möglichkeit wäre die Änderung bzw. Reduzierung der angewendeten Regeln. Dies ist aber nicht zielführend. In einer solchen Situation kann Jenkins feststellen, ob neue Regelverstöße aufgetreten sind. Hierfür vergleicht Jenkins die aktuellen Fehler mit denen eines Referenzbuilds. Einzustellen ist dies ebenfalls in den “Post-Build-Schritten” unter “Neue Warnungen bestimmen (bezüglich Referenzbuild)”. Durch dieses Vorgehen ist es möglich neue Schulden zu verhindern ohne alte vollständig abbauen zu müssen. Es wird als die Möglichkeit eines geordneten Abbaus von technischen Schulden geschaffen.
Jenkins – Dashboard
In Jenkins werden alle Fehler und Ergebnisse in Dashboards oder als Übersichtsseiten angezeigt. In diesen können wir mit “click through”, wie man es eventuell aus DWH Produkten kennt, bis auf Quellcodeebene die Fehler verfolgen und nach verschiedenen Kategorien unteruschen.