Mitwirken

Guppy nutzt einen Staging-Branch-Workflow, um Features kontrolliert zu testen, bevor sie in Produktion landen. Dieselbe Strategie gilt für DmfGuppyTheme und alle Guppy-Plugins.

Branch-Struktur

Branch	Zweck	Shopware-Kompatibilität
main	Produktionsbereit, Single Source of Truth, alle Tags entstehen hier.	aktuelle Shopware LTS
stage	QA-/Test-Branch, befüllt den Guppy Playground.	aktuelle Shopware LTS
Feature-Branches	individuelle Entwicklung, Konvention TICKET-123_feature-name.	–

Feature-Workflow Schritt für Schritt

1. Feature-Branch erstellen (von main)

git checkout main
git pull
git checkout -b GUPPY-123_product-slider-component

2. Entwicklung und Commits

Conventional Commits empfohlen, mit Ticket-Prefix:

git add .
git commit -m "GUPPY-123: Add product slider component"
git push origin GUPPY-123_product-slider-component

3. Merge in stage für Testing

git checkout stage
git pull
git merge GUPPY-123_product-slider-component
git push

Parallele Features

Mehrere Features können parallel in stage getestet werden, solange sie sich nicht gegenseitig stören.

4. Playground-Pipeline triggern

Im GitLab-Projekt guppy-playground:

• CI/CD → Pipelines → Run Pipeline
• Pipeline pullt automatisch die stage-Branches.

5. QA in Jira

• Ticket-Status auf Testing setzen.
• QA-Person zuweisen.
• Tests: Funktionalität, Cross-Browser, Mobile, Barrierefreiheit.
• Bei Problemen: zurück zu Schritt 2.
• Bei Erfolg: QA-Freigabe.

6. Merge in main

Direkt der Feature-Branch in main

Für saubere Git-History wird der Feature-Branch direkt in main gemerged, nicht der stage-Branch.

git checkout main
git pull
git merge GUPPY-123_product-slider-component
git push

7. Version taggen

SemVer beachten, siehe Changelog.

git tag v2.6.0
git push --tags

Major Releases mit RC-Tags

Für Breaking Changes (neue Shopware-Major-Version) gibt es keinen separaten Branch. Stattdessen werden RC-Tags direkt auf main gesetzt:

git tag v2.8.0-rc1
git push --tags

Mehrere RC-Iterationen sind möglich (-rc1, -rc2, ...) bis zur finalen Version.

8. Projekte aktualisieren

• Express-Demo: composer update dmf/sw6-guppy-theme.
• Kundenprojekte: nach Absprache mit Projekt-Manager.

Hotfixes

Für kritische Bugfixes:

1. Branch von main: HOTFIX-123_critical-bug.
2. Fix entwickeln.
3. Direkt in main mergen (stage überspringen).
4. PATCH-Version taggen.
5. Sofort deployen.
6. stage aktualisieren.

Hotfixes als Ausnahme

Hotfixes umgehen den QA-Schritt. Wenn möglich, normalen stage-Workflow nutzen.

stage aktuell halten

Regelmäßig (alle paar Monate) main in stage mergen, damit Hotfixes nicht verloren gehen:

git checkout stage
git merge main
git push

Workflow-Diagramm

Feature-Branch (von main)
         ↓
   Entwicklung
         ↓
   Merge → stage
         ↓
   Playground-Pipeline
         ↓
   QA-Testing ──→ Fehler? ──→ Zurück zu Entwicklung
         ↓
     QA-Freigabe
         ↓
   Merge Feature-Branch → main
         ↓
   Version taggen
         ↓
   Projekte aktualisieren

Test-Umgebungen

Umgebung	Branch/Version	Zweck
Guppy Playground	stage	QA + Feature-Testing
Express-Demo	getaggte Releases	Showcase
Kundenprojekte	spezifische Tags	Produktion

Release-Checkliste

• [ ] Feature-Branch von main erstellt
• [ ] Feature entwickelt und lokal getestet
• [ ] Feature-Branch in stage gemerged
• [ ] Playground-Pipeline getriggert
• [ ] Jira-Ticket QA-Person zugewiesen
• [ ] QA-Testing erfolgreich
• [ ] Feature-Branch in main gemerged
• [ ] Version-Tag erstellt
• [ ] Express-Demo aktualisiert
• [ ] Kundenprojekte informiert (falls nötig)

Verwandt

• Changelog: Versionierungs-Strategie (SemVer).
• Architektur: Plugin-Struktur, theme.json-Modell.