ASMIQ.one Release Konzept

Versionierung

ASMIQ.one folgt dem Prinzip des Semantic Versioning (SemVer). Jede Versionsnummer besteht aus drei Stellen nach dem Muster X.Y.Z:

Stelle	Bezeichnung	Wann wird erhöht?	Beispiel
`X`	Major	Grundlegende Architekturänderungen, Breaking Changes	5.x.x → 6.x.x
`Y`	Minor	Neuer Feature-Scope, neuer Develop-Branch	6.5.x → 6.6.x
`Z`	Revision	Bugfixes und kleinere Verbesserungen auf dem Revision-Branch	6.6.11 → 6.6.12

Ein Develop Release hat immer Z = 0 (z.B. 6.6.0). Alle nachfolgenden Revision Releases inkrementieren nur Z (z.B. 6.6.1, 6.6.2, …). Eine Änderung von X oder Y setzt alle nachfolgenden Stellen auf 0 zurück.

Die zwei Branches

ASMIQ.one wird parallel auf zwei Branches entwickelt und released:

Branch	Zweck	Versionsmuster
`develop`	Major-Weiterentwicklung, neue Features	X.X.0 → Develop Release
`revision/*`	Stabile Korrekturen und kleinere Änderungen	X.X.n (n > 0) → Revision Release

Develop Release

Ein Develop Release (z.B. 6.6.0) entsteht aus dem develop-Branch und beinhaltet grössere Änderungen oder neue Funktionsbereiche. Wegen des erhöhten Risikos durchläuft er eine erweiterte Testphase auf der dedizierten Integrationsumgebung integration.asmiq.ch, bevor er produktionsreif ist.

Ein Develop Release wird niemals alleine deployed – er wird immer zusammen mit dem ersten zugehörigen Revision Release (z.B. 6.6.1) ausgeliefert. Damit ist sichergestellt, dass bekannte Korrekturen bereits im ersten produktiven Einsatz enthalten sind.

Revision Release

Ein Revision Release (z.B. 6.6.12) entsteht aus einem revision/*-Branch. Er wird bewusst nah an der aktuell produktiven Version gehalten, damit er jederzeit installiert werden kann. Getestet wird auf test.asmiq.ch.

Build-Strategie

ASMIQ.one setzt auf eine automatisierte Build-Pipeline (Jenkins / AsmiqPipeline):

Branch	Build-Frequenz	Art
`revision/*`	2× täglich (automatisch)	Regulärer Release-Build
`develop`	Bei jedem Push / PR-Merge	SNAPSHOT-Build → Deploy auf dev.asmiq.ch
beide	Wöchentlich	Weekly Release (flüchtig)

Weekly Release

Der Weekly Release ist ein automatisierter Build, der keine offizielle Release-Nummer erhält und in ein temporäres Nexus-Repository (weekly) deployed wird – nicht in das produktive Repository. Er dient der kontinuierlichen Verifikation der Build-Stabilität, ohne die Versions-Nummerierung zu erhöhen. Weekly Releases sind flüchtig und werden nicht an Kunden ausgeliefert.

Testprozess über den Kanban-Workflow

Die Qualitätssicherung der einzelnen Features (Bugs, Changes, Stories u.a.) ist direkt im Kanban-Prozess auf dem ONE Board integriert. Vor dem Eintritt in den Review-Prozess muss ein grüner Build in Jenkins vorliegen – erst dann darf ein Pull Request erstellt und auf Ready for Review gesetzt werden.

Jedes Arbeitselement durchläuft die folgenden Stationen von links nach rechts:

Pull Requests

Ready for
Review

✓ Grüner Build

›

Reviewing

Review

Review Done

›

Test

Test Passed ✓

›

Release

Released

Deployed

›

Accepted

Closed ✓

Code-Review: mindestens ein weiterer Entwickler sowie der Senior Developer / Architekt müssen den PR genehmigen.
Test-Umgebung: test.asmiq.ch für Revision Releases · integration.asmiq.ch für Develop Releases

Erst wenn ein Issue den Status Test Passed erreicht hat, wird es in einen Release aufgenommen. Dies gilt für beide Branches gleichermassen.

Deployment-Ablauf

Issues mit Status Test Passed werden dem nächsten Release zugeordnet (Fix Version in Jira)
Der Release wird gebaut (Jenkins release-Job)
Bei einem Develop Release: gleichzeitiger Build des ersten Revision Release
Deployment auf die Kundeninstanzen (immer mittwochs)
Smoke-Test nach Deployment
Issues werden von Test Passed → Released → Deployed → Closed transitioniert

Umgebungen im Überblick

Umgebung	URL	Branch	Zweck
DEV	dev.asmiq.ch	`develop`	SNAPSHOT-Deployment nach jedem PR-Merge
Integration	integration.asmiq.ch	`develop`	Erweiterter Test von Develop Releases
Test	test.asmiq.ch	`revision/*`	Test von Revision Releases
Produktion	Kundeninstanzen (vasmiq*)	–	Live-Betrieb