Gelebte Architektur und ALM in der Praxis...von der Management-Ebene bis zu technischen Details. Wir verwenden und arbeiten mit Source Control, Work Items, Collaboration Features,

© AIT GmbH & Co. KG Ihre Software effizienter entwickelt

Gelebte Architektur und ALM

in der Praxis


9:00 Begrüßung und Einleitung, Erwartungshaltung

9:15 Build- und Dependency-Management mit dem TFS

11:00 Q&A

11:30 Anforderungen an moderne Software

12:00 Mittagspause

13:00 Demo: Analyse einer typischen Anwendung

14:30 Pause

14:45 Demo: Per Refactoring zur besseren Architektur

16:30 Zusammenfassung und Q&A

17:00 Ende

2

Agenda


„Moderne Software stellt oft hohe Anforderungen an Themen wie Modularität, Flexibilität und

Erweiterbarkeit. Häufig ändern sich Anforderungen während der Entwicklung oder ganz neue kommen

hinzu. Die spätere Anbindung von zusätzlichen Clients muss ebenso vorgesehen werden wie die

Möglichkeit, einzelne Komponenten der Software auszugliedern um sie beispielsweise in der Cloud zu

betreiben. Plötzlich werden Fragen zur getrennten Versionierung und separatem Deployment

aufgeworfen; eventuell werden einzelne Teile der Anwendung gar von unterschiedlichen Teams

bearbeitet, was ebenfalls in der Struktur berücksichtigt werden muss. Der Workshop zeigt verschiedene

Möglichkeiten, solche Aspekte durch eine robuste Architektur abzufedern. Es wird diskutiert, wie

Werkzeuge bei solchen Fragestellungen zusätzlich unterstützen können, und natürlich wie der Team

Foundation Server als zentrale Schaltstelle Teams und die gewählte Architektur bei der Entwicklung

unterstützt.“

3

Abstract


Nach zwei Tagen ALM Days 2012 sind wir geschult in

Entwicklungsprozessen und den involvierten Werkzeugen,

von der Management-Ebene bis zu technischen Details.

Wir verwenden und arbeiten mit Source Control, Work Items,

Collaboration Features, Metriken, Reporting, Test-Tools, Build-

Prozessen und –Skripts.

Wir kennen alles von A wie Anforderungsmanagement bis Z wie

zünftiges Continuous Integration…

4

Zielsetzung des Workshops (1)

Wo ist eigentlich die Software?


Rückbesinnung auf die Entwicklung

Was bedeutet ALM eigentlich für die Software-Entwicklung?

Warum werden Aspekte des ALM immer wichtiger für Software?

Was kann ich als Architekt und Entwickler tun, um meine Software fit zu machen für diese Anforderungen?

5

Zielsetzung des Workshops (2)


Demo: Build- und Dependency-

Management mit TFS (Sven Hubert)

© AIT GmbH & Co. KG Ihre Software effizienter entwickelt 7

Team Project Folder Structure

NetFactory

NetFactory

Features

NetFactory Trending

NetFactory Reporting

Main

NetFactory

Releases

NetFactory 1.0

NetFactory 2.0


Branch Folder Structure

NetFactory

Libraries

Scripts

Sources


Branch Folder - Libraries

NetFactory

Libraries

Telerik.2.0.0.3455

lib

net35

net4

sl4

doc

SharpZipLib.2.6.0.0

lib

sl4-wp71

winrt45

sources

Scripts

Sources


Branch Folder - Scripts

NetFactory

Libraries

Scripts Build.bat Fast, parallel build without any checks ->create executables fast

Cleanup.bat Deletes all project specific build artifacts.

Rebuild.bat Runs a Clean before a Build.

GetLatest.bat Copies latest build result into local output folder

incremental builds.

Sources


Release Branching - Basic

B

RI

B FI

RI

FI FI B

RI

Emergen

cy Hotfix


Feature Branching

RI

RI

RI

FI FI B FI FI FI B


Flexibilität

Neue fachliche Anforderungen

Unterstützung neuer Plattformen (Mobilgeräte, Webclients etc.)

Änderungen in der Architektur (z.B. Integration in die Cloud)

Dynamisierung von Anwendungen (z.B. durch Lizenzmodelle)

Wartbarkeit

Geänderte Anforderungen

Personalwechsel/Ressourcen-Shuffle im Team

Robustheit

Kapselung von Funktionalität (Komponenten)

Testbarkeit

Stabile Performance und Skalierbarkeit

13

Moderne Anforderungen (1)


Getrieben werden diese Anforderungen oft

stark getrieben durch äußere Einflüsse, z.B.:

Kostenfaktor

Time to market

Konkurrenzfähigkeit

Kundenzufriedenheit

Usability

14



Auswirkungen im Sinne von ALM:

Getrennte Versionierung von Komponenten

Dynamische Frameworks

(Plug-In-Architekturen u.ä.)

Paralleles Arbeiten mehrerer Teams

Veränderte Deploymentstrategien

15



Auf den Punkt gebracht:

Software soll effizienter entwickelt werden:

Gleiche Qualität in kürzerer Zeit

Höhere Qualität in gleicher Zeit

Beides

16



Klassische Modelle nutzen „Big Design Up Front“

Zeitraubend

Zu schwerfällig

Realität ist zu komplex

17

Problem:

www.integrativebiology.ac.uk/softarch.html


Agile Methoden

Leichtgewichtig

Flexibel

18

Lösung(?): Änderung der Prozesse

Working Software


Idee: Emergent Architecture

Probleme: Mangelhafte Umsetzung von Agilität („Hackerteams“),

fehlende Erfahrung, fehlendes Verständnis von Technologie, zu

großer Zeitdruck, …

Ergebnis:

19

Aber:

Wie funktioniert Architektur in agil?


Agile Entwicklung entbindet nicht von der Beschäftigung mit Architektur und Design

Denken und Planen in Pattern bzw. aktives Beschäftigen mit Designprinzipien ist notwendig

Refactoring als Mittel der Wahl kann genutzt werden, um Emergent Architecture zu leben (Zeit einplanen!)

20

Postulat


Demo: Analyse einer Anwendung


• Vermischung von Anwendungslogik und Datenzugriffschicht

• Vermischung fachlicher Logik und Anwendungslogik

• „Bleeding“ von Datenzugriffstechnologie bis in die Oberfläche

• Logisch zusammenhängende Teile auf die gesamte Anwendung verteilt

• Code-Duplication

• Austausch des Front-Ends (z.B. Windows Phone, Webclient) nicht möglich

• Testbarkeit extrem eingeschränkt (nur Integrationstests)

• Physikalische Aufteilung erschwert getrennte Versionierung von Komponenten

• Physikalische Aufteilung erschwert Einsatz von Werkzeugen (z.B. Architekturvalidierung)

22

Probleme der Beispielanwendung


Konsequentes Nutzen bewährter Prinzipien objektorientierter Programmierung, insbesondere SOLID

Unterstützung durch passende Patterns, beispielsweise Dependency Injection, Specifications, Unit of Work/Repository

Nutzen der vorhandenen Werkzeuge: Architekturvalidierung, Statische Code-Analyse, Metriken usw.

23

Wie kann Abhilfe geschaffen

werden?


Zur Erinnerung: SOLID

O

S

L

I

D

Single Responsibility There should never be more than one reason for a class change.

Open/closed Principle A module should be open for extension but closed for modification.

Liskov Substitutability Principle Subclasses should be substitutable for their base classes.

Interface Segregation Principle Many client specific interfaces are better than on general purpose

interface.

Dependency Inversion Principle Depend upon Abstractions. Do not depend upon concretions


Demo: Refactoring zum Guten


Entkopplung und Kapselung von

Funktionalitäten

Modularisierung der Anwendung

Testbarkeit auf verschiedensten Ebenen

Deutliche Verbesserung der Flexibilität,

Robustheit und Wartungsfreundlichkeit

26

Ergebnisse


Offene Diskussion


Buchempfehlungen

Continuous Delivery: Reliable Software Releases Through Build, Test,

and Deployment Automation

Ein empfehlenswertes Buch für alle technischen Projektleiter sowie Release- und Build-Manager, die

Continuous Integration als erste Stufe hin zu ständigen kurzfristigen Releases gemeistert haben und

bereit für den nächsten Schritt sind. Es behandelt neben Configuration Management und

Deployment-Themen auch Test und Dependency Management. Auch die notwendigen Prozesse im

Projekt- und Risiko-Management werden angesprochen.

Inside the Microsoft Build Engine: Using MSBuild and Team

Foundation Build

Eine wahre Pflichtlektüre für Build-Administratoren und Entwickler, die mit dem eigentlichen Bau der

Software im Sinne des Build zu tun haben, ist dieses Buch. Es behandelt MSBuild als Basisplattform

für den Bau von .NET-Solutions sowie Team Foundation Build und die verwendete Workflow

Foundation. Auch die für .NET 4.0 neu aufgelegte zweite Edition enthält allein schon in der Einleitung

wichtige Tipps und Tricks. Weitere Infos dazu gibt es hier.

http://amzn.to/h9z3rs



http://amzn.to/e8HdeY

http://amzn.to/e8HdeY

http://www.tfsblog.de/2011/01/06/buchempfehlung-inside-the-microsoft-build-engine-2nd-edition/


Whitepaper: Unternehmensweite Build-Prozesse

Activity Development Tutorial

Simple Team Build Activity sample

Writing code activities

Thema Build im TFS Blog

Team Foundation Build Customization Guide

29

Weiterführende Links (1)

http://www.aitgmbh.de/downloads/whitepaper/unternehmensweite-build-prozesse.html




http://www.ewaldhofman.nl/post/2010/04/20/Customize-Team-Build-2010-e28093-Part-1-Introduction.aspx

http://geekswithblogs.net/jakob/archive/2009/08/13/tfs-team-build-2010-working-with-custom-code-activities.aspx






http://blogs.msdn.com/bursteg/archive/2009/05/19/wf-4-0-code-only-custom-activities-for-atomic-actions-codeactivity-codeactivity-t.aspx




http://blog.aitgmbh.de/tag/build/




http://vsarbuildguide.codeplex.com/


AIT Dependency Manager

Create NuGet Packages

Whitepaper: Code Sharing

30

Weiterführende Links (2)

http://aitgmbh.de/dependencymanager




http://www.hanselman.com/blog/CreatingANuGetPackageIn7EasyStepsPlusUsingNuGetToIntegrateASPNETMVC3IntoExistingWebFormsApplications.aspx




http://blogs.msdn.com/b/cbinder/archive/2010/11/17/code-sharing-mit-tfs-2010.aspx


Kontakt

Sven Hubert

[email protected]

Peter Kuhn

[email protected]

AIT GmbH & Co. KG http://www.aitgmbh.de

http://www.tfsblog.de

Documents

Gelebte Architektur und ALM in der Praxis...von der Management-Ebene bis zu technischen Details. Wir verwenden und arbeiten mit Source Control, Work Items, Collaboration Features,