[gelöst]Entwicklungskonzept

Hi Allerseits,

wir werden in Kürze 365BC on Premises bei uns einsetzen. Da die Möglichkeit bestehen bleiben soll, evtl. später in die Cloud (SaaS) zu gehen, soll die Entwicklung von Anpassungen in Extensions gemacht werden, nichts in C/Side.

Wir sind drei Entwickler und entwickeln ausschließlich zur eigenen Nutzung. Bisher haben wir eine Entwicklungsdatenbank mit Nav3.6, auf der die Objekte angepasst wurden, bzw. neue Obbjekte entwickelt wurden. Wenn ein Entwickler ein Objekt bearbeitet, dann "sperrt" er es, indem er sein Namenskürzel in die Versionsliste hineinschreibt. Nach Test werden dann alle Objekte als .fob exportiert und dann in die Echt-Datenbank importiert. Das funktioniert soweit ganz gut und hat noch nie zu Problemen geführt, setzt allerdings ein gewisses Maß an Disziplin voraus.

Wir grübeln jetzt über ein Konzept für die Extension-Entwicklung.

Wie sollten wir die Extension(s) aufbauen ?

Ist es sinnvoll, eine große Extension für alles zu machen, also alle Anpassungen in einer einzigen Extension zu haben. Oder sollten wir besser einzelne Bereiche mit eigenen Extensions machen? Es wird sehr oft Überschneidungen zwischen den Bereichen geben, aber da kann man ja mit Dependencies arbeiten. Oder ist es gar vorstellbar, für jede erweiterte Table eine eigene Extension (Table und dazu gehörende Pages) zu machen. Auf diese Art findet jeder sofort die Quelle eines Feldes und braucht nicht zu grübeln, in welcher der Extensions ein Feld definiert wurde.

Wie gesagt, wir arbeiten nur für uns, brauchen also keine Rücksicht auf Vermarktungsfähigkeit etc. zu nehmen.

Zuletzt geändert von elf am 4. September 2019 12:16, insgesamt 1-mal geändert.

Es gibt in meinen Augen nur 2 Möglichkeiten als Endnutzer.
Beides hat vor und nachteile, wobei ersteres leichter zu handhaben ist, das Zweite allerdings mehr flexibilitaet bietet

1. Eine Extension für alles
Vorteile:
- du musst dir keine Gedanken darum machen in welche App du jetzt welche Funktion packst. Du hast keine Dependencies!
- es unterscheidet sich nicht all zu sehr von der C/Side Entwicklung. Eine Datenbank -> eine App
Nachteil
- es wird sehr schnell sehr unübersichtlich wenn die Extension größer wird.
- du kannst nicht einfach Tabellen/Tabellenstrukturen refactoren.
- "Quickfixes" im laufenden Betrieb sind hiermiet fast unmöglich.

2. Eine Extension für logisch abtrennbare Module
Vorteil:
- solltest du mehrer Datenbanken besitzen kannst du entscheiden ob du ein Modul in der Datenbank benötigst. Vor allem wenn du mehrere Länderversionen hast.
- du kannst ein Modul komplett aus der Datenbank entfernen wenn es nicht mehr benötigt wird. (oder es leicht refactoren).
- sind in der Regel recht klein und damit übersichtlich.
Nachteil:
- du musst dich mit Dependencies rumschlage, dies kann vor allem in Entwicklungsumgebungen sehr nervig werden.
- du musst Entscheidungen Treffen wo du bestimmte Funktionen implementierst (als Beispiel brauchst du in einer App ne OAuth authentifizierung - wo packst du die Logik dafür hin?)
- für die installation der untersten App musst du alle Apps die eine abhängigkeit haben deinstallieren
- du musst deine ObjektID's irgendwie verwalten

Wir haben uns für Variante 2 entschieden. Ich hab im laufe der letzten 2 Jahre jede Menge Powershell Scripte entwickelt welche uns mit den meisten Nachteilen helfen.
Bei uns entwickelt jeder Entwickler lokal in seiner eigenen Instanz (auch App übergreifend). Wenn er fertig ist, wird der Code in die Versionskontrolle geschoben und automatisiert in ein Testsystem geschoben.

Früher war die Application noch überschaubar, und wenn man sehen wollte, wo was angepasst wurde, öffnete man das Objekt im Designer und schaute in dem Trigger/Feld einfach nach.
Navision/NAV/D365BC wurde mit der Zeit aber immer komplexer und spätestens mit der Einführung der Events kann man auch nicht "mal eben" nachschauen, ob das Objekt angepasst wurde.

Ich empfehle daher auf jeden Fall den Einsatz von Tools wie den "Object Manager Advanced".
(Ehrlich gesagt, kann ich mir heute nicht mehr vorstellen, dass man früher ohne ein solches Tool in einem ERP-System programmiert hat.)
Die aktuelle Version 13 des Object Manager Advanced unterstützt auch C/AL <-> AL Konvertierungen on-the-fly.

ok, danke,

alles in eine einzige Extension zu packen scheint uns tatsächlich nicht der beste Weg zu sein. Da wir ziemlich nah am Anwender sitzen, machen wir oft mal Quickfixes - das wäre dann wahrscheinlich wirklich sehr schwierig zu bewerkstelligen.

Wir überlegen jetzt, eine eigenständige Extension für jede Table zu machen. In dieser Extension wären dann die Felder der Table, die Extension für die Karte und die Liste drin. So wäre es relativ einfach, Änderungen an Tables "aufzuspüren", man müsste nicht schauen, in welcher Extension welches Feld hinzugefügt bzw. geändert wurde. Allerdings bläht das natürlich die Anzahl der installierten Extensions und der Dependencies auf. Würde das ein Problem bereiten?

Würde das ein Problem bereiten?

schwierig zu sagen, da es sicherlich noch kein Livebeispiel gibt, wieviele Extensions das System problemlos verkraftet - ich denke es klappt, aber wie du schon sagtest, bläht das alles ungemein auf.

M. E. macht 1 Extension pro Tabelle keinen Sinn da i. d. R. ja mehr zu einer Anpassung gehört als eine Tabelle mit zugehöriger/n Page(s).

Beispiel: Neues Feld im Debitor dass in den Verkaufsbeleg übertragen werden soll und mitgebucht werden soll. Es ist kein einfaches Feld (kein transferfields) sondern soll in bestimmten Abhängigkeiten beim Buchen unterschiedliche Dinge bewirken. Ich setze auch mal voraus dass es in der Buchungsfunktion/Codeunit ein passendes Event gibt und hier nur Code ergänzt, nicht Standard-Code geändert werden soll. Dann wären mehrere Tabellen, Pages, Codeunit(s) von der Anpassung betroffen. Diese Anpassung dann in z. B. 3 Extensions zu verteilen (pro Tabelle und Codeunit) macht m. E. keinen Sinn.

M. E. macht 1 Extension pro Tabelle keinen Sinn da i. d. R. ja mehr zu einer Anpassung gehört als eine Tabelle mit zugehöriger/n Page(s).

Ja, das ist uns schon bewusst. Grundsätzlich halten wir es auch für sinnvoller, die Extensions nach Inhalten zu bauen. Also alle Dinge einer neuen Funktion (neue Pages, Reports, Codeunits etc.), in einer eigenen Extension zusammenzufassen. Nun gibt es bei uns aber auch Felder - im Wesentlichen im Customer- und ItemTable - die übergreifend in sehr vielen Bereichen benutzt werden. So haben wir z.B. derzeit im Customer ein zusätzliches Feld "Name 3". Dieses Feld könnten wir keinem Bereich explizit zuordnen. Wir müssten also eine Basis-Extension haben, in der die grundsätzlichen zusätzlichen Tabellenfelder definiert werden würden. Wir müssten dann bei jedem neuen Feld überlegen, ob dieses Feld evtl. später mal in einer anderen Extension auch benötigt werden könnte, um zu entscheiden, ob es in die Basis-Extension hineinkommt oder einer bestimmten Extension explizit zugeordnet ist. Wie schon gesagt, wir entwickeln nur für den Eigenbedarf.

Wenn wir je Tabelle eine eigene Extension machen, dann werden das vielleicht tatsächlich zu viele Extensions mit sehr vielen Dependencies in den darauf zugreifenden Extensions. Vielleicht ist es sinnvoller, eine Extension für alle Tables und die dazu gehörigen Pages (Stammdatenkarte und -Übersicht) zu benutzen.

Wir sind da noch in der Findungsphase...

ok, wir haben jetzt - vorerst - entschieden, alles in einer einzigen Extension zu machen. Das scheint uns am einfachsten, und wir sparen uns das Dependencies-Gedöns. Es sei denn, es gibt eigenständige, komplett unabhängige Bereiche, die werden dann eigene Extensions bekommen.

Hotfixe dürften auch relativ problemlos sein. Wir werden die Struktur so gestalten, dass jedes Objekt eine eigene Datei erhält. Jeder Entwickler hat eine Kopie der kompletten Codebasis in seiner Entwicklungsumgebung. Bei Hotfixen werden im Projekt halt diese zu tauschenden Dateien ausgetauscht und es wird kompiliert und installiert.

Bei Hotfixen werden im Projekt halt diese zu tauschenden Dateien ausgetauscht und es wird kompiliert und installiert.

Denkt bitte daran, wenn ihr eine neue Version einer Extension installieren wollt, muss dafür die alte Version deinstalliert werden.
Dies sollte nur geschehen wenn kein Benutzer im System ist, oder du 100% sicherstellen kannst das die Benutzer keine Objekte von der Extension nutzen die du jetzt deinstallierst.

D.h. schnell mal nen Objekt wie in C/Side zu ändern ist so nicht möglich!

Denkt bitte daran, wenn ihr eine neue Version einer Extension installieren wollt, muss dafür die alte Version deinstalliert werden.

Muss die Extension wirklich deinstalliert werden? Oder ist das über die Versionsnummer gesteuert? Wenn wir die Versionsnummer in der app.json nicht ändern, muss dann die Extension wirklich zunächst deinstalliert werden?

Aber i.d.R. installieren wir Updates eh am Abend. Das war bisher in Nav auch so: wenn eine Table geändert wurde, dann sind die Benutzer auch rausgeflogen..

Hallo,

Aber i.d.R. installieren wir Updates eh am Abend.

Du hast da ein ganz wichtigen Zusatz gemacht-> i.d.R. .

Wenn es ein gravierendes Problem gibt, wirst du sofort handeln müssen, und nicht bis abends warten können. Gerade am Anfang wird sicherlich häufiger passieren.

Gruß Fiddi

na klar, wenn das Problem so gravierend ist, dass es nicht bis zum Abend warten kann, dann müssen halt zur Not alle User raus..

Muss die Extension wirklich deinstalliert werden? Oder ist das über die Versionsnummer gesteuert? Wenn wir die Versionsnummer in der app.json nicht ändern, muss dann die Extension wirklich zunächst deinstalliert werden?

Weiß das einer?

Weiß das einer?

Wenn du versucht die Extension noch einmal über Powershell zu publishen bekommst du folgenden Fehler

Code:

Publish-NAVApp : This Extension cannot be published as it is already published.
At line:11 char:7
+       Publish-NAVApp -ServerInstance $Serverinstance -Path $AppFile.F ...


SO funktioniert es zumindest nicht.


Allerdings kann VSCode ja auch über F5 die gleiche Version noch einmal mit "Synchronize" oder "Recreate" publishen.
Der F5 Button benutzt den DEV Endpoint (wie der genau funktioniert kann ich dir allerdings nicht sagen)
Wenn du aber beim F5 drücken die Extension Liste offen hast, siehst du das die Extension erst deinstalliert, unpublished und dann neu gepublished und installiert wird.

Die aktuelle Version 13 des Object Manager Advanced unterstützt auch C/AL <-> AL Konvertierungen on-the-fly.

Die kommende Version OMA 365 (Beta ab August) wird die erste AL-basierte sein, verwendbar ab BC 15 aufwärts.