Ein agiles Projekt mit dem RedSpark Framework von A bis Z

Agil mit Stil
Kommentare

Versionierung
Jede Library und jede App einer RedSpark-Installation kann in verschiedenen Versionen auf dem Server hinterlegt werden. Zum Beispiel das Zend Framework in Version 1.11.0, die RedSpark Library

Versionierung

Jede Library und jede App einer RedSpark-Installation kann in verschiedenen Versionen auf dem Server hinterlegt werden. Zum Beispiel das Zend Framework in Version 1.11.0, die RedSpark Library 1.3.2, die Apps RedSparkCore und RedSparkBlog in den Versionen 1.2.2 bzw. 1.0.0). Alle so hinterlegten Versionen entsprechen in der Regel gleichlautenden Tags im Subversion. Auf gleiche Weise können demnach auch Branches oder der Trunk als „Version“ eingebunden werden. Im Fall des Trunk gilt die Konvention, dass dieser als Ordner mit dem Namen latest abgelegt wird. In der Projekt-App werden die Abhängigkeiten dann jeweils genau gegen eine spezielle Version gelinkt:

[Libraries] 
Redspark = "latest"; 
Zend = "1.10.0"; 
Smarty = "2.6.26"; 

[Applications] 
RedSparkCore = "1.2.2"; 
RedSparkBlog = "1.0.0";

Auch die Projekt-App sollte demnach immer nur in versionierter Form abgelegt werden. Für die Entwicklung der App im stets aktuellen Trunk wird dieser z. B. als latest abgelegt. Sämtliche Meilensteine und Zwischenabnahmen sollten mit 0.x.x Tags versehen und die erste finale Version schließlich als 1.0.0 abgelegt werden. Da jede dieser Versionen die Abhängigkeiten neu festlegt, ist es möglich, jedes Release der App mit fest definierten Library- und App-Abhängigkeiten zu verknüpfen (Abb. 3).

Upgrade

Ein späteres Upgrade der Projekt-App erfolgt unter Nutzung der obigen Möglichkeiten wie folgt – siehe dazu auch [10]:

  • Festlegung neuer Abhängigkeiten zur jeweils aktuellen Version fremder Libraries und Apps.
  • Weiterentwicklung neuer Funktionen im Trunk.
  • Testing und Abnahme der neuen Funktionen.
  • Fixierung der Änderungen über ein neues Tag, zum Beispiel 1.1.0.
  • Upload aller nötigen Libraries und Apps sowie des neuen Tags der Projekt-App.
  • Test über spezielle URLs: /(AppName)/(Version)/.
  • Umschaltung der Version in der Datei /config/bootstrap.ini.

Abb. 3: Versionierung im RedSpark FrameworkAbb. 3: Versionierung im RedSpark Framework (Vergrößern)

Fazit

Jedes Projekt hält individuelle Anforderungen bereit, will aber auch auf Standardkomponenten nicht verzichten. Dieser Erfahrung tragen die Konzepte hinter dem RedSpark Framework Rechnung und versuchen, beiden Anforderungen gerecht zu werden. Das hier beschriebene Projektvorgehen ist sicher nicht für jedes Projekt in Gänze angemessen, es stellt aber für Projekte mittlerer Größe das unserer Erfahrung nach erfolgversprechendste Vorgehen mit einem möglichst reibungslosen Projektablauf bei höchst möglicher Qualität dar. Der Fokus auf agile Ansätze ist derzeit in aller Munde. Das RedSpark Framework bietet, neben dem vereinfachen Einstieg in die Entwicklung mit dem Zend Framework [6], auch in Bezug auf die agilen Entwicklungsmethoden die Möglichkeit, diese Stück für Stück (besser: Projekt für Projekt) einzuführen, ohne die Effizienz bei der Projektdurchführung außer Acht zu lassen. Letztlich startet man bereits im ersten Projekt mit RedSpark nicht „auf der grünen Wiese“, sondern direkt mit einem Backend für die eigenen Entwicklungen sowie einem etablierten CMS im Rücken. Zur Not findet sich zudem in der Community meist eine Firma oder ein Entwickler, die in den ersten Projekten unterstützen können.

alt=“Till Kubelke“ height=“100″ />

AUTORENKURZBIO

Till Kubelke ist Gründer und Geschäftsführer der Kuborgh GmbH und hier unter anderem verantwortlich für Entwicklung und Strategie des RedSpark Frameworks. Er studierte Wirtschaftsinformatik an der Fachhochschule Wedel und ist seit 1997 im IT-Bereich tätig.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -