Marko Apfel - Afghanistan/Belgium/Germany

Management, Architecture, Programming, QA, Coach, GIS, EAI

  Home  |   Contact  |   Syndication    |   Login
  187 Posts | 2 Stories | 201 Comments | 4 Trackbacks

News



Twitter | LinkedIn | Xing

Archives

Post Categories

Image Galleries

BizTalk

C#

Enterprise Library

SAP

SQL Server

Technologie

Motivation

Kommen Ihnen diese Szenarien bekannt vor:

  • der Build scheitert, weil ein Kollege ein 3rd Party Framework eingeführt hat und nur lokal auf seiner Maschine die benötigten Bibliotheken installiert sind
  • der Build scheitert weil ein 3rd Party Framework auf einigen Maschinen in anderen Versionen vorhanden ist und sich damit die Datei-Versionen und -Funktionalitäten der Bibliotheken unterscheiden
  • das Build-Ergebnis unterscheidet sich auf verschiedenen Maschinen weil jeweils andere Toolsets in die kompilierende Umgebung eingebunden sind (Code-Weaver und -Analysierer, die als Plugin in Visual Studio installiert sind)
  • die benötigten Fragmente für ein aktuell benötigtes MSI-Setup (z.B. PDF-Dokumentationen) liegen in der Verantwortlichkeit eines Kollegen, der diese Dateien auf seinem Laptop hat, mit welchem er gerade unterwegs ist
  • nach der Inbetriebnahme einer neuen Maschine sind stundenlange Installationsopern notwendig um wieder am Projekt mitarbeiten zu können
  • die ausgerollte Software läuft beim Kunden nicht, weil Bibliotheken in der Applikation referenziert wurde, welche nicht im Standard-Installationsumfang beim Kunden sind

Root Cause Analysis

Was ist der Grund all dieser und verwandter Probleme?

Begeben wir uns auf die Suche nach der Ursache – lassen Sie uns eine Root Cause Analysis durchführen.

Schnell kommt man zum Ergebnis, dass all die benötigten Fragmente (Bibliotheken, Dokumente, Sourcecode, ..) als ein Bündel vorliegen sollten – und das natürlich an einem zentralen Ort, zu welchem alle Projektbeteiligten einen Zugriff haben.

Idealerweise ist dieser Ort ein Versions-Repository wie SubVersion, Git oder Co.

Dieses Bündel nennen wir Development-Tree oder kurz DevTree.

DevTree

Mit dem Vorhandenseins eines vollständigen DevTree erlaubt ein einzelner Checkout das sofortige Mitarbeiten im Projekt – egal, ob für neue Kollegen, neue Maschinen, neue Bibliotheksversionen und sonstige Änderungen.

Getreu der Devise: “one single checkout should start you up!“

Für den Aufbau eines derartigen DevTree gibt es etliche Beispiele in der Literatur (beispielweise CI-Factory1 oder Tree Surgeon2).

Am Standort Kranzberg der ESRI Deutschland GmbH haben wir ein eigenes Schema etabliert, welches ideal für die Belange in unseren .NET-Projekten ist.

Realisierung

Die adressierten Aspekte sind dabei teilweise völlig unterschiedlicher Natur.

Sie umfassen nicht nur die oben genannten anschaulichen Konflikte der Versionierung, des Setups oder des Toolsets.

Auch die verschiedenen Phasen in der Software-Entwicklung wie Architektur und Implementierung werden durch eine stärkere Trennung in Interface- und Implementierungs-Komponenten direkt auf Bibliotheks- und Berechtigungsebene physisch im Dateisystem unterstützt (u.a. forciert im blauen Grad des CCD3)

Des Weiteren orientieren wir uns bei der Zerlegung in Komponenten stark an den Prinzipien des Clean Code Development4 und diverser Pattern. Insbesondere SOC5, SRP6, CCP7 und CRP8 geben uns dabei die Kriterien vor.

Darüber hinaus berücksichtigt dieser DevTree natürlich auch das Release Management von ArcObjects-Bibliotheken.

Ausblick

Hat man innerhalb der Entwicklergruppe für typische eigene Projekten einen Konsens über die Struktierung und Umfang der benötigten Bibliotheken gefunden, kann man diesen DevTree selbst auch als Template-DevTree in ein Repository stellen und bei Bedarf für neue Projekte unversioniert heraus kopieren.

Bei SubVersion heißt dieser Befehl „Export“ und mit ihm wird der jeweilige Inhalt unterhalb der exportierten URL auf die eigene Festplatte übernommen und kann von dort aus wiederum als initiales Checkin in ein neues Projekt-Repository aufgenommen werden.

Unser Template umfasst u.a.

  • Bibliotheken für Unit-Test, Mocking, Logging, IoC-Container, ..
  • MS-Build Targets für statische Codeanalysen mit StyleCop, FxCop, ..
  • Build-Tools wie Doku-Compiler, NAnt, ILMerge, ..
  • ArcObjects-PIAs (Bibliotheken)

Die ArcObjects-Bibliotheken sind u.a. deswegen in den DevTree aufgenommen worden, damit wir auf einem weitgehend installationsneutralem Continuous-Integration-Server9 einen interferenzfreien Build durchführen zu können.

Ein derartiger CI-Server sichert uns zu, dass wir keine Fremd-Bibliotheken versehentlich referenzieren, die auf den Rollout-Maschinen nicht vorhanden sind. Ein entsprechender Build-Break würde uns auf diese Referenzen aufmerksam machen.

Zusammenfassung

Ein sinnvolles Ablegen von Software-Entwicklungs-relevanten Artefakten bildet eine der Grundlagen für eine effektive Zusammenarbeit von Kollegen und eine effiziente Evolvierbarkeit der Software.

Die Mühe einen möglichst generischen DevTree aufzubauen lohnt sich aus verschiedenen Blickwinkeln. Die technischen Blickwinkel wurden schon kurz angerissen – organisatorische gibt es auch. Man vergleiche mal die 5S-Methologie10 im Kaizen11.

Das hier angekündigte Whitepaper „Aufbau eines pragmatisch smarten DevTrees“ kann in hier oder unter support.esri.de heruntergeladen werden.

 

[1] CI Factory
http://cifactory.org/joomla/

[2] Tree Surgeon Project
http://treesurgeon.codeplex.com/

[3] CCD – blauer Grad
http://www.clean-code-developer.de/Blauer-Grad.ashx

[4] Clean Code Developer
http://www.clean-code-developer.de/

[5] SOC – Separation Of Concerns
http://en.wikipedia.org/wiki/Separation_of_concerns

[6] SRP – Single Responsibility Principle
http://en.wikipedia.org/wiki/Single_responsibility_principle

[7] CCP – Common Closure Principle
http://ifacethoughts.net/2006/04/08/common-closure-principle/

[8] CRP – Common Reuse Principle
http://ifacethoughts.net/2006/04/05/common-reuse-principle/

[9] CI – Continuous Integration
http://de.wikipedia.org/wiki/Kontinuierliche_Integration

[10] 5S-Methologie

http://de.wikipedia.org/wiki/5S

[11] Kaizen
http://de.wikipedia.org/wiki/Kaizen

posted on Wednesday, June 15, 2011 11:46 AM

Feedback

# re: Whitepaper “Aufbau eines pragmatisch smarten DevTree“ 6/15/2011 4:15 PM essay jobs
Very useful post! Thanks for author.

Post A Comment
Title:
Name:
Email:
Comment:
Verification: