Projektfluss¶

Der komplette Lebenszyklus eines Projekts - von der Erstellung bis zur Archivierung. Projekte durchlaufen acht Stufen. Ein Release-basiertes System entkoppelt die einzelnen Phasen und ermöglicht paralleles Arbeiten ohne Konflikte.

01 - Projekterstellung

project.meta.json wird angelegt
Leere planning/ Struktur wird erstellt
Projektstatus: Konzeptplanung

02 - Konzeptplanung

Planer setzt planning.lock.json
Arbeitet an planning.zip (enthält CP.msgpack)
Stand hochladen und Lock freigeben (transaktionsbasiert)
Freigabe: CP.msgpack wird eingefroren - nicht mehr editierbar
Projektstatus wechselt zu Detailplanung

Hinweis

Nach Freigabe ist ein rein textueller Vergleich zwischen Konzept- und Detailplanung möglich (Geräte, Datenpunkte, etc.). Die Sperre des CP.msgpack ist keine harte Sperre - es ist möglich diese falls nötig im Nachhinein zu bearbeiten. Die Konzeptplanung ist ab dem Freigeben der Detailplanung bis auf den textbasierten Vergleich entkoppelt. Die Freigabe erstellt eine eingefrorene Kopie der Konzeptplanung, diese kann nicht mehr bearbeitet werden.

03 - Detailplanung & Release

Selber Lock auf planning/, arbeitet an planning.zip
Enthält: CP.msgpack + DP.msgpack + Bibliothek
Transaktionsbasiert: Lock holen, arbeiten, hochladen, freigeben
Release freigeben (manuell): DP.msgpack wird als DP.msgpack.gz in releases/vX.Y/ abgelegt
Minor (v1.0 -> v1.1): Kleine Änderungen, kein neuer E-Plan nötig
Major (v1.x -> v2.0): Strukturelle Änderungen, neuer E-Plan erforderlich

Weiterarbeiten

Der Detailplaner arbeitet nach dem Release weiter. Der Release ist ein Snapshot - die nachfolgenden Stages arbeiten gegen diesen eingefrorenen Stand.

04 - E-Planung

E-Planer setzt engineering.lock.json
Sieht verfügbare DP-Releases und ob ein neuer E-Plan nötig ist
Lädt DP.msgpack.gz des gewählten Releases herunter (read-only)
Arbeitet extern in EPLAN Software
Upload: engineering/v1/eplan_upload.zip
E-Plan v1 ist gültig für alle DP v1.x Releases
Lock freigeben

05 - Software

Softwareplaner setzt software.lock.json
Wählt Referenzen: dp_ref und eplan_ref in software.meta.json
Lädt herunter: DP.msgpack.gz + eplan_upload.zip (beides read-only)
Arbeitet lokal, eventuell offline - der referenzierte Stand ist statisch
Upload: software/software.zip (nur eigener Arbeitsstand)

Hinweis

Die Software-Ansicht zeigt permanent welche DP-Release Version und welche E-Plan Version referenziert wird, und ob neuere verfügbar sind (Mismatch-Anzeige).

06 - Neuer Minor Release (v1.0 -> v1.1)

E-Plan v1 bleibt gültig - automatisches Matching
Softwareplaner sieht: "Neuer DP v1.1 verfügbar, kein neuer E-Plan nötig"
Kann Diff zwischen v1.0/DP.msgpack.gz und v1.1/DP.msgpack.gz prüfen
Entscheidet selbst ob und wann die Referenz aktualisiert wird

Kein Handlungsbedarf

Kein Handlungsbedarf für den E-Planer. Der Softwareplaner hat volle Kontrolle über den Zeitpunkt des Umstiegs.

07 - Neuer Major Release (v1.x -> v2.0)

E-Plan v1 ist nicht mehr gültig für v2.x
E-Planer muss neuen E-Plan erstellen: engineering/v2/eplan_upload.zip
Softwareplaner sieht: "Neuer DP v2.0, E-Plan v2 noch ausstehend"
Kann bewusst mit Mismatch weiterarbeiten oder auf E-Plan v2 warten
Bei Umstieg: Referenzen aktualisieren, neue Dateien herunterladen

Mismatch erlaubt

Mismatch-Situationen sind bewusst erlaubt. Die Kollegen sitzen im selben Raum und sprechen sich ab - das System strukturiert den Prozess, erzwingt ihn aber nicht.

08 - Archivierung

Referenzierte Versionen ermitteln (DP von E-Plan, DP von Software, E-Plan von Software, recent)
Alle nicht referenzierten Releases nach archive/
Konfigurierbar in den allgemeinen Projekteinstellungen