Make your Software agile
Werbung
Make your Software agile Karsten Besserdich Besserdich und Redmann GmbH Berlin Schlüsselworte Modularisierung, Agilität, Transformation, Continuous Integration, Java, Oracle, Projektbericht Einleitung Die Wartung und Weiterentwicklung von monolithischen Anwendungen sind eine Qual. Mit der Einführung agiler Entwicklungsmethoden ändert sich daran grundsätzlich nichts. Erst durch die „Agilisierung“ der Software können SCRUM und andere agile Entwicklungsmethoden ihre ganzen Vorteile ausspielen. In diesem Projektbericht geht es um die Zerschlagung von Monolithen im „automatischen Verfahren des Zulagesystems“ der Deutschen Rentenversicherung Bund. Auf Basis des Agile Development LifeCycle werden die Änderungen und daraus resultierenden positiven Effekte dargestellt. Über den Autor Karsten Besserdich ist seit 15 Jahren in der Softwareentwicklung zuhause und beschäftigt sich seit längerem intensiv mit agilen Entwicklungsmethoden im skalierten Umfeld. Den größten Teil seiner Zeit verbrachte er in Großprojekten im öffentlichen Sektor sowie in der Energiewirtschaft. Er ist einer von zwei geschäftsführenden Gesellschaftern der Besserdich & Redmann GmbH. Karsten Besserdich und Tobias Redmann unterstützen gemeinsam mit ihren Mitarbeitern ihre Kunden bei der Planung, Durchführung und Steuerung von IT Projekten in den Bereichen Oracle und Webentwicklung. Agenda In diesem Vortrag wird aus einem aktuellen Projekt berichtet. Zuvor werden ein paar theoretische Begrifflichkeiten wiederholt. Bei dem Projektbericht werden folgende Schwerpunkte gesetzt: Organisatorische und technische Ausgangssituation Die Schmerzen Umsetzung Ergebnisse Abschließend erfolgt ein subjektives Fazit sowie ein Ausblick auf kommende Herausforderungen im weiterhin laufenden Projekt. Abgrenzung Es erfolgt keine Beschreibung wie SCRUM im skalierten Umfeld funktioniert. Auch technische Umsetzungen und Konfigurationen von Tools werden nicht erläutert. Begriffe Monolithische Anwendungen Eine monolithische Softwarearchitektur1 folgt nicht dem Ansatz einer expliziten Gliederung in Teilsysteme oder Komponenten. Ein monolithisches IT-System2 ist eine untrennbare Einheit, woraus sich u.a. folgende Nachteile ergeben: weder wartbar noch erweiterbar (nur mit erheblichen Aufwand) nicht mehr beherrschbar – bei Änderungen kann es zu nicht vorhersehbaren Nebeneffekten kommen keine Wiederverwendung von Teilen des Softwaresystems starre Kopplungen verhindern u.U. Lastverteilung auf verteilten Systemen Agile Entwicklungsmethoden Agile Softwareentwicklung versucht mit geringem bürokratischem Aufwand, wenigen Regeln und meist einem iterativen Vorgehen auszukommen3. Frameworks wie Adaptive Software Development (ASD), Crystal, Extreme Programming (XP), Kanban und das wohl bekannteste Vorgehensmodell SCRUM sind hier zu nennen. Im skalierten SCRUM sind wiederum Frameworks wie Nexus, SCRUM at Scale, SAFe und LeSS zu erwähnen. Dies sind Methoden, um agile Vorgehensweisen in großen Organisationen mit vielen Teams erfolgreich einzusetzen und diese entsprechend zu synchronisieren. 1 http://www.itwissen.info/definition/lexikon/Monolithische-Software-Architektur.html 2 http://www.enzyklopaedie-der-wirtschaftsinformatik.de/lexikon/ismanagement/Systementwicklung/Softwarearchitektur/Architekturparadigmen/Monolithisches-ITSystem 3 https://de.wikipedia.org/wiki/Agile_Softwareentwicklung Projektbericht Organisatorische Ausgangssituation Die betroffene Abteilung hat mit der Transformation in die „SCRUM-Welt“ Anfang 2015 begonnen. Bei den Produkten handelt es sich um Fachverfahren, welche z.B. Zulagen für die Riester-Rente oder Wohn-Riester berechnen. Diese Produkte befinden sich zum Teil seit über 14 Jahren im produktiven Einsatz und werden ständig den sich ändernden gesetzlichen Anforderungen angepasst. Einzelne Fachverfahren sind je nach Größe einem oder mehreren SCRUM Teams zugeordnet. Die Größenordnung aller beteiligten Personen beträgt ca. 100 -120 Personen. Team 3 Team 1 Team 4 Team 2 Abbildung 1 Organisatorische Projektstruktur Team 5 Technische Ausgangssituation Die „Basis“ Die Fachverfahren teilen sich einen Teil des Sourcecodes, der die „Basis“ genannt wird. Sie beinhaltet viele kleine Funktionalitäten wie z.B. Parameter-, Druck-, Authentifikation-, Logging-Services oder Prozess-Engine. Des Weiteren sind Informationen für den Build-Prozess der Datenbankbestandteile der einzelnen Fachverfahren in der „Basis“ abgelegt. Das bedeutet, dass die „Basis“ steuert, welches Fachverfahren welche DB-Funktionalitäten im Build-Prozess heranzieht. Die Übernahme der Java-Bestandteile der „Basis“ in ein Fachverfahren ist ein manueller Prozess und dementsprechend unbeliebt und fehleranfällig. Fachverfahren 1 Funktion 1 Fachverfahren 2 Funktion 3 Fachverfahren 3 Funktion 5 Funktion 3 Funktion 4 Funktion 1 Basis Funktion 1 Funktion 2 Funktion 3 Funktion 4 Funktion 5 Funktion ... Abbildung 2 Die "Basis" Funktionalitäten der „Basis“ Basis Java Source Java Source Funktion 1 Funktion 2 Java Source Java Source Funktion 3 ... Java SVN-Repository Die „Basis“ besteht aus Java-Sourcen und Datenbank-Bestandteilen, welche jeweils in separaten SVNRepositories verwaltet werden. Nicht nur die Ablage, sondern auch die Auslieferung der Datenbankund Java-Sourcen erfolgt separat. Function Buildinformationen TAB1 TAB4 TAB2 TAB3 PL/SQL Packages Oracle SVN-Repository DB-Schema Basis Procedure MatView Abbildung 3 Architektur der Basis Entwicklungs- & Release-Zyklus Jedes Fachverfahren sowie die „Basis“ hat seine eigenen Entwicklungs- und Release-Zyklen. Sprintdauer sowie Sprintbeginn sind weder in den Fachverfahren noch in der Basisentwicklung identisch. Grund dafür sind unter anderem gesetzliche Anforderungen an die Fachverfahren, welche zu einem bestimmten Zeitpunkt released werden müssen, sowie organisatorische und historische Gründe. Basis Funktion 1 Funktion 3 Funktion 5 Funktion 2 Funktion 4 Funktion ... Abbildung 4 Entwicklungs- & Releasezyklen Die Schmerzen Die beschriebene Ausgangssituation bringt vielerlei Probleme mit sich. Aus Sicht der Fachverfahren werden Anforderungen für Änderungen in der „Basis“ nicht rechtzeitig und in zu schlechter Qualität umgesetzt. Des Weiteren ist die separate Übernahme von Änderungen einer einzelnen Funktionalität nicht möglich. Der komplizierte und teilweise manuelle Übernahmeprozess mit getrennten Datenbankund Java-Sourcen erhöht die Komplexität erheblich. Aus Sicht der Basis-Entwicklung ist keine transparente Zuordnung von zusammengehörigen Datenbank- und Java-Bestandteilen möglich. Die geringe Testabdeckung der einzelnen Funktionalitäten ist unbefriedigend. Die Abhängigkeiten, welche hier in verschiedenen Arten vorhanden sind, erhöhen die Komplexität erheblich und machen einen erfolgreichen Einsatz von SCRUM sowie dessen Skalierung nur schwer möglich. Lösungsfindung Es wurde entschieden, die „Basis“ zu modularisieren. Alternative Lösungsvorschläge wurden umfangreich diskutiert und abgestimmt, darunter z.B. auch die Auflösung der „Basis“ und Integration sowie Weiterentwicklung der benötigten Funktionalitäten in die jeweiligen Fachverfahren. Organisatorisch wurde ein SCRUM-Team (Komponententeam „SYNERGY“) aufgestellt, welches die Aufgabe hat, die Weiterentwicklung der einzelnen Funktionalitäten in der „Basis“ fortzuführen und die Modularisierung der „Basis“ umzusetzen. Team 3 Team 1 Team 4 Team 2 Team 5 Team SYNERGY Abbildung 5 Organisatorische Projektstruktur mit Basisentwicklung Im Folgenden werden die wichtigsten Anforderungen an die Modularisierung der „Basis“ dargestellt. 1. 2. 3. 4. 5. Selektive Übernahme von einzelnen Komponenten durch die Fachverfahren ermöglichen Schnelle Umsetzung von Features ermöglichen Schlanke und gut dokumentierte Komponenten bereitstellen Hohe Qualität der Komponenten sicherstellen Automatisierung der Komponentenintegration in die Fachverfahren ermöglichen Aus diesen fünf wichtigsten Anforderungen wurde eine Vision für das SCRUM-Team der Basisentwicklung formuliert: „Als SYNERGY-Team wollen wir den Fachverfahren qualitativ hochwertige verfahrensunabhängige Komponenten zu Verfügung stellen. Auf Anforderungen aus den Fachverfahren wollen wir schnell reagieren.“ Umsetzung Roadmap Im ersten Schritt wurde eine Roadmap aufgestellt, deren wichtigste Aufgaben in den folgenden Abschnitten erläutert werden. Analyse der „Basis“ Zu Beginn wurden alle Bestandteile der „Basis“ analysiert. Alle Funktionalitäten, welche in der „Basis“ enthalten waren, wurden mit ihren Java- sowie Datenbank-Sourcen identifiziert und in Komponenten aufgeteilt. Zudem wurden Abhängigkeiten zwischen den Funktionalitäten analysiert und dokumentiert. Vorhandene Testfälle, Dokumentationen und Modelle wurden gesichtet und bewertet. Projektstruktur aufsetzen Jede Komponente wurde in einem separaten Projektverzeichnis im SVN abgelegt. Datenbank- und Java-Sourcen sollten von nun an als Einheit betrachtet werden. Vorhandene Modelle und Testfälle wurden den einzelnen Komponenten zugeordnet. Zielarchitektur Komponente 02 Komponente ... Java Source ... ... ... Database Java Source Database Java Source Database Komponente 01 Abbildung 6 Zielarchitektur der Komponenten DB-Bestandteile extrahieren Eine aufwendige Aufgabe war es, die bestehenden Datenbankobjekte zu extrahieren und den einzelnen Komponenten zuzuordnen. Dazu wurde ein Datenmodell je Komponente mittels Reverse-Engineering im Oracle Data-Modeler erstellt. Die Datenbank-Installation einer Komponente konnte somit durch die vom Data-Modeler generierten Skripte erfolgen. Build-Prozess Die Einführung eines modernen und standardisierten Build-Werkzeuges war unerlässlich. Hierbei wurde das bereits im Haus genutzte Tool Maven ausgewählt. Für die Ablage von Artefakten wurde das Tool JFrog Artifactory gewählt. Im Build-Prozess wurden nun Java- und Datenbank-Artefakte generiert und im Artifactory abgelegt. Continuous Integration Für die Komponenten wurde eine eigene Continuous-Integration Umgebung aufgesetzt. Die Jobsteuerung übernahm das Tool Jenkins. Je Komponente wird in definierten Zeitabständen der Sourcecode aus dem SVN ausgecheckt, gebaut und es werden bereits vorhandene Unit-Tests ausgeführt. Testanwendung für Integrationstests Um die Komponenten automatisiert integrativ testen zu können, wurden Testanwendungen entwickelt und in den bestehenden Buildprozess integriert. Ein großer Teil des Aufwandes bestand darin, bestehende Integrationstests aus der „Basis“ zu identifizieren und der entsprechenden Komponente zuzuordnen, um diese dann lauffähig in den Testanwendungen zu integrieren und die Testergebnisse auszuwerten. Deployment CI Nachdem der dreistufige Build-Prozess durchlaufen wurde (1- Build der Java-Sourcen, 2 - Build der DB-Sourcen, 3- Build der Testanwendung) kann nun die Testanwendung auf der CI-Umgebung deployed werden. Der Deploy-Pozess erfolgt in mehreren Schritten: 1. Entpacken der Deployment-Unit (Testanwendungs-Artefakt) 2. Automatisierte Bereitstellung der notwendigen Ressourcen im Application-Server und der Datenbank 3. Deployment der Testanwendung auf dem Application-Server sowie der DB-Bestandteile (DBArtefakt) in die Datenbank Lokaler Build & Deploymentprozess Nachdem der Build- & Deploymentprozess auf der CI-Umgebung stabil und zuverlässig funktionierte, sollte dies auch auf den lokalen Entwicklerrechnern realisiert werden. Dazu wurde ebenfalls Maven als Buildwerkzeug verwendet. Somit können alle SourcecodeÄnderungen lokal verifiziert und nach erfolgreicher Prüfung in das Versionierungstool eingecheckt werden. Releaseprozess Zum Releaseprozess der Komponenten gehört neben den Releasenotes und der Releasebezeichnung auch die automatische Übernahme der neu releasten Komponenten in den Testanwendungen, in denen sie bereits Verwendung finden. Zudem mussten die DB-Skripte zum initialen Aufsetzen sowie zum Upgrade einer Komponente neu erstellt bzw. angepasst werden. Hier ist aktuell noch ein Teil manueller Aufwand enthalten. An einer vollautomatisierten Lösung wird gearbeitet. Produktdokumentation Da aus einem Produkt – der „Basis“ – nun viele separate, eigenständige Produkte entstanden sind (die Komponenten) wurde die Dokumentation ebenfalls so aufgebaut: je Komponente gibt es eine separate Produktdokumentation, die auch alle bis dahin veröffentlichten Releasenotes enthält. Quality-Gates Zur Steigerung der Qualität wurden neben den schon vorhandenen Unit- und Integrationstests QualityGates für die Code-Qualität eingeführt. Mit Hilfe des Tools Sonarqube wurden RuleSets und entsprechende Gates definiert, welche vollautomatisiert im Rahmen der CI geprüft und ausgewertet werden. Komponentenübernahme in die Fachverfahren Vor der Modularisierung wurden Build-Informationen für die einzelnen Fachverfahren teilweise in der „Basis“ vorgehalten. Mit der Einführung von Komponenten wurde dies geändert: Die Information, welches Fachverfahren, welche Komponenten, in welcher Version verwendet, wird nun in den Fachverfahren selbst verwaltet. Die Komponenten der „Basis“ besitzen somit keinerlei Informationen mehr darüber, von welchen Fachverfahren sie verwendet werden. Eine große Hürde für eine vollautomatisierte Komponentenübernahme durch ein Fachverfahren ist das Build-Werkzeug der Fachverfahren selbst. Hier werden heterogene Build-Werkzeuge verwendet, was eine Konfiguration der zu verwendenden Komponenten erheblich erschwert. Um den gewünschten Mehrwert für die Fachverfahren zu erbringen, werden aktuell Lösungsvorschläge erarbeitet. Ergebnisse der Modularisierung Folgende Ergebnisse wurden durch Modularisierung erreicht: - eigenständige Releasezyklen mehrere Teams können unabhängig voneinander an verschiedenen Komponenten arbeiten Erhöhung der Qualität durch Einführung einer CI-Umgebung schlanker Code bessere Testbarkeit Reduzierung von Abhängigkeiten Entwicklungs- & Releasezyklen nach der Modularisierung Ein wesentlicher Unterschied zu vorher ist, dass die „Basis“ nun aus einzelnen Komponenten besteht, welche über eigene Releasezyklen verfügen. Die Fachverfahren sind nicht mehr gezwungen, die komplette „Basis“ einzubinden, sondern können explizit eine bestimmte Version einer einzelnen, konkreten Komponente verwenden. Jedem Fachverfahren steht es nach dem Release einer neuen Komponentenversion frei, diese zu übernehmen. Abbildung 7 Entwicklungs- & Releasezyklen der Komponenten und Fachverfahren nach der Modularisierung Ausblick Die bei der Modularisierung der „Basis“ gewonnen Erkenntnisse können für die Fachverfahren als Grundlage für deren anstehende Modularisierung verwendet werden. Abbildung 8 Ausblick - Modularisierung von Fachverfahren Eine weitere spannende Problemstellung ist die vollautomatisierte Bereitstellung von Infrastruktur und die Verschmelzung von Betrieb und Entwicklung, als Stichworte sind hier „Infrastructure as code4“ und „DevOps5“ zu nennen. Fazit Einer der größten Herausforderungen bestand darin, einen geeigneten Build- und Deploymentprozess auf zuzusetzen. Die Einführung von neuen Tools und Techniken stieß auch auf Skepsis und vereinzelt auf Ablehnung, was Unruhe in die Teams brachte und einen Mehraufwand durch Erklärungsbedarf und Überzeugungsarbeit bedeutete. Die Etablierung von neuen Begriffen und das Schaffen eines Verständnisses bei den übrigen Entwicklungs-Teams, dass es keine separate „Basis“ mehr gibt, sondern man von Komponenten bzw. Produkten spricht, ist ein langwieriger Prozess, der bis heute andauert. Nicht zu unterschätzen war es, ca. 1,5 Jahre lang die „neue“ und „alte“ Welt parallel zu betreiben. Die Modularisierung von monolithischen Anwendungen ist zwangsläufig notwendig, um im agilen Entwicklungsumfeld Erfolg zu haben. Hierbei sollte man sich intensiv mit den XP-Praktiken wie z.B. Continuous Integration auseinandersetzen. 4 http://www.heise.de/developer/artikel/Infrastructure-as-Code-Agile-Entwicklung-muss-ueber-denSoftwarecode-hinausgehen-3046561.html 5 https://de.wikipedia.org/wiki/DevOps Kontaktadresse: Karsten Besserdich Besserdich und Redmann GmbH Hans-Böhm-Zeile 30 D-14165 Berlin Telefon: Fax: E-Mail Internet: +49 175 24 690 29 +49 30 12 089 47 69 [email protected] https://www.besserdich-redmann.com
