Die Entwicklung

NextDie durchgängige Modularität der Enterprise Apps führt besonders in der Entwicklung zu einer starken Vereinfachung in Bezug auf Strukturen, Verfahren und Werkzeuge. Denn jedes Enterprise Apps Modul ist einfach ein Standard Projekt einer beliebigen Entwicklungsumgebung, das auch als solches in einem Sourcecode bzw. Version Management System verwaltet wird.

Damit sind drei zentrale Eckpunkte einer Entwicklung festgelegt (Beispiele hier zur Demo auf unterschiedlichen Systemen SVN, Git Hub)

ModulesInDevelopment

Der entscheidende Unterschied zu vielen anderen Verfahren ist der, dass in allen Bereichen der gleiche Gegenstand, das versionierte Modul, gehandhabt wird und dadurch auch alle Strukturen, Verfahren und Arbeitsabläufe für alle Anforderungen1 gleich und automatisch im Vorfeld definiert sind (siehe auch Architektur out of the box).

Das vereinfacht insbesondere die Bereiche Dependency- und Sourcecode Management.

  • denn zum einen gibt es nur noch systeminterne Dependencies zwischen Modulen – die vom System automatisch selbst gehandhabt werden2
  • und zum anderen arbeitet die Entwicklung nicht mehr auf einer einzigen, allumfassenden Code Basis in die Neuerungen und Änderungen über komplexe Branching und Merge Verfahren eingebracht werden müssen

Stattdessen arbeitet ein Entwickler immer auf abgegrenzten, einzelnen Modulen, die durch ihre Versionierung ebenfalls keine Branching/Mergingproblematik mehr aufweisen – weil eine Änderung hier immer eine neue Modulversion bedingt und damit ein neues Modul ist3.

Dieser Aufbau vereinfacht nicht nur die Realisierung beliebiger Anforderung in der Entwicklung – sonder ermöglicht es auch Teams und Teamgrößen schnell und flexibel skalieren zu können.

Zum einen weil die Einarbeitung neuer Mitarbeiter sehr einfach ist und zum anderen, weil alle benötigten Werkzeuge sehr leicht zu einem vollständig vorkonfigurierten Standard Tool Stack (IDE, Strukturen, VCS, Planning, Tracking, Collaboration etc.) gebündelt werden können. Dabei wirkt das Modul in allen Bereichen als Identifikationspunkt und Strukturgeber – sodass es keine Brüche mehr gibt und eine sehr hohe Allgemeinverständlichkeit entsteht.

Apps in der Java Entwicklung
In der konkreten Java Entwicklung ist ein App Modul ein Standard Java Projekt einer beliebigen Java IDE (z.B. Eclipse oder NetBeans etc.). Dabei werden weder spezielle Projektstrukturen noch IDE spezifische PlugIns oder andere Tools benötigt.

Die Nutzungsabhängigkeiten zwischen Modulen (Imports) zum Compilieren und Debuggen werden wie gewohnt mit den Projektverknüpfungsmitteln der jeweiligen IDE realisiert, wodurch sich die Entwicklung von Apps Modulen nicht von der Entwicklung von Standard Java Programmen unterscheidet – egal ob Client oder Server.

Das Ergebnisartefakt eines Apps Projektes ist immer die entsprechende Modul Jar-Datei im Modul Repository, das sowohl für Entwicklung und Laufzeit als auch für Client und Server das gleiche ist. So werden fehlerträchtige Redundanzen vermieden und weder der Entwickler noch Tools müssen sich um Dinge wie Paketierung, Deployment oder Installation kümmern – sie sind einfach nicht mehr notwendig.

Für die automatische Generierung der Modul Manifestdatei mit ihren spezifischen Modulinformationen wie z.B. Name, Version, Imports (Dependencies) etc. und einem entsprechenden Buildpath bietet das System einen eigenen kleinen Ant Task.

Die Technik ist einfach, robust und universell. In der Entwicklung wird pro Modul eine Manifest Sourcecodedatei (MANIFEST.MF.src) gepflegt, die alle benötigten Info-Tags enthält. Der Ant-Task (oder ein anderes Tool z.B. JavaScript) ließt die Datei am Beginn eines Modul-Builds und generiert mit ihren Informationen die eigentliche Manifestdatei sowie den benötigten Buildpath für den Compiler. Auf diese Weise sind die Informationen zentral und redundanzfrei (DRY Prinzip) abgelegt und stehen zudem automatisch unter der notwendigen Sourcecodeverwaltung.

Um damit auch einen IDE unabhängigen automatisierten Build “out of the box” zu ermöglichen bietet ISA noch zwei sehr einfache, globale Ant Scripte (global bedeutet: es gibt sie nur einmal, sie gelten für alle Module)

  • das eine Script definiert eine Handvoll Properties für Dinge wie feste Verzeichnisse und Namen etc.
  • das zweite Script definiert darauf aufbauend einfache, standardisierte Ant Tasks für die Compilierung und die Jar-Erstellung etc. Diese Tasks sind einfach, weil sie keine Logik oder Wissen über ISA enthalten. Sie dienen nur zum Aufruf von Werkzeugen wie Compiler oder Jar-Packager etc.. Dadurch kann der Build auch leicht mit anderen Mitteln oder Scriptsprachen realisiert werden.

Ein konkretes Apps Projekt braucht damit nur noch ein zum Projekt selbst vollständig bezugloses, “leeres” Standardscript, das das globale Scrip importiert um auf Knopfdruck gebaut werden zu können.

Auf diese Weise lassen sich Apps Modul Projekte in und aus jeder Umgebung heraus standardisiert und automatisiert bauen – ohne dass für ein Modul zusätzliche individuelle Informationen (z.B. pom.xml o.ä.) oder Scripte erstellt und gepflegt werden müssen. Alle notwendigen Informationen stehen im Source Manifest – das jedem Werkzeug und jeder Umgebung zugänglich ist.

Das eröffnet sowohl einen unabhängigen, leichten und flexiblen Einstieg in die Apps Entwicklung als auch eine problemlose Ausbau- und/oder Integrationsfähigkeit in bestehende Verfahren und Landschaften. Die Struktur ermöglicht zudem die Optimierung von Continuous Integration Verfahren, weil die Module viel schärfere Grenzen zwischen kleineren Einheiten bilden.

Eine Standard Projektstruktur (z.B. Eclipse)
(Beispiel: isa.TestService)

JavaAppsProject

______________________

1: Für alle Anforderungen – weil Module durch ihre Technologieunabhängigkeit jede beliebige Anforderung aus allen Bereichen (Client, Server, Integration, Web etc.) umsetzen können.

2: Mit ISA verschwindet die gesamte Thematik Dependency Management aus der Entwicklung – weil es in ISA kein Thema des Buildprozesses ist – sondern eine wichtige und automatisierte Kernaufgabe des modularen Systems selbst. Die Abhängigkeitsinformationen befinden sich daher auch redundanzfrei an nur einem Ort – dem Modul selbst (MANIFEST.MF.src).

3: Eine neue Modulversion ist im Prinzip ein “Branch”, ein neuer Zweig, der Vorgängerversion – der aber im ISA Modulsystem konsistent vom Sourcecodemanagement bis zum Betrieb reicht, weil er eine konstruktiv/strukturelle Eigenschaft eines Moduls selbst ist – und kein Verfahren der Codeverwaltung (siehe auch Versionslogik).

Ein weiterer wichtiger Punkt bzgl. der vereinfachten Codeverwaltung ist der, dass Konflikte durch parallele Bearbeitung von Sourcecode bereits durch die Modulgrenzen stark minimiert werden. Zum Vergleich: In monolithischen Strukturen ist immer der gesamte Sourcecode potentiell für Änderungen zugänglich – in ISA ist das Modul eine Grenze – denn der Code eines anderen Moduls kann nicht geändert werden – es muss nach der Logik der Module immer eine neue Modulversion erstellt werden.

Die Modulgrenze schützt und befreit zugleich – weil die Entwicklung innerhalb eines Moduls völlig autark bzw. unabhängig ablaufen kann und dabei gleichzeitig vor Änderungen von außen geschützt ist.

Darüberhinaus macht die Modulgrenze auch die Planung und das Controlling leichter – weil immer genau bekannt ist wer an welchen Modulen arbeitet (siehe auch agile, iterative Vorgehen und Modulspezifikation).