Verschiedene CU Stände verwalten

Heyho,

ich habe aktuell das Problem, mehrere unterschiedliche CU-Stände gleichzeitig vorhalten zu müssen, sprich ich habe sowohl auf dem Server als auch auf den Clients mehrere unterschiedliche Buildstände, die sich aber trotzdem nicht gegenseitig ins Gehege kommen dürfen.

Da ich wohl kaum der einzige mit diesem Problem sein werde, würde mich interessieren wie andere diese Herausforderung gemeistert haben. Über Anregungen und Tipps würde ich mich freuen.

FG
Thomas

kann das ServiceTierAdministrationTool nur sehr empfehlen.
Wir verwalten damit all unsere Stände...

https://mibuso.com/downloads/service-tier-administration-tool

Weiterhin lege ich die CU-Stände immer in folgender Reihenfolge ab:

Ohne CU: C:\Program Files (x86)\Microsoft Dynamics NAV\XXX\RoleTailoredClient\
Mit CU: C:\Program Files (x86)\Microsoft Dynamics NAV\XXX\RoleTailoredClient CU YY\
xxx = NAV-Version
gleiches natürlich auch beim Server

sofern benötigt, lade ich Management-Befehle in die Shell
Import-Module "C:\Program Files\Microsoft Dynamics NAV\XXX\CU YY\Microsoft.Dynamics.Nav.Management.dll"

-> also gerade wenn die Meldung kommt, das Client-&Serverversion unterschiedlich sind.

Damit das RUN aus der Entwicklungsumgebung (oder der Debugger Start) funktioniert brauchst du ein Tool dass jeweils die lokalen Registry Einträge anpasst.

Privat oder auf dem Notebook nutze ich auch das ServiceTierAdministration-Tool.

Im Betrieb wird dagegen alles aus einer von allen Mitarbeitern zusammen in langer Entwicklung erstellten internen NAV-Datenbank verwaltet.
In groben Zügen:

• Eine Tabelle für die Datenbanken (das sind Tausende). Hier stehen auch interne Kopier-/ Verschiebungs-/ (Rück)sicherungsfunktionen zur Verfügung, die vieles, was sonst vom SQL-Server-Management-Studio erledigt werden müsste, ausführen können
• Eine Tabelle für alle Builds aller Versionen mit den Clientpfaden, Downloadlinks, Releasedaten von Microsoft und unseren Versionen.
• Eine Tabelle für manuelle 2-Weg-Merges ("Mergeaufträge"), die mehrfach auf die Datenbanktabelle verlinkt. Von hier werden parametriesierte PowerShell-Skripte aufgerufen, welche die benötigten Objekte aus diesen Datenbanken exportieren, importieren und kompilieren können.
• Eine Tabelle für automatische 3-Weg-Merges, die auch mehrfach auf die Datenbanktabelle (als ORIGINAL, MODIFIED und TARGET, aus RESULT entsteht dann die neue Datenbank) verlinkt. Auch hier PowerShell-Skripte als Menüpunkte, hier dann zusätzlich welche mit Mergecmdlets, Sprachlayerfunktionen, Navx-Extensionerstellung
• Pro Datenbankkonvertierungstufe wird ein neuer virtueller Server erstellt und die jeweiligen Clientverzeichnisse, außerdem monatlich alle Clientbuildverzeichnisse nochmal separat. Servertrennung für Vorlagen-, Kundendatenbanken, "Spielwiesen" für interne Entwicklung usw.
• Eine Tabelle für die auf den Servern laufenden Dienste mit Servernamen, Instanzen, Portnummern etc.
• Pro Datenbankkonvertierungsstufe stehen mehrere Dienste zur Verfügung, die durch Auswahl einer Dienstnummer aus der Diensttabelle der Datenbank vom Anwender manuell zugeordnet werden.

Also hochkomplex, aber so auch von Nicht-Entwicklern gut benutzbar, denn bedient wird dann alles im wesentlichen über 3 Buttons (Start des Dienstes , Start des Windowsclient, Start des IDE) aus der Datenbanktabelle heraus. Auch Testmandanten können hier heraus angelegt (ab NAV 2013 R2) und Schemasynchronisierungen durchgeführt werden.
Beendet wird der Dienst durch Entfernen der Dienstnummer aus der Datenbanktabelle, dann ist er frei für den nächsten Kollegen.

Alles wird "unter der Haube" durch Interaktion von C/AL und Hunderten von Skripten ausgeführt (PowerShell, Scripting Host, SQL-Skripte). Einige davon werden zur Laufzeit aus NAV heraus geschrieben und ausgeführt, wie hier beschrieben.

Danke für die Antworten (auch wenn ich ziemlich spät dran bin).