7
SOFTWARE- KONFIGURATIONSMANAGEMENT: MIT AGILEN STRATEGIEN WAHR- SCHEINLICHKEITEN ERHÖHEN Abhängigkeiten auf unterschiedlichen Plattformen (z. B. Java, .NET und Host) ist ein systematischer SCM-Prozess Vorausset- zung, um Software in regelmäßigen, kurzen Zeitabständen und in hoher Qualität bereitstellen zu können. SCM identifiziert und begleitet Artefakte in ihren Versionen und Reifegraden. Dabei werden unterschiedliche Artefakt-Typen in eine umfassende Integrationsinfrastruktur („SCM-Container”) aufgenommen. SCM bildet um Artefakte der Anforderungs- erhebung und -analyse (z. B. Use-Cases und Anwender-Storys), Quellcode und Testfälle (technische und fachliche) eine atomare Produktklammer, um fachlich und tech- nisch konsistente Versionen des hergestell- ten Gesamtpakets reproduzierbar, automa- tisiert und effizient bereitzustellen. SCM dient als Katalysator, der die täglichen Aktivitäten der Projektteilnehmer begleitet und die aus diesen Aktivitäten generierten Artefakte in Obhut nimmt. Software-Konfigurationsmanagement (Software Configuration Management, SCM) schafft bessere Rahmenbedingungen für die tägliche Arbeit in der Softwareent- wicklung. Dieser Artikel liefert einen Einstieg in das Thema. Nach einem Überblick über die Ziele und Herausforderungen von SCM und dessen Evolution hin zum interdisziplinären „Change-Enabler” stellt der Artikel agile Strategien vor, die zu höherer Produktivität führen können. Sie können diese Strategien in Ihrem Projekt einsetzen – unabhängig vom genutzten Vorgehensmodell und der Projektgröße. 10 11 Identifikation und Verwaltung von Konfigurationselementen Definition von Standards und Werk- zeugen Bereitstellung der Software Entlastung der Entwickler von Rou- tineaufgaben Aufsetzen und Pflege von Entwick- lungslinien Controlling, Versionierung und Konfliktbehandlung von Artefakten, die über eine Signifikanz verfügen und sich im Projektverlauf ändern Dokumentation aller Änderungen an den Artefakten und deren Reifegraden Effizienzsteigerungen bei der automati- sierten Orchestrierung, Paketierung und Verteilung Standardisierung und Integration von vorhandenen Werkzeugen über alle tra- ditionellen Phasen hinweg (Anfor- derungserhebung, Entwicklung, Test usw.) Etablierung von Zugriffskontrolle und Konfiguration Durchführung von Audits, Implemen- tierung von Qualtiy Gates Nachvollziehbarkeit (insbesondere der Abhängigkeit von Artefakten) Reproduzierbarkeit, Nachverfolg- barkeit, Revisionssicherheit Herausforderungen an das SCM In Zeiten von verteilten, heterogenen Systemlandschaften, der Einbindung von Legacy-Systemen und Komponenten in vie- le verschiedene Versionen und (transitiven) Ziele und Evolution von SCM Eine eindeutige Definition von SCM und dessen Umfang fällt nicht leicht. Von den einen auf das bloße technische Ein- und Auschecken von Quellcode in/aus einem Versionskontrollsystem (VCS) reduziert, von anderen auf die Teildisziplin der „Konfiguration” einer Applikation limi- tiert, ist SCM doch weit mehr. SCM hat seine Ursprünge in der Hard- warekonfiguration und wurde ab den 70er Jahren bei der Beschreibung von Software nach Verlassen der eigentlichen Entwicklungsabteilung genutzt. Babich (vgl. [Bab86-a]) geht einen Schritt weiter: Für ihn ist SCM die Aufgabe, die Evolution der erstellten Software in jeder Minute zu begleiten. Ohne diese Begleitung gäbe es eine latente Verwirrung bei der täglichen Arbeit (siehe Abb. 1). Gemäß IEEE-Standard 729-1983 umfasst SCM die folgenden Dimensionen: Identifikation (Verfügbarmachung der Produktstruktur über Versionen hin- weg) Controlling (Steuerung des Releasings und Änderungen am Produkt) Status Accounting (Aufnahme und Reporting der Status der Komponenten und Änderungsanforderungen) Audit und Review (Validierung der Vollständigkeit eines Produkts zur Be- reitstellung einer konsistenten Version) Heutzutage kann SCM kann bei der Er- füllung der folgenden Anforderungen unterstützen: schwerpunkt „Sun Java Champion” Michael Hüttermann (E-Mail: [email protected]) ist freiberuflicher Trainer und Berater für Java/JEE, SCM/ALM, SDLC-Tooling und agi- le Softwareentwicklung. Sein Praxiswissen gibt er auf internationalen Konferenzen sowie über Bücher und Artikel weiter. Reinhard Borosch (E-Mail: [email protected]) ist Angestellter bei IBM im Bereich Global Business Services. Er agiert in System- lösungsprojekten primär in den Rollen des Lead-Architekten und des Projektleiters und ist sowohl in der OpenGroup als auch inner- halb der IBM als Master-/Senior-IT-Architekt zertifiziert. die autoren

SOFTWARE- KONFIGURATIONSMANAGEMENT: MIT AGILEN …huettermann.net/artikel/SCM-Huettermann.pdf · platzumgebung, um ohne Unterbrechungen arbeiten zu können. Sie können in ihrer 12

  • Upload
    others

  • View
    9

  • Download
    0

Embed Size (px)

Citation preview

Page 1: SOFTWARE- KONFIGURATIONSMANAGEMENT: MIT AGILEN …huettermann.net/artikel/SCM-Huettermann.pdf · platzumgebung, um ohne Unterbrechungen arbeiten zu können. Sie können in ihrer 12

SOFTWARE-

KONFIGURATIONSMANAGEMENT:

MIT AGILEN STRATEGIEN WAHR-

SCHEINLICHKEITEN ERHÖHEN

Abhängigkeiten auf unterschiedlichenPlattformen (z. B. Java, .NET und Host) istein systematischer SCM-Prozess Vorausset-zung, um Software in regelmäßigen, kurzenZeitabständen und in hoher Qualitätbereitstellen zu können.

SCM identifiziert und begleitet Artefaktein ihren Versionen und Reifegraden. Dabeiwerden unterschiedliche Artefakt-Typen ineine umfassende Integrationsinfrastruktur(„SCM-Container”) aufgenommen. SCMbildet um Artefakte der Anforderungs-erhebung und -analyse (z. B. Use-Cases undAnwender-Storys), Quellcode und Testfälle(technische und fachliche) eine atomareProduktklammer, um fachlich und tech-nisch konsistente Versionen des hergestell-ten Gesamtpakets reproduzierbar, automa-tisiert und effizient bereitzustellen. SCMdient als Katalysator, der die täglichenAktivitäten der Projektteilnehmer begleitetund die aus diesen Aktivitäten generiertenArtefakte in Obhut nimmt.

Software-Konfigurationsmanagement (Software Configuration Management, SCM)schafft bessere Rahmenbedingungen für die tägliche Arbeit in der Softwareent-wicklung. Dieser Artikel liefert einen Einstieg in das Thema. Nach einem Überblicküber die Ziele und Herausforderungen von SCM und dessen Evolution hin zuminterdisziplinären „Change-Enabler” stellt der Artikel agile Strategien vor, die zuhöherer Produktivität führen können. Sie können diese Strategien in Ihrem Projekteinsetzen – unabhängig vom genutzten Vorgehensmodell und der Projektgröße.

10 11

■ Identifikation und Verwaltung vonKonfigurationselementen

■ Definition von Standards und Werk-zeugen

■ Bereitstellung der Software■ Entlastung der Entwickler von Rou-

tineaufgaben■ Aufsetzen und Pflege von Entwick-

lungslinien■ Controlling, Versionierung und

Konfliktbehandlung von Artefakten,die über eine Signifikanz verfügen undsich im Projektverlauf ändern

■ Dokumentation aller Änderungen anden Artefakten und deren Reifegraden

■ Effizienzsteigerungen bei der automati-sierten Orchestrierung, Paketierungund Verteilung

■ Standardisierung und Integration vonvorhandenen Werkzeugen über alle tra-ditionellen Phasen hinweg (Anfor-derungserhebung, Entwicklung, Testusw.)

■ Etablierung von Zugriffskontrolle undKonfiguration

■ Durchführung von Audits, Implemen-tierung von Qualtiy Gates

■ Nachvollziehbarkeit (insbesondere derAbhängigkeit von Artefakten)

■ Reproduzierbarkeit, Nachverfolg-barkeit, Revisionssicherheit

Herausforderungenan das SCMIn Zeiten von verteilten, heterogenenSystemlandschaften, der Einbindung vonLegacy-Systemen und Komponenten in vie-le verschiedene Versionen und (transitiven)

Ziele und Evolution von SCMEine eindeutige Definition von SCM unddessen Umfang fällt nicht leicht. Von deneinen auf das bloße technische Ein- undAuschecken von Quellcode in/aus einemVersionskontrollsystem (VCS) reduziert,von anderen auf die Teildisziplin der„Konfiguration” einer Applikation limi-tiert, ist SCM doch weit mehr.

SCM hat seine Ursprünge in der Hard-warekonfiguration und wurde ab den 70erJahren bei der Beschreibung von Softwarenach Verlassen der eigentlichenEntwicklungsabteilung genutzt. Babich(vgl. [Bab86-a]) geht einen Schritt weiter:Für ihn ist SCM die Aufgabe, die Evolutionder erstellten Software in jeder Minute zubegleiten. Ohne diese Begleitung gäbe eseine latente Verwirrung bei der täglichenArbeit (siehe Abb. 1).

Gemäß IEEE-Standard 729-1983umfasst SCM die folgenden Dimensionen:

■ Identifikation (Verfügbarmachung derProduktstruktur über Versionen hin-weg)

■ Controlling (Steuerung des Releasingsund Änderungen am Produkt)

■ Status Accounting (Aufnahme undReporting der Status der Komponentenund Änderungsanforderungen)

■ Audit und Review (Validierung derVollständigkeit eines Produkts zur Be-reitstellung einer konsistenten Version)

Heutzutage kann SCM kann bei der Er-füllung der folgenden Anforderungenunterstützen:

schwerpunk t

„Sun Java Champion” Michael Hüttermann

(E-Mail: [email protected])

ist freiberuflicher Trainer und Berater für

Java/JEE, SCM/ALM, SDLC-Tooling und agi-

le Softwareentwicklung. Sein Praxiswissen

gibt er auf internationalen Konferenzen

sowie über Bücher und Artikel weiter.

Reinhard Borosch

(E-Mail: [email protected])

ist Angestellter bei IBM im Bereich Global

Business Services. Er agiert in System-

lösungsprojekten primär in den Rollen des

Lead-Architekten und des Projektleiters und

ist sowohl in der OpenGroup als auch inner-

halb der IBM als Master-/Senior-IT-Architekt

zertifiziert.

d i e au toren

Page 2: SOFTWARE- KONFIGURATIONSMANAGEMENT: MIT AGILEN …huettermann.net/artikel/SCM-Huettermann.pdf · platzumgebung, um ohne Unterbrechungen arbeiten zu können. Sie können in ihrer 12

2 / 2 0 0 9

SCM als Change-EnablerIn der Entwicklung komplexer Anwen-dungssysteme –- insbesondere über längereLaufzeiten –- ist der Wandel permanenterBegleiter des Prozesses. Dabei werdenÄnderungen immer mehr der Regelfall. Einhoher Prozentsatz an Projekten verfehlt dasZiel, weil dem Wandel nicht ausreichendRaum im Entwicklungsprozess eingeräumtwird und der Umgang mit sich dynamischändernden Rahmenbedingungen misslingt.Die moderne Softwareentwicklung machtden ständigen Wandel zum wesentlichenElement des Vorgehens. Änderungen sinddabei Bestandteil des Prozesses, um indynamischen Umgebungen die Arbeiten anden jeweils gültigen Anforderungen undRahmenbedingungen auszutarieren („kon-tinuierliche Adaption”).

Im Extremfall werden dabei neben denDefekten sämtliche fachliche und techni-sche Anforderungen an ein Softwaresystemals geordnete Menge von Änderungen auf-

gefasst. Diesem Paradigma folgend, bestehtdie Entwicklung eines Systems aus einemgeordneten Prozess der Identifikation vonÄnderungen und deren Prozedierung. SCMwird zur Drehscheibe der Nachvollzieh-barkeit und ist der Change-Enabler.

Wechselwirkungen zwischenSCM und anderenManagement-DisziplinenEin Teil der Änderungen kann durch dieSCM-Infrastruktur automatisiert verarbei-tet werden. Andere Änderungen werdendurch SCM begleitet, sichtbar gemacht underst durch eine (Projekt)Management-Entscheidung im System wirksam. DasProjektmanagement (PM) schiebt denEntwurf und die Entwicklung von Kompo-nenten an, was Konfigurationselementeerzeugt und ändert sowie in Releases umge-setzte Anforderungen abbildet. Die weiterentwickelten Anforderungen und Änderun-gen haben erneut Rückwirkungen auf das

schwerpunk tschwerpunk t

Abb. 1: Durcheinander lenkt Energie ab von den eigentlichen Aufgaben in derSoftwareentwicklung (aus: [Bab86-b]).

PM – der Kreislauf ist in Abbildung 2 dar-gestellt.

SCM hat Überschneidungen zu vielenweiteren Managementaktivitäten. Dazuzählen Teildisziplinen des PM genauso wiemit diesem verwandte Disziplinen. Bei-spiele sind etwa Qualitäts- und Release-Management. Darüber hinaus sind starkeWechselwirkung zur Peopleware zu beob-achten (vgl. [Bro95] und [Wei04]).

SCM in Vorgehensmodellenund RahmenwerkenAuch Ihr Projekt wird eine Form von SCMnutzen, auch wenn Sie die Aktivitäten gege-benenfalls nicht mit diesem Begriff inVerbindung bringen. SCM-Ausprägungenkönnen eine Tangente in einem striktenProzessvorgehen sein, eine zentrale SCM-Stabsstelle oder Teil eines Werkzeugkastensaus agilen Prinzipien, getragen von vielenSchultern von Entwicklern, Architektenund anderen, oder von dediziertem SCM-Personal als zentralem Dienstleister. SCMgeht in unterschiedlichen Vorgehens-modellen und Standards auf. Beispiele hier-für sind ISO 9001, ITIL, V-Modell XT undCMM-I. Auch unter den Oberbegriff „agi-le Softwareentwicklung” subsumierteVorgehen wie FDD, Scrum, XP, ASD, Lean,Crystal und andere haben eine Affinitätzum SCM. Tabelle 1 illustriert dieKernaussagen des Agilen Manifests (vgl.[Agi]) und stellt sie in Relation zum SCM.

Die ProzessfalleEin agiles SCM-Vorgehen fördert und for-dert Feedback, Kommunikation und bieteteinen zielführenden Prozess. Der SCM-Prozess soll ferner effektiv, effizient und ein-fach sein. Wie sieht es in der Praxis aus?Nicht selten existiert entweder zu vielbegleitender SCM-Prozess oder zu wenig.Wenn es zu wenig SCM gibt, existiert keinMechanismus, um Fehler zu entdecken,Unwuchten zeitnah zu glätten und korrigie-rend einzugreifen. Als Resultat aus schlech-ter Qualität, unkoordinierter Entwicklung,Integrationsproblemen und holprigemReleasing werden mehr SCM-Prozesse ein-geführt, um die Missstände unter Kontrollezu bekommen. Durch die Einführung vonzu vielen bzw. falschen Prozessregularienwird Kontrolle suggeriert, die inWirklichkeit unter Umständen gar nichtvorhanden ist. Entsprechend sollte man denEinsatz eines ausgewogenen, an den indivi-duellen Anforderungen ausgerichtetenSCM-Prozesses prüfen und nicht versuchen,

Page 3: SOFTWARE- KONFIGURATIONSMANAGEMENT: MIT AGILEN …huettermann.net/artikel/SCM-Huettermann.pdf · platzumgebung, um ohne Unterbrechungen arbeiten zu können. Sie können in ihrer 12

Auf der anderen Seite werden Fehler häu-fig erst im Zusammenspiel von Kompo-nenten während der Integration erkannt.Entwickler spielen ihre Arbeiten auf demEntwicklungszweig ein. Dieses Vorgehen isteine Synchronisation zwischen denArbeiten der Entwickler. Je weiter hintenauf der Zeitachse dieser Synchroni-sierungspunkt liegt, desto später könnenintegrative Defekte in Architektur, Designund Code gefunden werden. Sie sollten dieEntwicklungslinien so kurz wie möglichoffen halten (beispielsweise für nur tempo-rär und kurz existente Branches).

Im Optimalfall haben Sie ausschließlicheinen Entwicklungszweig, in den alleEntwickler ihre Arbeiten einspeisen. Sie ver-zichten also auch bewusst auf schwergewich-tigere Vorgehen, wie Release-Branches oderRelease-Prepare-Branches, und ersetzen diesdurch diszipliniert einzuhaltende Konven-tionen, beispielsweise durch die Einführungeiner „Frozen Zone”, in der gegen Ende desRelease nur noch Stabilisierungsarbeitengemacht und auf dem Hauptentwick-lungszweig eingecheckt werden.

Doch Vorsicht: Diese Strategie ist keinSilver Bullet und muss an individuelleRahmenbedingungen angepasst werden.Wenn Sie während der Release-Stabi-lisierungsphase bereits neue Features fürzukünftige Releases umsetzen müssen,kann die Arbeit auf nur einer Entwick-lungslinie den Durchsatz reduzieren. AuchKonstellationen wie die Entwicklung vonProdukt-Varianten und deren separateVerwaltung über unterschiedliche Linienbedürfen besonderer Herangehensweisen.Gleich welche Lösung im Einsatz ist, soll-ten die unterschiedlichen Entwicklungs-ströme zeitnah synchronisiert werden.

Mit opimistischem Locking, einer damitzusammenhängenden Praxis, sollen einhoher Entwicklungsdurchsatz ermöglichtund Integrationsdefekte frühzeitig erkanntwerden. Dabei kann jeder zur gleichen Zeitalle Artefakte bearbeiten und ändern. DieLösung von technischen Konflikten (die inder Praxis verhältnismäßig selten vorkom-men und sich häufig durch Kommuni-kation verhindern lassen) geschieht genauzu dem Zeitpunkt, wenn ein solcherKonflikt tatsächlich auftritt.

Strategie 2:In isolierten Arbeitsumgebungen arbeitenEntwickler benötigen eine isolierte Arbeits-platzumgebung, um ohne Unterbrechungenarbeiten zu können. Sie können in ihrer

12 13

entstehenden Herausforderungen sind imGrunde so alt wie die Softwareentwicklungselbst. Waren früher noch die gleichzeitigeBearbeitung eines gemeinsamen Daten-bestandes (im Sinne von Quellcode) oderein gleichzeitiges Einspielen von unter-schiedlichen, konkurrierenden Änderungenwesentliche Fehlerquellen, so sind dieseVorgehen für sich genommen heutzutageRoutineaufgaben. Die Fragestellung hatsich zunehmend dahingehend verlagert, zuwelchem Zeitpunkt und wohin die Ände-rungen eingespielt werden.

Die Artefakte (Quellcode, Build-Skripteusw.) werden in einem zentralen VCSgehalten und versioniert. Dort gibt es einezentrale Entwicklungslinie, die Hauptlinie(Mainline), die situativ und/oder zeitlichbedingt ergänzt wird durch Zweige(Branches) für Aufgaben, Entwickler,Releases sowie Projekte, Varianten undFeatures. Verbreitet ist ferner der Ansatz,dass jeder Entwickler per se seinen eigenenNamensraum hat, in dem er den Code aufseinem isolierten VCS-Stand weiterentwi-ckelt (verteilte Versionskontrollsysteme).

durch ineffektive Überfrachtung den Teufelmit dem Beelzebub auszutreiben.

Ein Katalog agiler StrategienWieviel SCM ist notwendig und wie siehtes konkret aus? Generell ist SCM einKompromiss aus einer prozesszentriertenSicht einerseits, um Sicherheit in die kom-plexe Softwareentwicklung zu injizieren,und einer agilen (gleichwohl sehr diszipli-nierten) Sicht andererseits, die SCM alsleichtgewichtigen, kanalisierenden Aktivi-täten- und Regelschlauch versteht. Anhandvon agilen Strategien möchten wir nun diewesentlichen Eckpfeiler vorstellen, umeinen maximalen Mehrwert zu erhalten(siehe Abb. 3). Die Strategien sind skalier-bar, beispielsweise auf verteilte Ent-wicklung und große Projekte.

Strategie 1:Arbeiten auf einer einzigen, aktivenEntwicklungslinie – die Hauptlinie alsSynchronisationspunktDie aus der gleichzeitigen Fortschreibungvon Artefakten durch mehrere Entwickler

schwerpunk t

Abb. 2: Der SCM-Kreislauf.

Page 4: SOFTWARE- KONFIGURATIONSMANAGEMENT: MIT AGILEN …huettermann.net/artikel/SCM-Huettermann.pdf · platzumgebung, um ohne Unterbrechungen arbeiten zu können. Sie können in ihrer 12

2 / 2 0 0 9

autonomen, individuellen UmgebungÄnderungen von anderen zu einem vonihnen gewünschten Zeitpunkt übernehmen.In diesem Kontext spielen Tests einewesentliche Rolle. Ist das Einchecken vonÄnderungen von schlechter Qualität, hatdas für andere negative Folgen und bremstden Entwicklungsfluss. Entwickler testenihre isolierten Änderungen und spielen siefrühestens dann ein, wenn die Tests erfolg-reich durchlaufen wurden. Das ist aller-dings nur dann effizient möglich, wenn die

Build- und Test-Zeiten minimal sind.Liegen zwischen einer Codeänderung unddem Testergebnis auf der privatenUmgebung mehr als 20 bis 30 Sekunden,wird dadurch der Arbeitsablauf unterbro-chen und es geht viel Produktivität verlo-ren.

Um eine vollständige, lokale Umgebungzu haben, sind insbesondere eigeneRessourcen notwendig, wie (lokale) Serveroder eigene Datenbanken (oder Datenbank-Schemas) für jeden Entwickler. Gelegentlich

wird vorgebracht, dass geteilte, gemeinsamgenutzte Ressourcen – also beispielsweiseein Entwicklungs-Datenbankschema füralle Entwickler – eine Integration beschleu-nigen. Steht dies allerdings im Widerspruchzu einem isolierten Arbeitsplatz, kann dieProduktivität leiden. Wenn die Ressourcenzentral vorliegen und gemeinsam genutztwerden, sollte dennoch jeder Entwickler sei-nen isolierten Bereich darauf nutzen können(z. B. zentrale Datenbank, Schemas proEntwickler). Dadurch wird der Nutzengewöhnlich höher, als wenn an An-schaffungs-/Bereitstellungskosten gespartwird, insbesondere, weil laufende Ent-wicklerkosten häufig höher sind, als dieeinmalige Anschaffung von Infrastruktur.

Die folgenden komplementären Arbeits-schritte sollten Sie prüfen:

■ Einen Mechanismus etablieren, umeinen an den individuellen Entwickler-profilen austarierten Arbeitsplatz auto-matisiert und reproduzierbar bereitzu-stellen: Dem Entwickler liegen dabeiausschließlich diejenigen Artefakte inQuellform vor, die er zur Umsetzungseiner Aufgabe benötigt. Fremdkompo-nenten und Abhängigkeiten werdensauber im Binärformat eingebunden,soweit möglich. Das ermöglicht erst dieKongruenz der Builds auf Entwickler-und Build-Rechner. Der aufgebauteWorkspace liegt darüber hinaus in einerschlanken, effizienten Form vor, wasein zügiges Arbeiten ermöglicht.

■ Etablieren eines privaten Build- undTest-Prozesses: Auf diesem Weg kön-nen Entwickler ihre eigenen Änderun-gen überprüfen und bereitstellen. Dabeiist die Unabhängigkeit von nativenBuild-Mechanismen der Entwicklungs-umgebung (IDE) wichtig. Der zentraleBuild-Server arbeitet nicht mit einerIDE, sondern mit Batch-Mechanismen.Der lokal genutzte Build-Mechanismussollte mit dem zentralen identisch sein.Moderne Entwicklungsumgebungenbieten die Möglichkeit, identischeBuild-Skripte auf dem Server und lokallaufen zu lassen. Dies hilft dabei, das„Aber bei mir läuft es!”-Syndrom zuvermeiden. Der Build-Prozess wirddirekt am Anfang initial aufgesetzt undsowohl evolutionär als auch passendzur Software weiter ausgebaut. Fernerkommen Regeln zum Einsatz, diebeschreiben, wie Entwickler den Codeschreiben, Builds erstellen und den

schwerpunk t

Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.

Generell: Das Projektgeschäft dreht sich umMenschen. Software wird von Menschen fürMenschen gemacht. IT/Technik ist ein Mittelzum Zweck. Die Notwendigkeit von Prozessenund Tools wird explizit herausgestellt, da einsystematisches Vorgehen und Werkzeugeinsatzunabdingbar sind. Individuen und Interaktionensind aber noch wichtiger.

SCM-Blick: Oft gibt es Enttäuschungen beimEinsatz eines SCM, da dieser mit übermäßighohen, rigiden Prozessregularien verbunden ist.Häufig wird auch ein Werkzeug verwendet, dasin der Organisation einen rigiden Prozess aus-rollt oder notwendig macht, den diese gar nichtbenötigt. SCM-Prozesse und -Werkzeuge sollendie Arbeit unterstützen – und nicht andershe-rum. Die SCM-Infrastruktur soll leichtgewichtigsein und Interaktionen anregen.

Generell: Dokumentation ist wichtig, entschei-dend aber ist ein lauffähiges System. Der Kundekann nicht mit Dokumentation arbeiten, er willmit der Software arbeiten. Software lügt nicht.Dokumentation soll dort erstellt werden, wo sieeinen wirklichen Mehrwert bringt.

SCM-Blick: SCM kann die Bereitstellung vonArtefakten (und Konfigurationen) automatisierenund auf die Grundlage von „ausführbaremWissen” stellen, anstatt auf reichhaltigerDokumentation, z. B. in MS-Word. StattProzesse zu dokumentieren, werden diese ineine ausführbare Infrastruktur überführt.Lauffähige Software steht jederzeit und frühzei-tig im Mittelpunkt.

Funktionierende Programme sind wichtiger als ausführliche Dokumentation.

Generell: Eine auf Verträgen aufbauendeGeschäftsbeziehung ist notwendig. Dennoch:Kunde und Dienstleister sitzen in einem Bootund wollen beide eine optimale, lauffähigeSoftware. Eine intensive Zusammenarbeit, einkontinuierlicher Austausch und eine aktiveEinbeziehung des Kunden auch während derEntwicklung sind unabdingbar.

SCM-Blick: SCM kann die Kommunikation undInteraktionen zwischen den Stakeholdern kanali-sieren und Erwartungen organisieren. Ein ziel-orientierter Prozess und eine effektiveWerkzeugunterstützung machen den Status desProjekts jederzeit sichtbar und vermitteln einaktuelles Blutbild der Software. SCM liefertSynchronisationspunkte und dient alsKommunikationsvehikel.

Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.

Generell: Eine Systematik ist wichtig, um dieSoftware planmäßig, in Meilensteinen undgeordneten Aktivitäten zu erstellen. Ein starrerPlan kann eine Sicherheit suggerieren, die nichtvorhanden ist. Veränderte Rahmenbedingungenund neue Erkenntnisstufen sind in komplexenProjekten an der Tagesordnung. Das Vorgehenmuss jederzeit offen sein für Änderungen. AgileProjekte haben das Änderungsmanagementimplizit gemacht.

SCM-Blick: SCM erleichtert Änderungen undunterbindet sie nicht. SCM-Methoden und -Strukturen erlauben es der Entwicklung, ineiner vitalen, nachhaltigen Geschwindigkeit zuarbeiten. Synchronisationspunkte ermöglichenes, wechselnde Rahmenbedingungen zu identifi-zieren, darauf zeitnah zu reagieren und alsProjekt manövrierfähig zu bleiben.

Offenheit für Änderungen ist wichtiger als ein Befolgen eines festgelegten Plans.

Tabelle 1: Das agile Manifest und SCM.

Page 5: SOFTWARE- KONFIGURATIONSMANAGEMENT: MIT AGILEN …huettermann.net/artikel/SCM-Huettermann.pdf · platzumgebung, um ohne Unterbrechungen arbeiten zu können. Sie können in ihrer 12

von komplexen Altsystemen – erfordern inder Regel einen größeren Umbau. DieseStrategie ist eng verwoben mit allen ande-ren hier vorgestellten Strategien.

Strategie 4:Automatisches TestenCI umfasst ein automatisiertes, regelmäßi-ges Testen bereits als Bestandteil desEntwicklungsprozesses. AutomatisierteTests sind dabei die Voraussetzung, um inkurzen Zyklen qualitativ hochwertigeSoftware zu erstellen. Testen fängt bereitsauf dem Arbeitsplatzrechner an understreckt sich bis zu zentralen, integrativenTests bzw. einem abschließenden System-test. Pre-Checkin-Tests wendet der Ent-wickler vor jedem Einchecken an. Schlägtein Test fehl, wird nicht eingecheckt, waseinem ersten Quality Gate gleichkommt.Diese Testreihen müssen schnell laufen, umdurch zügiges Feedback wertvolle Hin-weise zu geben, ohne den Entwick-lungsfluss zu bremsen. Wenn die Pre-Checkin-Tests zu lange laufen, wird aufihre Nutzung verzichtet oder es wird selte-ner eingecheckt. Selteneres Einchecken hateinen langsameren Entwicklungsrhythmuszur Folge.

Auch integrative, zentral angestoßeneTestreihen müssen schnelle Rückkopplun-gen gewährleisten, sodass Entwicklerschnell Feedback bekommen und den Über-blick behalten, wer für welchen Defekt dieVerantwortung trägt bzw. welche Änderungfür einen Defekt verantwortlich ist.

Testen kann klein anfangen: Scheint es,dass Teile einer Anwendung nicht testbarsind (falsches Design, keine testgetriebene

14 15

„Mocks”), werden spätestens hier integra-tive Tests auf realen Datenbanken,Umsystemen und ähnlichem durchgeführt.Die gleiche Version eines Builds kann ohneneue Kompilierung und Paketierung aufweitere, auf der Staging-Leiter höher ange-siedelte Umgebungen verteilt werden (z. B.auf eine Systemtest-Umgebung). Dabeigehören insbesondere auch Datenbank-elemente zum Release und werden automa-tisiert eingespielt. Die Verfügbarmachunggeschieht durch bloße Konfiguration gegendie jeweilige Zielumgebung.

Der Integrations-Build stellt eine atoma-re Produktklammer dar – eine Klammer,die das Produkt in einem Stand fachlichund technisch reproduzierbar beschreibt.Diese Klammer ist die stetig fortgeschriebe-ne „Basiskonfiguration”. Eine Identifi-kation und SCM-mäßige Erhebung vonKomponenten beschränkt sich dabei aufdie tatsächlich eingebundenen und instal-lierten Module. Auf eine fein granularereErhebung sämtlicher technischer Artefaktewird, wo möglich, verzichtet. Die fortge-schriebene Basiskonfiguration wird opti-malerweise in einem ausführbaren Mediumvorgehalten. Es existieren also keineParallelwelten zwischen realen Praktikenund in MS-Office beschriebenen Zielvor-stellungen.

CI kann verhältnismäßig kostengünstigaufgesetzt werden und ist deutlich effizien-ter, als wenn versucht wird, durchMaßnahmen Fehler im Code per se gänz-lich zu verhindern oder Fehler erst deutlichspäter nach der eigentlichen Entwicklungzu identifizieren. Lange Build-Zeiten – bei-spielsweise resultierend aus der Einbindung

Code einchecken. So gehören Pre-Checkin-Tests zum guten Ton, um vorder Bereitstellung von Quellcode dasDesign und den Code durch Metrikenund Tests zu validieren.

Strategie 3:Kontinuierliche IntegrationEin System der kontinuierlichen Inte-gration (Continuous Integration (CI), vgl.[Duv07]) erstellt fortlaufend Builds derSoftware, lässt Tests laufen und überprüftMetriken. Dabei wird ein Build-Stagingeingeführt und ein Build-Server genutzt.Dies erfolgt auf der Basis von Standards(beispielsweise Unternehmensmetriken),hoher Qualität (kein Staging in einerSituation, in der ein Test nicht erfolgreichdurchlief) und Transparenz (Darstellungder Ergebnisse in einem Wiki oderDashboard).

Die erste Staging-Umgebung ist dabeiden Entwickler-Workspaces direkt nachge-lagert. Sie erstellt beispielsweise bei jedemEntwickler-Commit ein neues Build(Continuous Build) der Komponente. Einnächtlich erstellter Integrations-Build(Nightly Builds, vgl. [Berc03] und[Berk05]) fungiert als „Single Point ofTruth” und ist ein Katalysator für dasRelease. Ein Integrations-Build erzeugtArtefakte, die einerseits in dasKomponenten-Repository eingespielt unddort zur Verfügung gestellt werden und dieandererseits als Grundlage für automati-sche Bewirtschaftungen von Testumge-bungen dienen. Kommen im Workspace inder Regel noch intelligente Testsimu-lationen zum Einsatz (beispielsweise

schwerpunk t

Abb. 3: Strategien und Nutzen eines agilen SCM.

Page 6: SOFTWARE- KONFIGURATIONSMANAGEMENT: MIT AGILEN …huettermann.net/artikel/SCM-Huettermann.pdf · platzumgebung, um ohne Unterbrechungen arbeiten zu können. Sie können in ihrer 12

2 / 2 0 0 9

Entwicklung) bedeutet das nicht, dass alleTests gänzlich nachgelagert durchzuführensind oder dass komplett auf Testen verzich-ten werden muss. Auch einfache Tests kön-nen ausdrucksstark sein und ein aktuellesBlutbild der Software vermitteln. Unter-scheiden Sie hier zwischen funktionalenTests bzw. Akzeptanztests (die überprüfen,ob das Richtige umgesetzt wird, und die alsfachliche Spezifikation dienen können) undModultests (die überprüfen, ob das Richtigeauch richtig gemacht wurde). Smoke-Testsoder Sanity-Checks auf der einen Seite undumfassende Regressions-, Integrations-und/oder Systemtests auf der anderen Seiterunden die Test-Infrastruktur ab.

Die Abdeckung kann ausgebaut werden,indem pro neu gefundenem Fehler ein neuerTest geschrieben wird, der die Fehler-behebung auch direkt validiert. EinEntwicklungsvorgehen wie testgetriebeneEntwicklung bzw. „Test First” (vgl. [Bec02])oder die Spezifikation von Funktionalitätüber fachliche Akzeptanztests fördern dieTestabdeckung und erlauben einen regelmä-ßigen, automatisierten Abgleich zwischenAnforderung und Umsetzung.

Die Testabdeckung kann werkzeugunter-stützt überprüft werden. Die Definitionvon sinnvollen Ziel-Überdeckungsmaßen –genauso wie deren korrekte Interpretation– ist nicht immer einfach. Beim Einsatzeines derartigen Vorgehens entsteht dieGefahr, dass auf die Metrik hin gearbeitetwird und nicht mehr auf das eigentlicheZiel. Dennoch wird eine Messung von denmeisten Teams als hilfreich empfunden.

Tests und Testabdeckung spielen häufigeine entscheidende Rolle beim Aufsetzenvon Quality Gates. Dabei werdenAnforderungen an die Artefakte bzw. Testsund Testabdeckung beschrieben, die überden weiteren Build- und Staging-Verlaufentscheiden können. Viele Projekte habenmit einem „Null-Toleranz”-Vorgehen guteErfahrungen gemacht (Build gebrochen beifehlerhaftem Test, mangelhaften Metrikenoder ungenügender Testabdeckung).

Strategie 5:Regelmäßige BereitstellungSoftware ist nur nutzbar, wenn sie instal-liert bzw. verteilt ist. Spezifikationen oderVersionen in einem Workspace sind keinErsatz für eine verfügbare Version auf einerTestumgebung. Verfügbar ist eine Anwen-dung nur, wenn sie tatsächlich nutzbar ist,wenn also notwendige Datenbestände oderBerechtigungen vorliegen. Das Risiko desAuftretens von Anti-Mustern – wie lange,

nachgelagerte Bing-Bang-Integrations-phasen gegen Ende des Release1) – undnach der Umsetzung aufkommendenKundenunmuts („Das wollten wir doch garnicht!”) kann mit regelmäßiger Bereitstel-lung minimiert werden.

Stakeholder wie Projektleitung, Entwick-ler und Kunde begleiten anhand kontinu-ierlich bereitgestellter Versionen denFortschritt und geben zeitnah Rück-kopplungen. Je häufiger Sie die Softwarebereitstellen, desto schneller werden Fehlergefunden und desto mehr wird dieserBereitstellungsprozess zur täglichen Rou-tine. Regelmäßige, automatisierte Installa-tionen helfen, Defekte im Deployment- undInstallations-Prozess, aber auch in Designund Code zu identifizieren, diese zu glättenund Feedback zum aktuellen Status zuerhalten. Um häufige Bereitstellungen zuermöglichen, sind Sie laut [Nyg07] ange-halten, diese auch tatsächlich gut zumachen. Häufige Bereitstellungen eröffnendirekte, zeitnahe Rückkoppelungen – eineVoraussetzung für stetige Verbesserungen.Wenn eine Bereitstellung hingegen nurumständlich und schmerzvoll möglich ist,entmutigen sie von häufigen Bereitstel-lungen. Dabei ist es allerdings wichtig, dassdie Zielumgebung physikalisch tatsächlichder finalen Umgebung entspricht. Falls Siemit längeren Vorlaufzeiten für Infrastruk-turarbeiten rechnen, nimmt dies noch anBedeutung zu. Auch die Verteilung lässtsich inkrementell und kontinuierlich weiterfortschreiben.

Strategie 6:Komponenten-RepositoryIn Projekt-Landschaften mit heterogenenPlattformen ist es nicht unüblich, viele ver-schiedene Repositorys zu haben, in denen dieArtefakte vorgehalten werden. Opti-malerweise bauen Sie ein „Single Access”-Repository auf – einen zentralen Pool, in demSie die in Ihrem Projekt/Produkt genutzten,QS-gesicherten und bereitgestellten Kompo-nenten in ihren jeweiligen Versionen undAbhängigkeiten vorhalten. Das betrifft auchArtefakt-Typen wie Anforderungsdokumen-te, die Sie ebenfalls über ein VCS zentral vor-halten. Eingebundene Abhängigkeiten liegenim Binärformat und versioniert vor, was fürdie einfache Herleitung eines Workspace aufKnopfdruck Voraussetzung ist. Darüber hin-aus ist es einfach möglich, aus dem zentralen

Repository Komponenten zu entnehmen, bei-spielsweise über eine Web-Page oder Skripte.Das unterstützt nicht nur eine effiziente,reproduzierbare Arbeit, es ermöglicht bei-spielsweise auch die verteilte Entwicklungüber mehrere Standorte hinweg. Die klassi-sche, lückenlose Identifikation von Konfi-gurationselementen wird auf eine pragmati-sche Granularität reduziert, beispielsweiseKomponenten oder in Laufzeitumgebungeninstallierbare Deployment-Einheiten.

Strategie 7:Task-Level Commit & Daily CommitDas Einchecken der Änderungen sollte infein granulare, konsistente Aufgabengeschnitten sein. Mit Hilfe aufgabenorien-tierter Changesets werden die Änderungendurch gleichzeitiges Einchecken und ein-heitliches Versehen mit einem semantischenKommentar (beispielsweise eine Referenzauf ein Ticket, das mit der Änderung abge-arbeitet ist) zueinander in Beziehunggebracht. Changesets umschließen mehrereÄnderungen mit einer atomaren Klammer.Werkzeuge ermöglichen ein Reporting überChangesets bzw. deren Verwaltung.

Ein Einchecken geschieht in regelmäßi-gen, kurzen Abschnitten, mindestens täg-lich (die Hauptlinie ist hier der Synchroni-sierungspunkt). Skeptiker sehen bei hoherEincheck-Frequenz die Gefahr von Sta-bilitätseinbußen. Bei einer agilen Heran-gehensweise werden mehr tägliche Fehlerin der Integration toleriert. Diese reduzie-ren das Risiko, indem Fehler frühererkannt und direkt behoben werden.Checken Sie frühzeitig ein, auch wenn einFeature noch nicht gänzlich umgesetzt wur-de. Je später ein Fehler auftritt, destokostenintensiver ist dessen Lokalisierungund desto teurer die Behebung.

Strategie 8:Standards und QualitätMöchten Sie in schnellen Zyklen Releasesbereitstellen, so müssen Design und Codeeine Qualität besitzen, die dies auch ermög-licht. Qualität ist eine fixe Konstante, dieimmer gleich hoch sein soll. Das betrifftinsbesondere auch Tests: Die Qualität wirdhoch gehalten, indem man die Tests nichtnur automatisiert und kontinuierlich laufenlässt, sondern indem ein Release nur dannals abgeschlossen gilt, wenn alle Testserfolgreich durchlaufen. Regeln für Designund Code werden nicht nur auf (elektroni-schem) Papier beschrieben, sondern siewerden in ausführbare Medien übertragen.Das Ergebnis sind Ausführungen ohne

schwerpunk t

1) Ohne CI ist es wahrscheinlicher, dass solcheProbleme eintreten; mit zunehmender Release-Längeerhöht sich die Wahrscheinlichkeit.

Page 7: SOFTWARE- KONFIGURATIONSMANAGEMENT: MIT AGILEN …huettermann.net/artikel/SCM-Huettermann.pdf · platzumgebung, um ohne Unterbrechungen arbeiten zu können. Sie können in ihrer 12

gehen, so lassen sich eben diese Maßnahmenauch isoliert und von der Umwelt gekapselt(z.B. geschnitten nach organisatorischenEinheiten) durchführen, z. B. durch ein iso-liertes, lokales SCM, das seine Artefakte imvorgegebenen, umschließenden Gesamt-prozess traditionell bereitstellt.

FazitKlassisches Softwarekonfigurationsmanage-ment unterliegt einer Weiterentwicklung,um den Herausforderungen der modernenSoftwareentwicklung zu genügen. AgileStrategien und eine gesamtheitliche Blick-weise – eingebettet in unterschiedliche, sichüberlappende Managementaktivitäten – tre-ten in den Vordergrund. Die integrativeHerangehensweise ist maßgeblich durch dasChange-Management beeinflusst. Signi-fikant für den Erfolg ist es, die individuellenAnforderungen an das SCM zu identifizie-ren sowie das Konzept und die Ziel-vorstellung vor Augen zu haben, um danngeeignete Werkzeuge unterstützend einzuset-zen (vgl. z.B. [Hüt07]). Neben Effektivitätund Effizienz führt dies zum wichtigsten: zuhöherer Kundenzufriedenheit. ■

16 17

üblicherweise den Ressourcen stehen alsodrei Konstanten einer Variable – demRelease-Umfang – gegenüber. KurzeIterationen und Time-Boxing sind Bestand-teil und Basis eines guten Risiko-managements. Auch in einem dynamischenUmfeld sind in einer individuell sinnvollbestimmten Release-Distanz die Anfor-derungen und Rahmenbedingungen relativstabil. Bei hoher Release-Taktung kann einChange-Control-Board im eigentlichenRelease-Management aufgehen.

Agiles SCM einführenSelbstverständlich sind Fragen derEinführung stark von den individuellenRahmenbedingungen und Anforderungenabhängig. Grundsätzlich ist es dann ver-hältnismäßig einfach, eine agile SCM-Umgebung auszurollen, wenn Sie direkt amAnfang der Entwicklung mit den entspre-chenden Maßnahmen beginnen und dieIntegrationsinfrastruktur dann kontinuier-lich und inkrementell ausbauen. Aber auchwährend der Entwicklung lässt sich einSCM umfassend oder in Facetten einführen.Für eine Auswahl der gewinnbringendstenStrategien sind häufig eine Stärken-/Schwächenanalyse und eine Priorisierungvon Vorteil. Die folgenden Punkte könnenSie dabei verzahnt verfolgen:

■ Codeline-Struktur im Repository auf-setzen (insbesondere Verzeichnisse imVCS)

■ Standards aufsetzen (Codeline-Regeln,Design und Code-Policies)

■ Entwicklerarbeitsplätze definieren■ Komponenten-Repository aufsetzen■ Mechanismus aufsetzen, um isolierte

Arbeitsplätze automatisiert zu erstellen■ Build-Prozess erstellen (privaten Build,

Integrations-Build)■ Kontinuierliche Verteilungen/Installa-

tionen verankern■ Tests verankern■ CI-Prozess aufsetzen■ Retrospektiven, Adaption

Auch in einem sehr reichhaltigen, traditio-nellen Umfeld lassen sich viele Strategienohne größere Hindernisse noch zu einemspäteren Zeitpunkt einführen, so beispiels-weise die kontinuierliche Integration, dertägliche Abgleich mit dem zentralenRepository und die regelmäßige Bereitstel-lung von Installationen.

Falls doch Gründe dagegen sprechen, agileSCM-Maßnahmen umfassend und transpa-rent im Kontext des Gesamtprozesses anzu-

Medienbruch. Begleitet wird dies durchdirekte Rückkopplungen und aussagekräf-tiges Reporting.

In einen Integrations-Build eingehängteWerkzeuge ermöglichen die Überprüfungvon Metriken und somit die Validierungder Anforderungen an Design und Code.Software bleibt somit über einzelneReleases hinweg wart- und erweiterbar.Besitzen Sie unterschiedliche Codelinienoder haben Sie unterschiedliche (historischgewachsene) Anforderungen an Kompo-nenten, so prüfen Sie den Einsatz verschie-dener Regelwerke. Ältere Code-Bestand-teile können beispielsweise über wenigerrestriktive Regeln verfügen. Qualität undStandards beginnen im Workspace.Tatsächlich verbindlich und aussagekräftigsind allerdings die Integrations-Builds, daEntwickler möglicherweise doch einge-scheckt haben, obwohl Tests fehlschlugen,Tests/Metriken nicht liefen oder lokalschlichtweg andere Regelwerke im Einsatzsind (was natürlich nicht vorkommen darf,aber nicht ausgeschlossen werden kann).Quality Gates und Null Toleranz sind dieZutaten, um Fehler sichtbar und derenBehebung als hoch priorisierte Aufgabe zusehen. Ansonsten droht die Gefahr, dasseben diese verschleppten Defekte für gefal-lene Termine verantwortlich werden odersich die Kosten der Behebung drastischerhöhen.

Strategie 9:Release-Zyklen und TimeboxingDurch kurze Release-Zyklen erreichen Siezügige Rückkopplungen, eine bessereMessbarkeit des Fortschritts, ein aussage-kräftigeres Blutbild der Software undschnelle, wiederkehrende Synchronisa-tionspunkte zwischen Entwicklern, Archi-tekten, Kunden und anderen Stakeholdern.Jedes Release dient als Kommuni-kationsbasis und Synchronisationspunktzwischen allen Artefakten, Infrastrukturund den Beteiligten. Vor bzw. am Anfangdes Release werden die Release-Inhaltebestimmt, die im Laufe des Release bis zurendgültigen Definition konkretisiert und –wo nötig – interpretiert werden. Die Inhaltewerden während des Release in hoherQualität bereitgestellt. Gelingt dieUmsetzung in dieser Qualität nicht, wirddas Feature in einem nächsten Releaseimplementiert. Im Rahmen des Releasingssind alle Termine fix und allseits bekannt.Die Termine können in einem Release-Kalender festgezurrt und in einem Wikipubliziert werden. Mit Qualität, Zeit und

schwerpunk t

Literatur & Links

[Agi] Das agile Manifest, siehe: agilemanifesto.org/[Bab86-a] W.A. Babich, Software Configura-tion Management, Addison-Wesley, 1986[Bab86-b] W.A. Babich, Software Configura-tion Management: Coordination for TeamProductivity, S. 7, Addison Wesley, 1986 (einImprint von Pearson Education)[Bec02] K. Beck, Test Driven Development:By Example, Addison-Wesley, 2002[Berc03] S. Berczuk, B. Appleton, SoftwareConfiguration Management Patterns, Addison-Wesley, 2003. S. 97ff.[Berk05] S. Berkun, The Art of ProjectManagement, O‘Reilly, 2005[Bro95] F.P. Brooks, The Mythical Man-Month: Essays on Software Engineering, 20thAnniversary Ed., Addison-Wesley, 1995[Coc07] A. Cockburn, Agile Software Devel-opment, Addison-Wesley, 2007, S.370ff.[Duv07] P. Duvall et al., Continuous Inte-gration: Improving Software Quality andReducing Risk, Addison-Wesley, 2007[Has03] A. Hass, Configuration ManagementPrinciples und Practices, Addison-Wesley,2003, S. 159ff.[Hüt07] M. Hüttermann, Agile Java-Ent-wicklung in der Praxis, O'Reilly, 2007[Nyg07] M. Nygard, Release It!, ThePragmatic Bookshelf, 2007[Wei98] G. Weinberg; The Psychology ofComputer Programming, Dorset House, 1998