Eine JD Edwards EnterpriseOne Checkliste für die Objektpromotion in DV-, PY- und PD-Umgebungen ist genau das Prozessdokument, das Installationen mit ruhigem Produktionsbetrieb von Installationen trennt, in denen jeder Dienstagmorgen zum Feuerwehreinsatz wird. Der Unterschied liegt fast nie am Können der Entwickler. Der Unterschied liegt darin, ob alle Beteiligten wissen, welche Bedingungen erfüllt sein müssen, bevor ein Objekt von einer Umgebung in die nächste verschoben werden darf, und ob jemand jeden einzelnen Punkt prüft, bevor sich der OMW-Status ändert.
Ich habe JDE-Installationen gesehen, in denen der Promotion-Prozess aus „frag Marco, ob es fertig ist“ bestand, und andere, in denen eine Checkliste mit dreißig Punkten über dem Schreibtisch des CNC-Administrators hing. Die zweite Art von Organisation hat weniger Ausfälle, schnellere Wiederherstellungen und Entwickler, die Montagsdeployments nicht fürchten. Die Checkliste selbst ist nicht der Zaubertrick. Der eigentliche Wert liegt darin, dass alle — Entwickler, Lead, CNC-Team und Business Owner — wissen, was geprüft wird, bevor die Änderung PD erreicht.
Wofür DV, PY und PD eigentlich existieren
Das Drei-Umgebungen-Modell in JDE E1 sieht in jeder Installation gleich aus, bedeutet aber in jeder Installation etwas leicht anderes. DV steht für Development und ist der Ort, an dem instabiler Code lebt — Code, der möglicherweise nicht kompiliert, das betroffene Formular beschädigt oder Testdaten verfälscht. Die einzige Zusage von DV ist, dass alles, was dort liegt, einem Entwickler gehört, der es korrigieren kann. PYPrototype- oder Pristine-Umgebung — die JDE-Testebene, in der promoteter Code gegen eine produktionsnahe Datenkopie geprüft wird, bevor er nach PD verschoben wird. Das „Y“ stammt aus dem historischen Pristine/Pristine-Yes-Pathcode. ist der Ort, an dem stabiler Code liegt, der ein Peer Review bestanden hat und gegen Daten getestet wird, die der Produktion ähnlich genug sind, um Fehler sichtbar zu machen, die DV nie zeigen würde. PD ist Production: dort läuft das Geschäft, und der Vertrag lautet Verfügbarkeit und Korrektheit.
Der häufigste Fehler, den ich sehe, ist PY wie „DV mit besseren Daten“ zu behandeln. Das ist falsch. PY ist eine Release-Candidate-Umgebung, und Code in PY hat bereits ein Gate passiert. Wenn drei Entwickler unfertige Änderungen nach PY einchecken, weil „es ja nur die Testumgebung ist“, wurde das eigentliche Gate zwischen PY und PD verschoben, und PY erfüllt seine Aufgabe nicht mehr. Das Functional-Test-Team beginnt Fehler zu finden, die bereits in DV hätten abgefangen werden müssen, Regressionstests blähen sich auf, und die Promotion-Frequenz nach PD fällt von wöchentlich auf monatlich.
Jede Umgebung lebt in ihrem eigenen Pathcode — DV920, PY920, PD920 in einer 9.2-Installation, mit den entsprechenden Business-Data-Tabellen in Umgebungen wie DV920FA, PY920FA und PD920FA. Die folgende Checkliste setzt diese Zuordnung voraus. Wenn Ihre Installation andere Namen verwendet, ersetzen Sie sie entsprechend; die Gates und ihre Reihenfolge bleiben gleich.
Das DV-zu-PY-Gate: Was erfüllt sein muss, bevor Code die Hände des Entwicklers verlässt
Das erste Promotion-Gate ist der Punkt, an dem der größte Wert entsteht, weil Fehler, die hier gefunden werden, Minuten kosten, während dieselben Fehler am PY-zu-PD-Gate Tage kosten können. Bevor ein Objekt über eine OMWObject Management Workbench — das JDE-Werkzeug zur Verwaltung von Check-in, Check-out, Projektzugehörigkeit und Statusübergängen über DV-, PY- und PD-Pathcodes hinweg.-Statusänderung von DV nach PY verschoben wird, umfasst die Checkliste für dieses Gate grob sechs Punkte.
Das Objekt muss in DV sauber kompilieren. Für BSFNs und Table Conversions ist das nicht verhandelbar, und das Build-Log muss null Fehler und null Warnungen zeigen. Auch Warnungen zählen: Warnungen in C-BSFNs werden deutlich häufiger zu Laufzeitabstürzen, als Entwickler gerne zugeben. Der Spec Merge gegen die aktuelle Standard-ESU-Baseline muss geprüft werden — insbesondere bei Retrofit-Objekten, bei denen sich der Standard seit dem letzten Refresh des Entwicklers geändert haben kann. Die von der Funktion oder Anwendung verwendete Data Structure muss gegen die aufrufenden Stellen geprüft werden. Ein neues Feld in einer DS kann jeden Caller beschädigen, der nicht neu kompiliert wurde, und die Reihenfolge der Neukompilierung ist Teil des Promotion-Plans, kein nachträglicher Gedanke.
Das OMW-Projekt muss jedes berührte Objekt enthalten, nicht nur das Hauptobjekt: das Formular, das die neue BSFN aufruft, die Data Structure, die die BSFN verwendet, die UDC-Tabelle, die der neue Code liest, und die F7900-Fehlermeldungszeilen für neue Fehlercodes. Ein Projekt, das die BSFN promotet, aber die neue F7900-Zeile vergisst, schlägt in PY zur Laufzeit mit einer leeren Fehlermeldung fehl, deren Rückverfolgung den Bereitschaftstechniker eine Stunde kosten kann.
Peer Review ist das menschliche Gate, das erkennt, was Werkzeuge nicht erkennen. Ein zweiter Entwickler, der die Änderung auch nur zehn Minuten lang liest, findet oft die Annahme, die dem ursprünglichen Entwickler entgangen ist: die fest codierte Company Number, der Datumsvergleich, der über den Jahreswechsel bricht, oder der Lookup, der die erste Zeile zurückgibt, obwohl aggregiert werden müsste. Status 25 in OMW ist die übliche Konvention für „peer-reviewed und bereit zur Promotion“. Diese Konvention funktioniert nur, wenn jeder Entwickler sie respektiert.
Das PY-zu-PD-Gate: Wo Geschäftsrisiko tatsächlich gesteuert wird
Das zweite Gate ist der Punkt, an dem die Promotion-Checkliste ihren Wert beweist. Code, der DV zu PY passiert hat, ist technisch für sich genommen korrekt. Um PY zu PD zu passieren, muss er jedoch neben allem anderen funktionieren, was bereits in Produktion läuft, und die Bereitstellung selbst darf den Geschäftsbetrieb nicht gefährden.
Der erste Punkt an diesem Gate ist die Testfreigabe. Die Person, die den betroffenen Geschäftsprozess verantwortet — Auftragserfassung, Fakturierung, Payroll oder Bestandsauffüllung — muss persönlich bestätigt haben, dass sich PY so verhält wie erwartet. Nicht „das Entwicklungsteam glaubt, dass es funktioniert“, sondern der Business Owner, der die Support-Tickets abbekommt, wenn es schiefgeht. Ohne diese Freigabe ist der Entwickler die einzige Person, die den Code wirklich berührt hat, und auch die einzige Person, der die Schuld gegeben wird, wenn etwas bricht.
Der Package-Build-Plan muss klar sein, bevor das Gate geöffnet wird. Update Package, Foundation Package oder Full Package? Ein Update reicht für ER- und Formularänderungen. Foundation ist zwingend erforderlich, sobald kompilierter C-BSFN-Code geändert wurde — und „zwingend“ bedeutet Server-Neustart, also ein koordiniertes Downtime-Fenster. Ein Full Package bleibt Tools-Release-Änderungen und quartalsweisen kumulativen Deployments vorbehalten. Die falsche Package-Art liefert entweder die Änderung nicht aus — Update ohne Foundation, obwohl C-Code geändert wurde — oder verursacht eine unnötige Betriebsunterbrechung, wenn ein Full Package gewählt wird, obwohl ein Update gereicht hätte.
Der Rollback-Plan muss geschrieben sein, bevor die Änderung promotet wird, nicht nachdem der Alarm losgeht. Für ER-Änderungen ist Rollback ein OMW-Restore der vorherigen Objektversion. Für C-BSFN-Änderungen ist Rollback die erneute Promotion des vorherigen Foundation Package, was dieselben 30 bis 60 Minuten dauern kann wie die ursprüngliche Installation. Für Data-Dictionary-Änderungen, die viele Formulare betreffen, gibt es möglicherweise keinen sauberen Rollback. Genau solche Fakten gehören auf die Gate-Checkliste und dürfen nicht erst um 02:00 Uhr entdeckt werden, wenn etwas ausfällt.
Koexistenzprüfungen: Wenn das neue Objekt auf den Rest von PD trifft
Das verborgene Risiko einer Promotion liegt selten im neuen Objekt selbst. Es liegt in der Interaktion zwischen dem neuen Objekt und den Dutzenden Standard- und Custom-Objekten, die bereits in PD vorhanden sind. Die Checkliste braucht dafür einen expliziten Prüfschritt, weil dieser Punkt sonst von nichts zuverlässig abgefangen wird.
Der Spec-Merge-Status ist die erste Koexistenzprüfung. Wenn das neue Objekt von einem Standardobjekt abgeleitet ist, das sich zwischen Entwicklungsbeginn und geplanter Promotion geändert hat, muss der Spec Merge erneut ausgeführt, das Diff geprüft und jeder Konflikt gelöst werden. Wird dieser Schritt übersprungen, funktioniert eine Custom-P4210-Änderung auf 9.2.6 perfekt und hört dann auf zu funktionieren, sobald die Installation das kumulative 9.2.8-Update einspielt — weil sich das Standardformular unter der Customization verschoben hat.
BSFN-Call-Abhängigkeiten sind die zweite Prüfung. Eine neue BSFN, die vorhandene BSFNs aufruft, benötigt die Bestätigung, dass diese aufgerufenen BSFNs in PD in der Version vorhanden sind, gegen die der neue Code getestet wurde. Ein neues Feld in einer bestehenden Data Structure bedeutet, dass jeder Caller im OMW-Projekt in derselben Promotion enthalten sein muss — und jeder Caller außerhalb des Projekts identifiziert, regressiongetestet und entweder gebündelt oder ausdrücklich als nicht betroffen freigegeben werden muss.
UDC- und Data-Dictionary-Erweiterungen sind die dritte Prüfung. Neue UDC-Werte für einen bestehenden UDC-Typ sind normalerweise unkritisch. Neue UDC-Typen, auf die Code verweist, sind es nicht, weil der Typ in F0004 in PD existieren muss, bevor der Code läuft, der ihn liest. Der Checklistenpunkt lautet hier: „Prüfe, dass jede neue F0004- und F0005-Zeile, die vom Package benötigt wird, in PD vorhanden ist, bevor der abhängige Code promotet wird.“ Zwei Minuten Pre-Flight-Check vermeiden Stunden an Supportarbeit.
Was im Moment der Promotion nach PD passiert
Die Promotion selbst ist der prozeduralste Schritt der gesamten Sequenz, und genau deshalb verursacht sie den größten Schaden, wenn ad hoc entschieden wird. Eine Promotion nach PD ist ein geplanter Vorgang, kein „machen wir schnell, solange es ruhig ist“-Vorgang.
Das Fenster wird vorab angekündigt — an das Operations-Team, an die Business Owner und an alle, deren Batch-Jobs während dieses Fensters laufen. Das CNC-Team verantwortet den eigentlichen OMW-Transfer und den Package Build. Entwickler promoten ihren eigenen Code in keiner sauber geführten Installation selbst nach PD, sowohl wegen Audit-Anforderungen als auch deshalb, weil die Person, die den Code geschrieben hat, die schlechteste Person ist, um zu validieren, dass er in einer sauberen Umgebung funktioniert.
Die Prüfung nach der Promotion ist der letzte Checklistenpunkt und derjenige, der am häufigsten übersprungen wird. Innerhalb desselben Maintenance Window wird ein Smoke Test gegen die promotete Änderung ausgeführt — eine realitätsnahe Transaktion entlang des betroffenen Pfads, Ende zu Ende, gegen PD-Daten mit einem markierten Testkonto. Diese Prüfung beweist, dass das Package gebaut, deployt und aufrufbar ist. Ohne diesen Schritt läuft der neue Code in PD zum ersten Mal dann, wenn ihn am nächsten Geschäftsmorgen ein echter Benutzer ausführt, und jedes Deployment-Problem wird zu einem Produktionsincident statt zu einem Rollback innerhalb des Wartungsfensters.
Mehr zur operativen Seite der JDE-Arbeit finden Sie in den verwandten Artikeln zur Tools-Release-Upgrade-Strategie, zum Retrofit von Standardkopien und zu BSFN-Test-Harnesses. Das technische Projektportfolio auf dieser Website dokumentiert zwei Produktionsdeployments, aus denen die hier beschriebenen Checklistenmuster entstanden sind.