Lieferverzögerungen bei CUs für Version 14

Thema abgeteilt von hier. (Mod. Kowa)

Nachdem schon CU 1 (Mai) verspätet kam wurde CU 2 gar nicht veröffentlicht, dann irgendwann mal für 22.07.2019 angekündigt (https://twitter.com/FrankSpronck_MS/sta ... 3206538240), aber bis heute nicht veröffentlicht. Microsoft scheint extreme Probleme zu haben.

Das die Probleme haben ist prinzipbedingt, leider.

Durch die Events und die Eventsubscriber verliert man jeden Überblick darüber, was in der Anwendung abgeht.

Ich finde, ein gutes Programm erzählt eine Geschichte, was passiert, wenn man an einer bestimmten Stelle vorbei kommt. Durch die Events sieht man nicht mehr was passiert, bzw. man sieht das Elend erst im Debugger und rauft sich die Haare warum das Programm so langsam ist.
Außerdem wird sklavisch an irgendwelchen Design- Richtlinien festgehalten, und eingeführter stabiler Code durch eine Unmenge von SalesSetup.GET ersetzt, weil man keine Globalen Variablen mehr haben will. Nicht zu verachten. die tief verschachtelten Funktionsaufrufe, die einen den Überblick verlieren lassen.

Das größte Problem in der Software- Entwicklung scheint aber die mangelnder Erfahrung der Entwickler zu sein. Das ist allerdings kein Problem von Microsoft alleine.
Wenn Buchhalter entscheiden, das Leute frisch von der Uni billiger sind als Programmierer mit 10 und mehr Jahren Erfahrung, muss sich nicht wundern, wenn da nichts Vernünftiges dabei herauskommt.
Ein Entwicklerteam sollte immer aus Erfahrenen und Neulingen bestehen, damit der eine von dem Anderen lernen kann. Wobei das nicht nur in eine Richtung gehen sollte.

Ein weiteres Problem ist die Art und Weise wie entwickelt wird.
Als NAV erfunden wurde, haben die Leute, die programmiert haben, das mit dem Endanwender zusammen gemacht. Sie haben sofort gesehen, wenn eine ihrer genialen Ideen vielleicht doch nicht so genial war, weil sie es dem Anwender nicht erklären konnten, oder der sich die Finger gebrochen hat.
Heute stehen zwischen den Anwendern und den Programmierern nahezu unendlich viele Ebenen, bevor das beim Programmierer ankommt (Anwender-> Lokale IT->Partner-Support ->Consultant-> Entwicklungsleitung-> lokale Programmierung,...). Das gleicht dem "Stille Post" -Prinzip. Wobei das nur eine Seite des Problems ist. Der Programmierer sieht nicht mehr wie und ob seine Arbeit funktioniert, und kann nicht gegensteuern.

Am Ende kommt dann eine Lösung wie das bekannte Schaukel-Projekt dabei heraus.

Gruß Fiddi

Du sprichst bzw. schreibst mir aus der Seele...

Es war von Anfang an Blödsinn monatlich ein CU rauszuhauen für alle Versionen im Wartungszyklus. Und dort dann nicht nur Fehlerkorrekturen sondern auch neue Funktionalität einzubauen. Dann gibt sich Microsoft für gravierende technische Veränderungen (von denen die Anwender nix mitbekommen) regelmäßig zu wenig Zeit so dass neue Versionen im Grunde keine wirklich bedeutenden neue oder verbesserte Funktionalität für den Anwender bieten (dafür nur technische Neuerungen die in RTM natürlich noch nicht korrekt funktionieren). Immer wieder werden Ankündigungen (z. B. zum neuen Lizenzmodell) von Microsoft ohne vorherige Rücksprache mit der realen Welt (z. B. mit den Partnern) rausgehauen und nach der Protestwelle zurückgezogen oder zurechtgebogen.

Aber zurück zum Thema... Ich finde interessant dass man das mit den CUs bis heute weiterhin macht, inkl. D365BC v13, aber mit v14 läuft's nicht. Was ist das Problem bei v14 was man bei v13 nicht hat?

kann fiddi hier auch nur zustimmen!

durch Extensions hab ich vor kurzem eine Liste / Karte nicht mehr öffnen können - Grund war, dass die Extension auf ein Feld verwies, was ich rausgekickt hatte.
Ich wusste nur nicht, dass dieses kundenindividuelle Feld in einer Extension verwendet wurde
Nach ein "bisschen" fluchen, weinen, resignieren hab ich dann doch in die Erweiterungsverwaltung geschaut und die Extension deinstalliert - man muss nun halt auch noch an dieser Stelle nachsehen.

@enh, ich denke Microsoft versucht bei v14 mehr Stabilität reinzubringen und merkt selber, dass die monatlichen CUs gerade auch in Hinblick auf die Technologieveränderung nicht wirklich ....zielführend sind.
Die Ressourcen müssen ja auch irgendwo her kommen, um die CUs zu programmieren und gleichzeitig auf den Fall-Release hin zu arbeiten.

Auch wenn es nun sehr Offtopic und mehr geworden ist als ich eigentlich schreiben wollte, es passt irgendwie zu den letzten Posts

Ich finde, ein gutes Programm erzählt eine Geschichte, was passiert, wenn man an einer bestimmten Stelle vorbei kommt.

Ist richtig und das tut es auch weiterhin, nur eben auf Modulebene.

Außerdem wird sklavisch an irgendwelchen Design- Richtlinien festgehalten, und eingeführter stabiler Code durch eine Unmenge von SalesSetup.GET ersetzt, weil man keine Globalen Variablen mehr haben will.

Ich muss dir ehrlich sagen, ich begrüße diese Änderung sehr.
Wenn ich an stelle X in CU80 bin möchte ich Wissen was ich zur Verfügung habe und nicht erst alle 87 globalen Variabeln (Stand 2018CU18) überprüfen.
Die Regel gibt es auch in unseren Code-Richtlinien, globale Variabeln sind nur auf Pages erlaubt.
Und ob nun 5x SalesSetup.Get gemacht wird oder nicht, ist doch wurst, das wird eh übern Cache gehändelt

Man mag es vielleicht anders sehen wen man NAV seit anfang an begleitet und genau weis an welcher Stelle was passiert und welche Variabeln gefüllt werden. Die Einstieg für neue Entwickler ist dadurch aber so extrem komplex.

Das größte Problem in der Software- Entwicklung scheint aber die mangelnder Erfahrung der Entwickler zu sein. Das ist allerdings kein Problem von Microsoft alleine.
Wenn Buchhalter entscheiden, das Leute frisch von der Uni billiger sind als Programmierer mit 10 und mehr Jahren Erfahrung, muss sich nicht wundern, wenn da nichts Vernünftiges dabei herauskommt.
Ein Entwicklerteam sollte immer aus Erfahrenen und Neulingen bestehen, damit der eine von dem Anderen lernen kann. Wobei das nicht nur in eine Richtung gehen sollte.

Das ist nen Punkt wo ich dir 100% recht gebe, hinzu kommt das das NAV Umfeld (im Gegensatz zu anderen Programmiersprachen und/oder ERP Systemen) relativ schlecht bezahlt ist. NAV wird nur an einer Handvoll Unis überhaupt behandelt, in der Regel ist es SAP.
In den 5 Jahren, die ich nun im NAV Umfeld tätig bin, musste ich leider feststellen, dass vor allem von älteren "Entwickler" oft einfach nur Code von A nach B kopieren weil sie es immer so gemacht haben und das an der anderen Stelle so funktioniert, aber sie mir nicht erklären konnten warum. Wie oft hab ich gesehen das sie immer noch rec.findfirst; repeat .. schreiben.

durch Extensions hab ich vor kurzem eine Liste / Karte nicht mehr öffnen können - Grund war, dass die Extension auf ein Feld verwies, was ich rausgekickt hatte.

Wie hättest du das Ganze denn mitbekommen wenn es keine Extension gewesen wäre? Du hättest alles exportieren und mit where used überprüfen müssen. Oder du hättest die besagte Page Compelieren müssen um es mitzubekommen.
Jetzt Deinstallierst und installierst du einfach die Extension neu und diese sagt dir beim Installieren dann ob nen Fehler existiert.

----

Ich bin Softwareentwickler aus Leidenschaft, ich habe spass daran saubere (sowohl vom Code, als auch von der usability), elegante Lösungen an den Endnutzer zu überreichen.
Ich begrüße die meisten Änderungen die Microsoft macht, denn es ist der Zahn der Zeit. Es gibt nicht mehr DIE Lösung, sondern man "klickt" sich seine Lösung aus verschiedenen Modulen zusammen.

Wir haben angefangen im August 2017 mit Extensions zu beschäftigen und zu testen was möglich ist und was nicht.
Seit Februar 2018 entwickeln wir 99% unserer Anwendung in Extensions. Der letzte Prozentpunkt beschränkt sich in der Regel darauf neue Publisher zu implementieren - dabei orientieren wir uns an den BC releases ob dort ggf. publisher dafür implementiert wurden.
Alle unsere Änderungen müssen in 4 verschiedene Lokalisationen implementiert werden.
Jeder unserer Entwickler entwickelt lokal auf seinem Rechner gegen eine Docker Instanz. Jede Änderungen an unserem System geht in eine Versionkontrolle und wird erst einmal gegen alle notwendigen Lokalisierungen getestet und gegen Coderichtlinien gecheckt. Wenn alles gut ist wird das ganze in allen Testsystem bereitgestellt (und das in weniger als 3 minuten).
Allerdings muss ich zugeben das wir derzeit noch keine Unit Tests haben

Vorteile die ich sehe:
* CU Updates kosten keine Zeit mehr
* Module sind komplett separiert
* Kein rumhantieren mit DeltaFiles mehr wenn die Extension in verschiedene Lokalisierungen gespielt werden soll
* Es kann nichts mehr vergessen werden wenn eine Extension von eine in die andere Datenbank kopiert wird
* Übersetzungen sind komplett von der Entwicklung losgelöst
* super einfache Versionskontrollen implementation (auch CI / CD)
* Code lässt sich schneller schreiben
* endlich keine .dll Dateien mehr

Nachteile die ich sehe:
* Man kann in sehr grossen Extensions schnell den Überblick verlieren
* "Mach mal schnell" ist nicht mehr wirklich möglich (obwohl ich das für Entwickler nicht wirklich nen Nachteil ist)
* Für ein Update eines Moduls muss die Vorgänger version deinstalliert werden - es muss sichergestellt werden das kein Nutzer im System ist

Was ich vermisse
* eine Möglichkeit Dependencies optional zu machen

durch Extensions hab ich vor kurzem eine Liste / Karte nicht mehr öffnen können - Grund war, dass die Extension auf ein Feld verwies, was ich rausgekickt hatte.

Wie hättest du das Ganze denn mitbekommen wenn es keine Extension gewesen wäre? Du hättest alles exportieren und mit where used überprüfen müssen. Oder du hättest die besagte Page Compelieren müssen um es mitzubekommen.
Jetzt Deinstallierst und installierst du einfach die Extension neu und diese sagt dir beim Installieren dann ob nen Fehler existiert.

ich hätte einfach alles kompiliert - was ich damit ausdrücken will: man muss sich auch an die Neuerungen gewöhnen. Manchmal braucht man für eine Kleinigkeit halt Ewigkeiten, weil man einfach garnicht so weit gedacht hat (so wie ich).
Das kommt mit der Zeit, so wie alles.

Wir beschäftigen uns auch schon ein paar Tage mit Extensions und haben eine in die Appsource gestellt.
Ich sehe die gleichen Vorteile wie du, allerdings gibt es auch Strategien, die nicht immer von Vorteil sind ....alles in x-Funktionsaufrufe zu verschachteln ....da wird es recht schwer, etwas schnell nachzuvollziehen. Eure Coderichtlinie "Globale Variablen nur auf Pages" ....kann ich leider nicht nachvollziehen....wenn ich an div. Stellen einer CU eine Einrichtungstabelle prüfen muss, sorry, dann mach ich das einmal inital in eine globale Variable ....da ist mir das auch völlig egal, ob das ggf. durch den Cache kaum auswirkungen hat....aber egal jeder soll halt machen wie er will

Thema ab erstem Beitrag abgeteilt von hier.

Vorteile die ich sehe:
* CU Updates kosten keine Zeit mehr
* Module sind komplett separiert
* Kein rumhantieren mit DeltaFiles mehr wenn die Extension in verschiedene Lokalisierungen gespielt werden soll
* Es kann nichts mehr vergessen werden wenn eine Extension von eine in die andere Datenbank kopiert wird
* Übersetzungen sind komplett von der Entwicklung losgelöst
* super einfache Versionskontrollen implementation (auch CI / CD)
* Code lässt sich schneller schreiben
* endlich keine .dll Dateien mehr

Warum CU- Updates keine Zeit mehr kosten verstehe ich nicht.
Wenn ein neues CU kommt musst du prüfen welchen neuer Publisher enthalten sind, und du musst evtl. Subscriber dafür bereitstellen. Du musst prüfen ob sich im Ablauf der Programme etwas geändert hat, und du musst darauf reagieren. Zu glauben, dass in CUs keine "Breaking Changes" enthalten sind, halte ich für ein bisschen naiv.

Auch sind Module nicht komplett separiert. Es gibt immer Abhängigkeiten zwischen Modulen. Aus der Sicht des Entwicklers einer App erscheint es zunächst einfach, weil er nur seine App sieht. Für denjenigen, der das ganze beim Kunden um laufen bringen muss wird es schon schwieriger, Denn der Kunde erwartet, das die wie du sagst "zusammengeklickten Module" auch zusammenarbeiten.
Beispiel aus der Praxis: Der Kunde verwendet NAV, eine Handelslösung, ein Zahlungsmodul, eine Webshop- Addon, und eine Logistik- Lösung. Der Kunde möchte die speziellen Suchfunktionen für Artikel au der Handelslösung auch im Webshop- Addon benutzen, denn er erwartet eine integrierte Lösung. Der Zahlungsverkehr soll Online-Aufträge freigeben, wenn Zahlungen eingegangen sind. Das Webshop- Addin benötigt benötigt die Trackingdaten aus der Logistiklösung, damit es die zeitnah an Amazon und eBay melden kann. Die Handelslösung hat eine spezielle Preisfindung, weil die in der Branche üblich ist. Die Preise müssen aber auch in den Webshop, genauso wie die Daten des Produktkonfigurators, die speziell für diesen Kunden entwickelt wurde. Wieviele abhängige Apps für alle möglichen Kombinationen willst du denn erzeugen und pflegen, damit das funktioniert?

Die Extensions haben haben an viele konzeptionelle Schwächen, die für den Entwickler einer App für den Standard zunächst nicht ersichtlich sind, denn seine App funktioniert ja damit. Probleme treten dann auf, wenn mehrere Apps zusammenspielen sollen. Die Kunden erwarten eine integrierte Lösung, die durchgängig einheitlich funktioniert. Das bieten andere Anbieter deren funktionellere Lösung die gleiche Handschrift im ganzen Programm zeigt. In NAV nervt es manchmal schon, wenn das eine Addon nur markierte Datensätze einer Liste verarbeitet, das andere Addon aber alle angezeigten.
Außerdem gibt es nahezu unendlich viele Branchenspezifika, die BC zu einer Eventpublisher/Subscriber- Lösung mit ERP-Addon verkommen lassen würde, oder wie würdest du eine Lösung bauen, die mehrere Skonti pro Beleg benötigt?

Das man Code schneller schreiben kann mag schon sein. Aber wenn man sich die Integration von CRM und MS- Graph in NAV 2019 mal anschaut, dann wird man feststellen, das diese Lösung wohl kaum so ausgesehen hätte, wenn man das ohne Events hätte realisieren müssen.

Ich habe nichts gegen die Gedanken, die hinter dem ganzen stehen, das Addons einen möglichst kleinen Fußabdruck im NAV hinterlassen sollen. Auch sollten Addons möglichst gekapselt sein, und Interfaces für andere Module bereitstellen, um Events in anderen Addons zu ermöglichen, genauso wie die Möglichkeit Daten aus dem Kundensystem abzufragen, die nicht dem Standard entsprechen.
Das alles ist kein Problem in C/SIDE, das mit den Abhänigkeiten der Module außerdem wesentlich weniger Probleme zu haben scheint als AL.

Mal abgesehen davon, das zusätzliche Felder in Postentabellen über zusätzliche Tabellen pro Addon, wie zur Zeit gelöst, und die Unmöglichkeit optimierende Schlüssel über alles zu erstellen sicher nicht zu Performance- Verbesserungen führt wenn der Kunde eine Wertpostentabelle von 48 GB Größe (optimiert) hat. und sich mehrere Addons darin befinden.

Ein weiteres wichtges Thema, das noch nicht angesprochen wurde, ist das Thema Support: KLeinste Fehlerkorrekturen können nur noch während der Betriebspausen durchgeführt werden. Nur dumm, wenn der Kunde ein Dreischicht- Produktionsbetrieb ist, und es sich dabei um ein gravierendes Problem handelt, nur Weil in einem Report ein falsches Vorzeichen falsche Werte berechnet.

Gruß Fiddi

Eventuell soll es nun in der nächsten Woche so weit sein.
Wer Zugriff auf Yammer hat, kann die Diskussion dazu hier aufrufen.

Halbwegs feste Releasetermine für CUs sind ab BC 14 auch in Zukunft nicht mehr zu erwarten .

Freddy Kristiansen schreibt:
"The docker image is there now. KB+DVD's are on their way out"

Und:
"14.2 was never shipped - 14.3 is called CU2 - not sure about BC SaaS"

Nach außen hin heißt's also "CU 2", intern "14.3". Damit auch wirklich jeder verwirrt ist. Faszinierend!

Sorry,
ich muss mal gerade einen einen Kommentar zu einem Bericht zum Thema "Agile Entwicklung" auf Heise hier posten.

Zitat: von https://www.heise.de/forum/heise-Developer/Kommentare/Die-Einfuehrung-agiler-Softwareentwicklung-und-von-Scrum-bei-Heise-Teil-1/Agile-im-Bauwesen/posting-34967987/show/

Agile im Bauwesen

Bauherr, Architekt und ausführende Firmen einigen sich darauf, das Häuschen "agil" zu bauen. Eine schnuckelige Butze im Grünen, unterkellert, mit Garten.

Die Sprintdauer beträgt 3 Wochen zu 4 Sprints. Alle sind glücklich. Der Bauherr ob der kurzen Baudauer, der Architekt, weil er glaubt mehr Verantwortung delegieren zu können und die beteiligten Firmen, weil sie denken, ihre Resourcen sinnvoller aufteilen zu können.

In Sprint 1 wird dann auch gleich mal der Garten gemacht, der Gartenbauer kann im Fortlauf keine MA mehr freistellen, während die Dachdecker schon mal die Dachkonstruktion zusammendengeln. Das muss auf dem Nachbargrundstpück gemacht werden, da der Gartenbauer gerade die Pflanzen einsetzt und den Rollrasen ausbreitet, bis zu der Stelle, wo das Wohnzimmer hin soll. Das ist das Commitment der Maurer. Beim Sprintreview stellt sich heraus, dass Elektriker und Installateure die Anschlüsse vermissen, die sie im Keller verorten. Der allerdings sollte erst im Sprint 3 entstehen, weil dann dort die Tiefbaufirma Zeit hat. Der Architekt bastelt an dem Zeitplan, den er nicht gefährdet sieht. Der Hausherr hat erste Bedenken.

Voller Elan startet Sprint 2: In täglichen Standups beraten die Beteiligten, was aufgrund des nicht vorhandenen Kellers nun gemacht werden könnte. Der kleinste gemeinsame Nenner ist, dass man die restlichen Räumlichkeiten um das Wohnzimmer drappiert und bodenmäßig absichtert, sodass die nachträgliche Unterhöhlung des Gebäudes dieses nicht instabil werden läßt. Das läßt nun auch die Maler, Elektriker und Installateure ihre Teilgewerke ausführen. Das Sprintreview 2 beweist, dass die Methode nach Startschwierigkeiten im Sprint 1 zu schnelleren sichtbaren Ergebnissen führt. Alle sind zufrieden, der Bauherr spendiert eine Kiste Bier und plant schon die Anschaffung seiner Möbel.

Sprint 3 startet mit der Vollendung des Mauerwerks, die Fassade kann gemacht werden, energetisch voll auf der Höhe. Heizung wird eingebaut, Bäder gefliesst und möbliert. Die Innenausstattung wird abgeschlossen, Rohputz aufgetragen und Estriche gelegt. Glücklich liegen sich alle beim Sprintreview in den Armen, eine Gemeinschaft von Freunden, die das Richtfest auf das nächste und letzte Review festlegen. Die Tiefbaufirma kündigt die Unterhöhlung im nächsten Sprint an. Wegen der offensichtlichen Fertigstellung des Gebäudes terminiert der Bauherr den Einzug vor.

Im Sprint 4 gilt es die logistische Herausforderung aufzunehmen, massive Tiefbaumaschinen mit Abraumbedarf und gleichzeitig starke hydraulische Hebemaschinen für das Dach auf dem kleinen Grundstück zu platzieren ohne den bereits angelegten Garten zu beschädigen. Das Entgegenkommen der Nachbarn ist stark eingeschränkt, es werden erste amtliche Schriftstücke versendet ob der Entfernung von Eigentum auf ihren Grundstücken. Aufgrund dieser Impediments werden die Tasks der Unterhöhlung auf einen nachträglichen, zusätzlichen Sprint gelegt. Die Aufstellung des Daches hat aufgrund angemahnter rechtlicher Schritte des Nachbarn absolute Priorität. Das trotzdem durchgeführte Richtfest im eigentlich letzten Review besticht durch die ostentative Kühle aller Beteiligten und endet in gegenseitigen Schuldzuweisungen,Leugnung und Delegation jeglicher Verantwortung. Die Bierkiste wird nicht mal angelangt.

In Sprint 5, den es eigentlich nie geben sollte, stellt sich heraus, dass aufgrund der rechlichen Situation die Gartenfläche für den Abraum und als Stellplatz der Grabmaschinen benötigt werden. Das Absichern des Gebäudes erweisst sich schwierig, da das Wohnzimmer ohne Bodenverfestigung errichtet wurde und dadurch sinkt das Zimmer wenige Zentimeter ab, was zu Rissen in der Fassade, im Innenputz,in den verlegten Leitungen und Rohren führt. Die bereits eingestellten Möbel müssen eingelagert werden, Fassadenteile müßen nachgessert und der Estrich entfernt und wieder neu ausgebracht werden. Der Hausherr stellt nun aufgrund finanzieller Engpässe den Bau ein und beauftragt einen Anwalt mit einem bestimmt langjährigen Rechtsverfahren unbekannten Ausmasses. Seine Frau reicht die Scheidung ein. Die ausführendend Firmen melden aufgrund ausstehender Zahlungen Konkurs an und entlassen ihre Mitarbeiter. Der Architekt ist überzeugt von der vorgehensweise und schreibt ein Buch.

Irgendwie passt das.

Gruß Fiddi