Upgradeprozess mit ISV Lösungen

Ja, du verstehst mich richtig und so macht es auch für mich Sinn. Die Antwort von Fiddi hat mich aber dann auf den falschen Weg gebracht(oder ich habe es immer noch nicht verstanden):

wenn du einmal auf der Schiene mit dem Mergtool bist, benötigst du eigentlich immer nur die Neue Version. Die alte Version ist das (fehlerbereinigte) Ergebnis des letzten Merges. Die Kunden-Version ziehst du dir die aktuelle.

Das hieß für mich, dass ich nicht die NAV 2017 CU08 Demo Datenbank, sondern die Kundendatenbank mit dem letzten CU (um bei dem Beispiel zu bleiben CU08) als ORIGINAL für den Merge nehme.
Letztlich ist ein CU ja nichts Anderes als ein "kleines" Versions-Upgrade, also muss ich auch beim Merge so vorgehen, wie bei einem "großen" Upgrade.

Da ich eh gerade dabei bin unsere Branche in NAV 2015 nach CU 34 zu mergen hier einmal mein Beispiel;

MergeFenster.png

Hier siehst du den Mergevorgang einmal visuell.
Die Ansicht ist in vier Teile aufgeteilt

• links Oben: meine angepasste BranchenVersion basierend auf NAV 2015 CU33, die ich aktualisieren möchte
• mitte Oben: Die Ausgangsbasis für linke und rechte Version. Diese Version muss ein gemeinsamer Vorfahre von der linken als auch der rechten Version sein. Das kann NAV2015 CU1 sein, besser ist in diesem Fall allerdings NAV2015 CU 33, der in meiner linken- Version schon drin ist. Je näher dran dieser Vorfahre an linker als auch an rechter Version ist, desto besser ist das automatische Merge- Ergebnis. Er darf aber nicht neuer sein als die älteste am Merge beteiligte NAV- Version (außer beim Backmerge)
• rechts oben: Hier ist die Version auf die ich meine linke Version bringen möchte, also das Ziel.
• unten: Hier werden die neu zu importierenden Dateien abgelegt.

Wie man an der Statuszeile unten rechts erkennen kann, gibt es 1629 unterschiedliche Objekte, von denen 894 Inserts (neu) sind (d.h. nur in links und/oder rechts enthalten sind) und 48 Deletes (Löschungen) (d.h. die sind nur in Mitte und Rechts), 3473 Objekte sind identisch (d.h. Links, Mitte und Rechts sind identisch) und es gibt 10 Konflikte bei denen das Tool nicht weiß was es tun soll.

Da ich die Objekte nachher wieder in eine DB importieren möchte, die meine linke Version schon enthält, ist meine weitere Vorgehensweise folgende:

• 1. alle Objekte die in allen Versionen gleich sind, werden ignoriert (ist ein Schalter in dem Tool)
• 2. Alle Objekte die nur links eingefügt werden sollen werden ignoriert (die sind ja schon drin)
• 3. Die Deletions werden geprüft (man kann ja mal was vergessen) und ggf. ebenfalls ignoriert oder ins Ziel kopiert.
• Damit hätten wir von den fast 6000 Objekten schon mal über 4400 erledigt, die auch später gar nicht wieder importiert werden müssen.
• 4. Alle Objekte die nur rechts eingefügt werden, kann ich auch ignorieren (weil es in diesem Fall Objekte des Standards sind, die ich nur per FOB importieren kann), ansonsten müssen diese Objekte ins Zielverzeichnis kopiert werden.
• 5. Von den verbliebenen 1629 Objekten haben 1601 Anpassungen nur auf der linken Seite, d.h. im NAV Standard hat sich hier seit dem letzten Build nichts getan, ich kann meine Anpassungen so übernehmen (also ignorieren, die sind ja schon in meiner Ziel-DB drin). Ich habe mir allerdings angewöhnt hier Stichprobenartig (besonders bei den Objekten mit wenig Änderungen) zu prüfen, ob ich was übersehen habe oder nur Datum und Modified geändert sind, dann setzte ich das Objekt schon mal wieder auf den Standard zurück, was mir beim nächsten Merge wieder Arbeit spart.
• 6. von den verbliebenen 29 Objekten haben 18 Objekte nur Anpassungen auf der Rechten Seite, d.h. MS hat ihnen zumindest eine neue Versionsnummer verpasst. Wenn es dich nicht interessiert was da passiert ist, kopierst du diese Objekte einfach ins Zielverzeichnis, denn die geänderten Objekte sind ja in der Ziel-DB so noch nicht drin. Ansonsten schaust du dir die Änderungen vor dem Kopieren an, um zu prüfen, ob sich daraus Auswirkungen auf deine Anpassungen ergeben. Diesmal waren das im wesentlichen Anpassungen in der Größe von Code- Feldern ( was durchaus gefährlich sein kann, wenn man diese Funktionen in Anpassungen benutzt). Diese 18 Objekte sind Teil meines späteren Textimports.
• 7. Normalerweise gibt es auch Objekte die sowohl links als auch rechts Anpassungen haben, das Mergetool konnte die Änderungen aber automatisch mergen, weil sich die Anpassungen nicht überschneiden. Auch diese gemergten Objekte kommen ins Zielverzeichnis
• 8. Jetzt kommen wir zu den letzten 10 Objekten mit Konflikten, die nicht komplett automatisch gelöst werden. Diese Objekte müssen einzeln geprüft werden und nach Anpassung der Konflikte ebenfalls ins Zielverzeichnis kopiert werden.

So das war der Merge. Die Dateien im Zielverzeichnis müssen jetzt noch wieder zu einer Textdatei zusammengefügt werden, und in die Ziel-DB importiert werden. Wenn du alles richtig gemacht hast, machst du jetzt noch ein Compile all und alles ist gut.(jedenfalls oft)

Was ich mit der Aussage:

Wenn du einmal auf der Schiene mit dem Mergtool bist, benötigst du eigentlich immer nur die Neue Version. Die alte Version ist das (fehlerbereinigte) Ergebnis des letzten Merges. Die Kunden-Version ziehst du dir die aktuelle.

meinte, ist das du beim nächsten mal nur noch das nächste NAV-CU benötigst, und einen neuen Export deiner Kunden- DB. Denn links ist dann wieder deine Kunden-DB (jetzt mit CU34), in die Mitte wandert dein NAV CU34 und rechts ist dann in meinem Falls CU35.
Deshalb solltest du die Textexporte deiner NAV-CUs auch nicht sofort löschen, du benötigst Sie mindestens fürs Mergen des nächsten CUs.

Grusß Fiddi

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

Hey, vielen Dank für deine Mühe! Die Mitte entspricht bei dir dem ORIGINAL aus der Powershell, richtig? Müsste ich dann nicht hier auch in der Mitte immer die Version aus der Demo Datenbank des jeweiligen (aktuellen, vor dem Merge eingesetztem) CU verwenden (die "OldBaseVersion" benötige ich doch eigentlich immer)?
Oder anders gefragt: Worin unterscheidet sich denn die linke Seite und die Mitte bei dir, wenn wir mal davon ausggehen, dass sich zwischen zwei CUs an der Kundendatenbank nichts verändert hat?

Worin unterscheidet sich denn die linke Seite und die Mitte bei dir,

Die linke Seite ist die Datenbank, die du gerade produktiv einsetzt, mit angepassten Pages, verunstalteten Berichten, und anderen Krimskrams, den deine Chefs unbedingt brauchen.
Die Mitte ist der blanke NAV CU auf dem deine Produktiv-Datenbank basiert. (Das kann/sollte ein CU mit deinen Addons sein, wenn du so etwas zur Verfügung hast, und deine rechte Seite ebenfalls diese Addons mit aktuellem CU enthält)

Um den Merge so einfach wie möglich zu machen, sollten die Deltas zwischen allen Versionen möglichst klein sein. Wobei die mittlere Version immer die älteste bzw. gleich alt wie die linke ist, und die rechte Version die neueste ist.

Gruß Fiddi

Ok, das habe ich vestanden. Du schreibst aber

Denn links ist dann wieder deine Kunden-DB (jetzt mit CU34), in die Mitte wandert dein NAV CU34 und rechts ist dann in meinem Falls CU35.

Das bedeutet für mich, das dann beim nächsten Mal in der Mitte die Kundendatenbank mit dem Stand des letzten CUs ist, und nicht mehr die Demo Datenbank auf dem Stand des alten CUs (inkl. evtl. AddOns). Damit habe ich ein Verständnisproblem, von Anfang an übrigens.

Hallo,

ein Frage. Ist deine Kundendatenbank ein Vorfahre von NAV2017 CU35? Entwickelst du für den NAV- Standard?

Falls Ja dann hast du recht, falls nein, wäre es besser du nimmst die Version, die beim letzten Merge die rechte Version war, in die Mitte.

Gruß Fiddi

Deine Frage verwirrt mich jetzt noch mehr. Wovon hängt ab, ob ich die Kundendatenbank mit dem letzten Merge-Ergebnis oder die Demo Objekte als ORIGINAL nehme? Wenn ich laufend die CUs in die Kundendatenbank installiere, ist diese ein Vorfahre von NAV 2017 CU 35- ja. Eigentlich ist ja alles kleiner CU35 ein Vorfahre, auch CU1 oder RTM. In der Kundendatenbank sind typischerweise Anpassungen, die den NAV Standard erweitern/ergänzen oder auch verändern können.

Hallo,

Deine Frage verwirrt mich jetzt noch mehr. Wovon hängt ab, ob ich die Kundendatenbank mit dem letzten Merge-Ergebnis oder die Demo Objekte als ORIGINAL nehme?

Wenn du nur CUs in eine Kundendatenbank willst mergen, hängt das von gar nichts ab. Dann kommt immer nur der Vater-CU für die beiden anderen Versionen in die Mitte, links deine Version mit deinen Anpassungen, rechts die von Microsoft angepasste neue CU. Deine Kunden- Version ist nie ein Vorfahre eines MS-CUs.

Die Funktion ist an Diff3 angeleht Zitat aus Wikipedia:
"This is like subtracting the file older from the file yours and adding the result to the file mine,"

In unsere Darstellungsweise übersetzt heißt das: Der Merge entfernt aus der linken Version alles was in der Mitte enthalten ist, und fügt es der rechten Version an entsprechender Stelle hinzu.

Gruß Fiddi

Ok, das ist jetzt klar. Rein interessehalber: In welchem Fall lässt sich das Ergebnis des letzten Merges in der Mitte verwenden, wie von dir beschrieben? Ich vermute mal, dass das nur für das Aktualisieren von AddOns auf eine neuere CU-Version gilt? Für mich heißt das jedenfalls, dass ich immer die ursprüngliche CU-Version, auf der die Kundendatenbank basiert, als ORIGINAL bzw. Mitte verwende. Im Prinzip nicht anders, als bei einem Versions-Upgrade.

In welchem Fall lässt sich das Ergebnis des letzten Merges in der Mitte verwenden, wie von dir beschrieben? Ich vermute mal, dass das nur für das Aktualisieren von AddOns auf eine neuere CU-Version gilt

Das mach dann Sinn, wenn du in deiner Kundendatenbank seit dem letzten Update Anpassungen gemacht hast, die deine Addons betreffen, und du möchtest die in den Addon/CU übernehmen.
Das ist aber sehr mit Vorsicht zu genießen, und du importierst das Ergebnis dann nicht in deine Kunden-DB sondern in die des Addons/CUs.

Man kann auf die Art und Weise auch ein Addon entfernen, indem man als Mitte eine Version mit Addon und als rechte Version eine ohne Addon verwendet.

Aber solche Merges sind definitiv nichts für die Powershell- Tools, das muss man visuell machen.

Gruß Fiddi

Man kann auf die Art und Weise auch ein Addon entfernen, indem man als Mitte eine Version mit Addon und als rechte Version eine ohne Addon verwendet.
Aber solche Merges sind definitiv nichts für die Powershell-Tools, das muss man visuell machen.

Das geht auch mit PowerShell, wenn dafür die DELTA-Dateien einsetzt, diese aber als "Reverse Deltas", also statt wie üblich kein Zufügungsdelta, sondern ein Entfernungsdelta. Wenn das Setup stimmt, wird der Code sauber entfernt. Alles schon erfolgreich ausprobiert .
Erzeugen kann man die ganz einfach durch Vertauschen der Ordnerinhalte (z.B. in ORIGINAL und MODIFIED) bevor das Compare-NAVApplicationObject-Cmdlet läuft.

Es gibt auch Artikel von Waldo dazu:
Remove customizations with (Reverse) Deltas
Apply-NAVDelta to add and remove customizations

Nachdem ich nun diverse Dinge probiert habe, muss ich noch einmal zu einem Beitrag weiter hinten nachfragen:

Beispiele für Setups
Update Major Release
ORIGINAL: NAV 2016 DE (+ CU xx)
MODIFIED: NAV 2017 DE (+ CU yy)
TARGET: NAV 2016 DE (+ CU xx) + AddOn
RESULT: NAV 2017 DE (+ CU yy) + AddOn

Ich bin gemäß Guideline von Microsoft so vorgegangen:
ORIGINAL: NAV2016 DE Demo DB (+CU xx und AddOn in der eingesetzten Version)
MODIFIED: NAV2016 DE Kunden DB (inkl. CU xx und AddOn)
TARGET: NAV2017 DE Demo DB (+CU yy und AddOn in der zu dem CU yy passenden Version)

@Kowa: Welchen Vorteil hat deine Variante? Hier müsste ich doch anschließend in jedem Fall noch gegen die neuen AddOn Objekte mergen? Ist man über diesen Weg schneller?

Hallo,

einen Vorteil sehe ich in der Variante aus dem Zitat auch nicht, ich vermute hier eher einen Schreibfehler.

Ich finde deinen Mergeansatz schon korrekt. Ob man das mit Addon oder ohne macht, hängt davon ab, was man zur Verfügung hat. Hast du nur das CU, benutzt du nur die CU-Versionen als Original und Target. Mit Addon geht einfacher, weil das näher an der Modified- Version ist.

Ach übrigens:
Wenn du von NAV 2016 nach NAV 2017 mergst, sollten die Builds vom NAV 2016 nicht neuer sein, als das NAV 2017- Ziel- Build. Weil man sonst evtl. Fehlerkorrekturen, die in der NAV 2016- Version schon drin sind, in der NAV 2017 aber noch nicht, wieder ausbaut.

Ob das allerdings so einfach von 2016 nach 2017 funktioniert, hängt von euren Anpassungen ab. Wenn ihr in den Posten-, Beleg- oder Journaltabellen zusätzliche Felder eingebaut habt, musst du aufpassen, da die Art und Weise wie diese Tabellen gefüllt werden sehr stark überarbeitet wurde. Der Merge funktioniert zwar, es passiert aber hinterher trotzdem nicht das richtige.

Gruß Fiddi

@Kowa: Welchen Vorteil hat deine Variante?

Es gibt verschiedene Dokus von MS dazu (und MODIFED und TARGET war mal so, mal so befüllt), funktionieren tun beide Varianten.

Schreibfehler ist das kleiner, das sind Setups, die sich bei mir schon hundertfach bewährt haben und seit Jahren im Einsatz sind.

So sieht das bei mir für die letzten Monate praktisch aus, wird alles aus NAV gestartet, wie hier beschrieben.

MergeSetup.png

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

Du hast natürlich recht.

Das ist reine Gewohnheitssache, was man in Modified (links) und Target (rechts) einträgt.

Und eine Frage ob das Mergetool evtl. in die eine oder andere Richtung bessere Ergebnisse liefert.

Gruß Fiddi

Ich kann mich nur immer wieder bedanken!
Wie verhindert/übergeht ihr Konflikte aufgrund der unterschiedlichen Object Properties beim visuellen Mergen?

Wie verhindert/übergeht ihr Konflikte aufgrund der unterschiedlichen Object Properties beim visuellen Mergen?

Wenn du damit Datum, Uhrzeit, Modified,Version meinst, dann habe ich bei meinem Tool eine Möglchkeit eine "Ignore Regular-Expression" zu setzen, und dann auch zu sagen was er dann stattdessen nehmen soll.

Ich benutze so etwas um z.B. die Objekte heraus zu filtern, bei denen sich nur die Uhrzeit geändert hat (dann allerdings nur im Diff2- Modus). Alle Objekte die gleich sind, bzw. nur Änderungen in den ignorierten Passagen haben, werden grundsätzlich durch die Zielversion ersetzt.

Außerdem haben die Tools teilweise Möglichkeiten nach unterschiedlichen Vorgehensweisen die Unterscheide zusammen zu führen (z.B. Nur Links, Nur Rechts, Mitte, Erst Links dann Rechts,Inline, Erst rechts dann die Änderungen von Links,...)
Gerade der Inline-Merge funktioniert teilweise erschreckend gut. Er versucht dabei aus sich in allen drei Versionen unterscheidenden Blöcken(zeilen) eine(n) neuen zu bauen.

Gruß Fiddi

Hilfreich bei der Vorbereitung von Upgrades und auch sonst : Simplanova Objects Usage Log Tool