Versionen in Subversion

Die Versionierung in RedSpark ist eng mit der Subversion Versionsverwaltung verknüpft. Sowohl die RedSpark Library, als auch die RedSpark Apps nutzen den vollen Subversion Funktionsumfang wie "trunk", "tags" und "branches". 

Für weiterführende Infos sei hier auf die offizielle Subversion Webseite verweisen: Subversion.

Library und RedSparkCore App

Die Library und die RedSparkCore App sind Basis für die meisten Kunden-Apps, sie unterliegen daher einer besonderen, auf Stabilität ausgerichteten, Versionierung. Diese Versionierung stellt insbesondere sicher, dass die Kunden-App während der Entwicklungszeit gegen einen stabilen Stand (z.B. 1.2.x) von RedSparkCore und Library entwickelt wird, aber zusätzlich von aktuelle Bugfixes für 1.2.x profitiert. Beim Release der Kunden-App besteht dann die Möglichkeit, den Stand der Library und RedSparkCore zusätzlich gegen einen festen Tag (z.B. 1.2.5) zu linken, dies bring noch einmal mehr Stabilität.

Die Strategie ist an die Strategie des ZEND Framework angelehnt, hierzu ist die folgende Seite sehr interessant: ZEND Subversion Standards.

Subversion Struktur

Die Strategie sieht im Einzelnen wie folgt aus:

/trunk

Der Trunk dient für neue Features und stellt stets den aktuellen Entwicklungsstand dar. Der Trunk ist jedoch nicht immer ausführlich getestet und dokumentiert und daher ggf. instabil.

Nutzbar für:
  • Nur für Entwicklung zu empfehlen!
  • Nicht für Projekt- und abhängige Apps in Livesystemen geeignet.
  • Eine Referenz auf eine /trunk, also "latest" Version sollte nur per develop.ini, nicht über die Config.ini der App erfolgen.
  • Alle neuen Features für Library und RedSparkCore werden im Trunk entwickelt, um diese zu nutzen muss die App daher gegen den Trunk verlinkt werden.

/branches

Branches bieten stets stabile Stände eines Major Release (z.B. 1.2.x), enthalten aber keine neuen Features. Apps werden meist gegen den gewünschen "stable-branch" der Libraries (ZEND und RedSpark) und RedSparkCore entwickelt. Branchens werden zudem für große Umbauten genutzt, die ggf. über längere Zeit entwickelt werden.

Empfohlen für:
  • Bei der Projektapp: Branches ratsam für Deployment von Testversionen auf den Liveserver. Es sind noch weitere Bugfixes möglich.
  • Bei verlinkten Apps und Libraries: Branch ist ein dauerhaft stabiler Stand inkl. Bugfixes, aber ohne neue Features.

/tags

Tags sind fixierte Versionen von Libraries und Apps. Tags stellen ein Minor-Release dar und sollten nach Abschluss der Testphase zum Release einer neuen Version des Projekts erstellt werden. Tags sind verhältnismäßig "billig" und sollten daher häufig genutzt werden. Ein Projekt kann jederzeit auf den Stand eines Tags zurückgeführt werden.

Empfohlen für:
  • Deployment eines Updates auf kritischen Livesystemen nach Abschluss der Testphase mit einem Branch.
  • Sofern keine Weiterentwicklung (auch vorübergehend) in dem Projekt geplant ist.
  • Tags sind "geschlossen". Es sollten keine nachträchlichen Änderungen commited werden (Ausnahme: komplett unkritische Bugfixes)

Vorgehen bei Entwicklung

Das Vorgehen beispielhaft erläutert anhand einer eigenen App und dem verlinkten RedSparkCore.

  • Initiale Entwicklung 
    • Entwicklung "MyApp": /trunk (entspricht "latest")
    • RedSparkCore: aktuellster stabilen Branch (z.B. /branches/1.2.x).
    • Library (ZEND und RedSpark): aktuellster stabilen Branch (z.B. /branches/1.2.x).
  • 1. Testversion
    • Deploy /branches/1.0.x
    • Bugfix /branches/1.0.x + Merge des Bugfix aus /trunk
    • Entwicklung (Faustformel: < 1 PT) /branches/1.0.x + Merge des Bugfix aus /trunk
  • 1. Livestellung
    • Deploy /tags/1.0.0
  • Neues Feature
    • Entwicklung (Faustformel: > 1 PT) /trunk
  • Bugfix für alte Version
    • Bugfix /branches/1.0.x + Merge des Bugfix aus /trunk
    • Deploy /tags/1.0.1
  • 2. Testversion (neues Feature)
    • Deploy /branches/1.1.x
    • Bugfix /branches/1.1.x + Merge des Bugfix aus /trunk
    • Entwicklung (Faustformel: < 1 PT) /branches/1.1.x + Merge des Bugfix aus /trunk
  • 2. Livestellung (neues Feature)
    • Deploy /tags/1.1.0

Sonderfälle

  • Bei Bug in RedSparkCore:
    • Fix in RedSparkCore/trunk durch Kuborgh.
    • Merge inkl. Review-Prozess in /RedSparkCore/branches/1.2.x.
    • Danach: Bug für eigene App automatisch gefixt, weil diese gegen Branch verlinkt ist. 



Kuborgh GmbH

Hamburg 040 819 773 770 Köln 0221 276 66 96 info@kuborgh.de www.kuborgh.de

RedSpark Community

RedSpark Community

Community Website
RedSpark Apps

RedSpark Apps

Zur Übersicht
RedSpark Download

RedSpark Basispaket

Zum Download
Key facts