# Erklärung

GitLab Projekt für Al-KO E-Commerce Plattform.

# Definition Workflow

## Ziele
- Klar definierter, gemeinsamer Prozess für Beauftragung sowie für Anforderungs-, Defect-, Test-und Releasemanagementder E-Commerce Plattform zwischen Externen Dienstleistern und AL-KO
- Steigerung der Effizienz und Effektivität (mehr Speed, mehr Features zu geringeren Aufwänden & Kosten)
- Steigerung der Qualität und Sicherstellung der Konfidenz in diese
- Maximierung der Transparenz für jede beteiligte Person –Auflösen von „Schattenanforderungen“

## Workflow

### Backlog to Requirement

| # | Kanban Spalte | Push forward |
| --- | --- | --- |
| 0.1 | Ideen-Backlog | AL-KO FB |
| 0.2 | Anforderungsspezifikation | AL-KO FB |
| 0.3 | Abhängigkeitsprüfung | AL-KO FB |
| 0.4 | Priorisierung & Auswahl | AL-KO FB |

### Requirement to Order

| # | Kanban Spalte | Push forward |
| --- | --- | --- |
| 1.1 | Anforderungsklärung | Externer DL |
| 1.2 | Angebotserstellung | Externer DL |
| 1.3 | Angebotsprüfung | AL-KO FB |
| 1.4 | Beauftragung | AL-KO Mgmt + Purchasing |
| 1.5 | Beauftragt | Externer DL |


### Order to Solution

| # | Kanban Spalte | Push forward |
| --- | --- | --- |
| 2.1 | Zur Entwicklung ausgewählt | Externer DL |
| 2.2 | In Arbeit / Umsetzung | Externer DL |
| 2.3 | DL Test gemäß Testmatrix | Externer DL |
| 2.4 | AL-KO Feature Abnahmetest| AL-KO FB |
| 2.5 | Feature Done | Externer DL |

### Solution to Production

| # | Kanban Spalte | Push forward |
| --- | --- | --- |
| 3.1 | Release Bundling, Regressiontest gemäß Testmatrix | Externer DL |
| 3.2 | Release Abnahmetest incl. Regressiontest | AL-KO FB |
| 3.3 | Ready for Deployment | Externer DL |
| 3.4 | Publish | Externer DL |

## Regeln für den Prozess

| Kanban-Board | Kanban-Spalte | Regel |
| --- | --- | --- |
| Übergreifend | Übergreifend | Externer DL und AL-KO arbeiten ausschließlich mit GitLab. Alles, was nicht in GitLab abgebildet wird, „existiert“ nicht. Keine Umsetzung „auf Zuruf“. |
| Übergreifend | Übergreifend | Es gibt verschiedene Ticket-Arten, nämlich "Epic", "Story" und "Bug". Diese Ticket-Arten werden dem Ticket per Label zugeordnet. Jedes Ticket kann nur eine Ticket-Art haben. |
| Übergreifend | Übergreifend | Egal in welcher Kanban-Spalte es zu einem Ticket einen Blocker gibt, wird das Ticket in GitLab per Label als „on hold“ markiert |
| Übergreifend | Übergreifend | Sofern eine Anforderung ausschließlich für eine Zielplattform (z.B. Android vs. iOS) gültig ist, wird dem Ticket das Label "`PLATTFORM` only" markiert, wobei `PLATTFORM` z.B. "iOS" oder "Android" ist. Ist das Ticket für alle Zielplattformen gültig, wird KEIN zusätzliches Label benötigt. |
| Übergreifend | Übergreifend | Es gilt das Kanban-Prinzip. Für jedes Ticket gibt es nur eine Richtung im Prozess „von links nach rechts“ Fehler werden stets als Bugs erfasst, ergänzende Anforderungen stets als neue Story! In einer Spalte dürfen sich nicht zu viele Tickets befinden (max. 15), sonst müssen diese erst abgearbeitet werden, bevor neue Tickets hinzugefügt werden dürfen. |
| Übergreifend | Übergreifend | Egal an welcher Stelle im Prozess ein Bug gefunden wird (unabhängig davon, ob aus Regressionstest oder aus Feature-Test), geht dieser direkt auf Spalte 2.1 und wird ohne zusätzliche Beauftragung des externen DL umgesetzt. Ausnahmen: Sollte es sich jedoch bei dem vermeintlichen Bug um eine geänderte / neue Anforderung handeln, kann externer DL dieses Ticket in Spalte 1.1 verschieben und den Vorgangstyp zu „Story“ ändern. Sollte der Bug durch eine Veränderung der umliegenden Infrastruktur verursacht sein (z.B. neue iOS Version, API der AL-KO Smart Cloud ändert sich, …), wird dies ebenfalls als neue „Story“ und nicht als Bug behandelt |
| 0 Backlog to Requirement | 0.1 Ideen-Backlog | AL-KO erstellt stets alle neuen Anforderungen/Ideen als „Story“ |
| 0 Backlog to Requirement | 0.2 Anforderungsspezifikation | AL-KO ergänzt zu jedem Feature stets die zugehörige AL-KO interne Projektnummer als Label |
| 1 Requirement to Order | 1.1 Anforderungsklärung | Jede Story muss innerhalb einer Entwicklungsiteration umsetzbar sein. Falls Story zu komplex,um innerhalb einer Entwicklungsiteration umgesetzt zu werden, untergliedert externer DL die Story in Sub-Stories, die innerhalb einer Entwicklungsiteration umsetzbar sein müssen |
| 1 Requirement to Order | 1.1 Anforderungsklärung | Externer DL untergliedert Stories selbstständig in "Aufgaben", gemäß Aufgabenverteilung im Entwicklerteam |
| 1 Requirement to Order | 1.2 Angebotserstellung | Angebot enthält nur GitLab Projekt und Ticket ID in der Form `GitLab PROJEKTNAME`#`GitLab TICKET_ID` als Identifier für eine „Leistungszeile“ im Angebot |
| 1 Requirement to Order | 1.2 Angebotserstellung | Ein Angebot wird im Wiki auf der Seite "Angebote" hinzugefügt und das PDF dort hochgeladen. In jeder vom Angebot abgedeckten Story **MUSS** ganz oben in der Beschreibung der Story das korrespondierende Angebot und die entsprechende Leistungszeile referenziert werden. Vorlage siehe Markdown für "Story" und "Bug". |

## Wichtige Festlegungen / Konzepte für den Prozess

### Ticket-Arten
- Es werden in GitLab die Ticket-Arten "Epic", „Story“ und „Bug“ bereitgestellt. 
- Eine „Story“ umfasst eine von AL-KO gewünschte neue / geänderte Funktionalität. Eine „Story“ kann vom externen DL in weitere Stories untergliedert werden (müssen gegenseitig referenziert werden), sofern Storie nicht innerhalb einer Entwicklungsiteration umsetzbar ist. 
- Ein „Bug“ ist ein Fehler, der in einem Feature-Test (ein umgesetzte/s „Feature“/“Story“ funktioniert nicht so wie in der Anforderung beschrieben) oder einem Regressionstest (ein in einem vergangenen Release umgesetzte/s „Feature“/“Story“ funktioniert nicht mehr so wie in der Anforderung beschrieben) gefunden wurde

Für die verschiedenen Ticket-Arten wurden Vorlagen für die Beschreibungstexte als "Markdown" definiert, welche bei Erzeugung eines Tickets gemäß Ticket-Art auszuwählen sind.

### Aufgaben
- In GitLab gibt es die Möglichkeit, Tickets in Aufgaben zu untergliedern, die ganz konkrete Aufgaben für einzelne Mitarbeiter aus dem Team definieren.
- Eine Aufgabe sollte innerhalb weniger Stunden umsetzbar sein

### Releases & Builds
- Für Release-Bezeichner wird die unter [Vorgaben zur Versionierung von digitalen Produkten bei AL-KO Gardentech](#vorgaben-zur-versionierung-von-digitalen-produkten) referenzierte Vorgabe, die für alle digitalen Produkte in AL-KO Smart Solutions gilt, ebenfalls als verbindlich angesehen. Buildnummern werden nicht in den Release-Bezeichner eingeschlossen, sondern werden separat im Ticket im Beschreibungstext erfasst (siehe Vorlage Beschreibungstext)

### Testmatrix
- AL-KO stellt eine stets aktuelle Testmatrix bereit, die zu testende Geräte und Betriebssysteme definiert und an der intern und extern die Qualitätssicherung bemessen wird. AL-KO muss Änderungen an dieser Testmatrix proaktiv an kommunizieren
- Die Testmatrix findet sich im Folgenden: *TBD*

## Vorgaben zur Versionierung von digitalen Produkten

Jedes Ticket **MUSS** ab dem Status "Solution: Zur Umsetzung ausgewählt" einem Ziel-Release (=GitLab "Meilenstein") zugeordnet sein.

### 1.3.2
```mermaid 
graph TB
    subgraph Patch
    2--> RevNr["Hotfix / Patch"]
    end
    subgraph Minor
    3--> Min["Nebenversion"]
    end
    subgraph Major
    1--> Maj["Hauptversion"]
    end
```

### Nomenklatur

#### Hauptversion (Major Release)

- Breaking Changes
- Nicht kompatibel mit vorheriger Major-Version

#### Nebenversion (Minor Releae)

- Changes
- Neue Features
- unkritische Bugfixes
- Kompatibel mit vorheriger Minor-version

#### Revisionsnummer (Hotfix/Path)

- Hotfix 
- kleine Korrekturen, aber keine Änderungen

# import of data
After each product import call these console commands
- ./bin/console alko:process:benefitimages
- ./bin/console alko:process:productimages 1
- ./bin/console alko:process:documents 1
- ./bin/console alko:process:explodedviews 1
- ./bin/console alko:process:sale 1
- ./bin/console alko:factfinder:exporttoftp StageDeutschland 1

# crontab 
*/15 7-18 * * * /var/www/alko-garden.de/maintenance_scripts/syncAllDEPim.sh >> /var/www/alko-garden.de/log.txt 2> /var/www/alko-garden.de/error-log.txt
15 8 * * * /var/www/alko-garden.de/maintenance_scripts/createExportsChannable.sh > /var/www/alko-garden.de/log-channable.txt 2> /var/www/alko-garden.de/error-log-channable.txt
30 8 * * * /var/www/alko-garden.de/maintenance_scripts/createSitemap.sh > /var/www/alko-garden.de/log-sitemap.txt 2> /var/www/alko-garden.de/error-log-sitemap.txt