GELÖST Moderne Entwicklung und Dynamics NAV ?

Hallo zusammen,

ich beobachte die letzten 8 Jahre das sich in der NAV Welt wenig tut in Sachen moderner Entwicklung.
Ich meine die meisten Methoden und Tools sind nicht neu ...

-Versionskontrolle
-Clean Code
-Test Driven Development
-agile Vorgehen oder Scrum

Eine Versionskontrolle als Softwarehaus zu haben hat bei mir den Stellenwert wie beim Friseur der Kamm und beim Maurer die Maurerkelle.

Viele Firmen haben keine ordentliche Versionskontrolle, daraus folgend keine automatische Buildumgebung und daraus resultierend machen sie die Tests auch nicht automatisch.

Es gibt bei den Dynamics NAV Gurus (Waldo,Kine, Marije Brummel) immer wieder eine Menge Inputs und Ideen wie man die Prozesse besser machen kann, allerdings bekomme ich das Gefühl diese Innovationen bleiben irgendwo stecken.

Wie ist euer Feeling dazu?

Zuletzt geändert von Nody3000 am 19. Juli 2018 17:13, insgesamt 1-mal geändert.

Mein Gefühl ist, dass sich gerade in den letzten Jahren richtig viel tut.
Ich meine - wir stehen kurz davor VS Code als Entwicklugnsumgebung zu nutzen.

Wenn das kein Sprung ist, was denn dann?

Die neue Sprache entwickelt sich auch jeden Monat weiter, siehe: https://blogs.msdn.microsoft.com/nav/20 ... er-update/

... entwickelt sich auch jeden Monat weiter...

Was mir etwas Sorge bereitet, ist die Frage nach der Zukunft.
Nachdem Windows Phone 10 nun endgültig begraben wurde, hoffe ich, dass Nadella das nicht irgendwann mit der MS Dynamics Produkte macht.
Ich hatte bis zuletzt ein Nokia 930 und habe immer noch eine Xbox One daheim.
Hoffentlich trifft Microsoft die richtigen Entscheidungen in Zukunft und denkt an die Kunden, Partner und weltweite Community.

Es gibt keine Garantien. Mit VS Code und AL bekommt man Zugriff auf eine neue Entwicklungsumgebung, git-Integration, ggf. Testbarkeit, die spannendere Frage ist aber wohin sich der Client entwickelt. Und was man ändern darf und was nicht. Ich persönlich halte Extensions und Events nicht für die beste Idee. Als Beispiel, "unsere" AddOns könnte ich als Extension und mit Events einfach nicht umsetzen. Ich bräuchte zu viele Integration Events, die Laufzeit wäre eine Katastrophe, und die Idee das man aus Lizenzgründen die Extension einfach deaktiviert (z.B. Abo nicht bezahlt) kommt einer Zerstörung des gesamten Systems gleich. Wenn es nur darum geht tatsächliche, unabhängige, "zusätzliche" Funktionen bereitzustellen mag man mit diesen Einschränkungen auskommen. Das reduziert aber den Anwendungsbereich in dem man sich bewegen kann drastisch. Ich halte das für einen der Knackpunkte ob das Gesamtkonstrukt und der Markt von Dynamics NAV überleben kann. Moderne Entwicklung ist dann eher ein Nice to Have, aber nicht unbedingt überlebenswichtig - man kann auch im jetzigen Framework modern entwickeln, man muss nur recht diszipliniert sein.

Dem ist nichts hinzuzufügen!!!

Hallo zusammen,
danke für die Antworten.

Ja, was Mircosoft da leistet finde ich toll auch wenn die eine oder andere Neuerung noch nicht ausgefeilt ist (perfekte Entwickler werfe den ersten Stein )
Microsoft benutzt git und gibt uns den ebenfalls angenehme TFS
Microsoft gibt uns Dynamics NAV Docker Container in vielen Sprachen und Versionen
Microsoft macht AL Code in der Cloud möglich (Offline Version ist mir nicht bekannt bis jetzt?)
Microsoft baut Test Frameworks und soweiter.
Alles tolle Sachen nur Cracks benutzen wenn ich das richtig "fühle".

Worauf meine Frage abzielt ist, kennt ihr Dynamics NAV Solution Center die diese Technik einsetzen ?
Benutzt ihr in der täglichen Arbeit dieses Tools und Methoden ?
Ich hatte zuletzt mit etwa 16 Unternehmen zwischen 2013 bis heute zutun von diesen 16 haben ganze 2 eine echte Versionskontrolle im Einsatz.
Die anderen benutzen ein Tool mit der man zusammen auf einer Datenbank entwickeln muss, mit allen Unannehmlichkeiten die man dabei hat.

Damit kämpft man dann selbst bei kleinen Teams mit den Nachteilen von Lock_Modify_Write
Kontinuierliche_Integration ist auch nicht möglich und die Entwicklungspower kann man dann auch nicht freisetzen. (Cherrypick,Branching oder Automerge)

Firmen die im Jahr 2017 keine "externe" Versionkontrolle kennen, werden wenn Dynamics Nav Source in Visual Studio geschrieben wird vermutlich recht kalt erwischt oder ?
Kurz: Was Microsoft baut schön aber wie kommt das zu uns ?

Hier nur mal 2 Beispiele was ich meine aus dem Jahr 2014
https://dynamicsuser.net/nav/b/kine/posts/automatic-builds-of-microsoft-dynamics-nav
https://marijebrummel.blog/2014/08/15/dynamics-nav-git/

Kontinuierliche Integration leben wir. Im Handbetrieb mit 3 Datenbanken (dev, test, release, live) - ok das sind 4, release wird aber nur für komplizierte bzw. umfangreiche Fälle benutzt. Und mit SVN. Ticketverwaltung in Jira. Abgespeichert wird in .txt-Format. Wir haben auch erste Versuche mit git unternommen, geht auch. Mein bevorzugtes Tool ist immernoch TortoiseHG (also mercurial), jetzt seit 4 Jahren erfolgreich im Einsatz für mehrere AddOns und Kundendatenbanken. Wenn ich meine git-Abneigung überwunden / eine praktikable grafische Oberfläche für die normalen Anwendungsfälle habe, steige ich irgendwann darauf um. Zur Zeit besteht dafür keine Notwendigkeit.
Wenn man diesen Verhau benutzt muss man sehr diszipliniert sein. Man muss einiges an Vorschriften verfassen, und dann auch schulen/durchsetzen. Die Vorteile überwiegen aber ganz klar, sofern man die Disziplin durchgesetzt bekommen hat. Für die intensive Nutzung der "schickeren" Funktionen wie Merges, Rebase braucht es aber Leute die das auch gern machen und wissen, was man Erwarten kann und wo immer zusätzliche Arbeit nötig ist. Die Geduld hat nicht jeder.
Automatisierte Builds/Tests sind ganz weit weg, aus mehreren Gründen:
1. Je nach eingesetzter Version geht es gar nicht / nur mit wildgewordenen Powershell-Skripten. Die verfügbaren Frameworks sind höchsten Beta.
2. Jemand muss die Tests schreiben. Die müssen Sinn machen. Also jemand mit Erfahrung in NAV/ERP und möglichst auch in Tests. Das macht nur für bestimmte größere Sachen Sinn, wie z.B. ein AddOn. Dann ist immernoch die Frage was man testet. Geschäftslogik? GUI? Das gesamte System? Da verbringt man viel Zeit das zum laufen zu bringen ohne für die Firma etwas unmittelbar "nützliches" zu machen - ohne Garantie das es viel bringt. Das geht meiner Meinung nach erst ab einer gewissen Firmengröße.
Ganz generell bin ich der Meinung das Microsoft etwas umsetzen will das so am Markt nicht gewollt wird. Das geht für Microsoft evtl. nicht schlecht aus, für alle Partner aber mit hoher Wahrscheinlichkeit. Im Endeffekt verschwindet dann ein gut anpassbares ERP für kleine und mittlere Unternehmen vom Markt.

Hallo,

das Problem bei NAV ist leider, das es zwar au vielen einzelnen Objekten besteht, die meisten aber von einander abhängen, und man nur wenig programmieren kann ohne dass es andere Objekte beeinflusst. Arbeiten also mehrere Entwickler an einem Projekt funktioniert das nur sehr begrenzt unabhängig von einander, daher das arbeiten in nur einer Datenbank um schnell auf andere Anpassungen bzw. Fehlerkorrekturen zugreifen zu können.

Aus dem gleichen Grund benötigt man (heute) auch nicht wirklich eine Versionskontrolle in NAV. Wenn man ein Projekt/Produkt fertig hat, archiviert man eine Datenbank oder den Objektstand derselben und fertig. Muss man Mergen, holt man sich die entsprechenden Objektstände, und mergt die sich unterscheidenden Objekte.

Tests zu schreiben lohnt sich nur, wenn man diese Tests wiederholen will/muss, d.h. man entwickelt ein AddOn, das man über mehrere Generationen pflegen möchte. Wie Jens schon erwähnt, benötigt es für diese Tests aber erfahrene Programmierer, die eigentlich besser sein müssen als die eigentlichen Entwickler des Moduls, und welche Firma wird schon derart Ressourcen verschwenden.

Ich sehe eine ähnliche Gefahr wie Jens, dass aus NAV ein Produkt entsteht, das irgendwann Closed Source wird, dass wirklich nur noch über Extensions erweitert werden kann. Das würde aber dazu führen, das NAV für viele Anwendungen nicht mehr einzusetzen wäre, weil Anpassungen die heute Minuten dauern, gar nicht oder nur Umständlich zu realisieren wären.

Dann hätten wir wahrscheinlich irgendwann die Fortsetzung des Films "Windows Phone", das wurde auch mit großem Hurra präsentiert, um dann am Ende sang- und klanglos in der Versenkung zu verschwinden.

Gruß Fiddi

Hallo zusammen, ich bin eindeutig noch zu selten hier. Ich vergesse immer mein Passwort und muss es dann reaktivieren .

@jglathe ich benutze GIT Extensions
Evtl hilft dir das.

Nun die Fühlung reicht mir. Agile Prozesse bei Dynamics Nav sind eindeutig noch nicht angekommen.
Ich nehme das zum Anlass mal darüber zu schreiben.

@Fiddi in dem Fall mit den Objekten sehe ich das genau anders.
Dort sind die Stärken, da man meistens ein Feature geschlossen entwickelt statt auf etwas aufzubauen was ein anderer Entwickler noch nicht fertig hat.
Allerdings habe ich selbst den Fall schon erlebt. Die Update (Push/Pull) Frequenz war einfach höher als normal und man musste sich mehr austauschen als sonst.
Eine Versionskontrolle wird nur Wertvoller mit der Anzahl der Versionen/Kundenversionen die man Verwalten muss da man jetzt Branchen kann statt in einer Datenbank zu arbeiten.

Ich möchte hier zum Schluss auf einen Thread verweisen den ich auf Stackoverflow gefunden habe weil ich mich zugleich mit TFS und SVN als mögliche Versionskontrolle ansehe.

https://stackoverflow.com/questions/7197306/using-git-to-version-microsoft-dynamics-nav

EDIT: Some updates after more than half year of coding.

We switched back to git. Since its automatic merge is AWESOME. Just to win the bet I've moved a solution (modified standard objects and new ones) from NAV7CTP3 to NAV7CTP5 in 4 hours. While a team of four developers achieved the same result needing almost three weeks of everyday work.

Git really makes a difference. I believe the same results are possible with other distributed version control systems.

The reason is: Git and other distributed systems save a lot more information during a commit than i.e. TFS and SVN. It is not so important during regular development, but when it comes to merging, all this 'redundant' information from Git makes the difference.

During the merge Git finds the common revision which started a branch and then applies changes from both branches step by step - in the same way as the developer changed the code - to all files in solution.

If the same line was changed in both branches it shows the conflict. If not it just saves the files into the working folder ready for commit.

Here some statistics:

The Total number of files processed in both CTP3 and CTP3 codebases is around four thousand each;
The Total number of the solution's objects merged is 1170;
The Total number of conflicting files is 140;
The rate of successful automatic merge is about 88% (1170 – 140) / 1170 * 100 = 88%;
Most conflicts are changes in the object's versions — trivial;
None-trivial conflicts in about 20 files;
Trivial find and replace was done on all merged objects (to fix RunFormOnRec -> RunPageOnRec, etc.);
The result is a fully importable set of the most recent solution objects based on CTP5;
The Number of compile errors after import is about 50;
Most of these errors relate to changes in standard objects done from CTP3 to CTP5;
The rate of faulting objects is around 4% (50 / 1170 * 100% = 4%);

Danke nochmal für euer Feedback

Git <-> Mercurial: Ähnliche Erfahrung. Ich mache viele große Merges, und die Merge-Funktion in Mercurial ist relativ gut. Man kommt aber nicht umhin aufmerksam zu sein und man muss den Code schon verstehen. Was aber als Konflikt angezeigt wird ist in 99,9% der Fälle wirklich einer, "falsche" automatische Merges gibt es nur unter bestimmten Bedingungen.

Hallo,

ein schönes Beispiel für falsche Merges sind die von MS in einem CU ins englische konvertierte deutsche Textkonstanten. Die dürften bei jedem automatischen Merge- Tool ohne Probleme durchgehen. Trotzdem will man Sie nicht beim Kunden haben.

Gruß Fiddi

Sag mal jglathe wenn du jetzt SVN gegen Mercurial oder ggf. GIT vergleichst,gibt es Gründe die für SVN sprechen oder sollte man sich direkt an eine dezentrale Variante halten ?

Gruss Nody

Meiner Meinung nach sollte man nach Möglichkeit nicht mehr mit SVN starten. Besser gleich git (wenn man damit klarkommt). Wichtig ist an der Stelle das Verwaltungsmodell: Gibt es ein Master Repository wo einer die Gewalt drüber hat (und sonst niemand)? Das ist das Repository was man für gewöhnlich auf github ablegt, oder auf einem eigenen Server. Lokal kann man sich einen Branch pro Ticket (z.B.) anlegen, gemerged wird für gewöhnlih gegen master. Pull Requests laufen auch nur gegen master. Etwas mehr Überlegung erfordert die Produktpflege bei mehreren unterstützten Versionen, weil man auf bereits veröffentlichte Versionen eigentlich nur Fixes veröffentlicht (oder veröffentlichen will). Das erhöht den Aufwand dann schon erheblich, ist aber mit DSCM überhaupt erst sinnvoll machbar. Spätestens an dieser Stelle wäre man mit SVN am Ende angelangt - der Aufwand wird dann schon sehr groß.

Diese Aussage deckt sich mit den Quellen im Internet sowie ein paar Meinungen von Entwicklern die SVN benutzen.
Hoffentlich erspart das einigen die suche für die Zukunft. :)

Ich selbst habe mehrere Jahre mit Git gearbeitet und kenne SVN nicht. Daher habe ich immer das Gefühl die Sache zu "Pro Git" zusehen.

Quellen aus dem Internet wie

git-vs-svn-eine-vergleichende-einfhrung-64-728[1].jpg

helfen da nicht gerade dieses Gefühl zu verlieren.

Stand jetzt haben wir halt weder das eine, noch das andere so das automatisch die Frage entstehen muss ob SVN oder eine verteilte Versionskontrolle.

Ich für meinen Teil werde mal noch ein bisschen Mercurial vs Git lesen

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Mercurial vs Git ist so ein bischen akademisch. Mercurial ist halt Python, und kann an manchen stellen weniger als Git. Ist aber leichter zu bedienen und zu verstehen. Git ist "schneller", und kann halt ein paar mehr Dinge. Wie z.B. Octopus Merge (mehr als 2 Branches auf einmal mergen), Cherry-Pick Merge. Das ist dann aber schon ziemlich speziell. Die meisten Sachen gibt es auch bei Mercurial. Beide sind mow kompatibel, was die gedankenwelt des Benutzers betrifft.