AX7 – Code-Upgrade bei ISV-Lösungen

Direkt vorab: Es geht hierbei nicht um Updates von 2012 zu AX7 (obwohl es viele Gemeinsamkeiten gibt) – dazu werde ich gegebenenfalls ein anderes Mal berichten. Solltest du dich speziell dafür interessieren sei für die Zwischenzeit schon mal die Anleitung im offiziellen Wiki mit dem Titel Prepare to migrate to Microsoft Dynamics ‘AX 7’ empfohlen.
Die Artikel hier bezieht sich auf die Aktualisierung von Code und anderen Artefakten zwischen Versionen von AX7. Kurz vor Weihnachten haben wir das Upgrade unserer ISV-Lösung gevis ERP | AX von CTP7 zu CTP8 abgeschlossen. CTP steht für Community Technology Preview und entsprechend kann es natürlich sein, dass die Dinge, die ich aufzeige, bis zur offiziellen Veröffentlichung des neuen Microsoft Dynamics AX noch Änderungen unterzogen werden.

LCS-Projekt mit VSTS verbinden

Man benötigt ein LCS-Projekt mit ‚AX 7‘-Methodik und muss sicherstellen, dass dieses mit Visual Studio Team Services (VSTS oder früher auch mal Visual Studio Online / VSO) verbunden ist. Die Methode zur Authentifizierung wurde kürzlich von Alternate credentials auf Personal access token umgestellt. Bei bereits vorhandenen LCS-Projekten kann es also sein, dass das noch aktualisiert werden muss. Man kann so ein Token im VSTS erzeugen, indem man in seinem Profil (den eigenen Namen rechts oben anklicken und dann My profile) zum Bereich Security wechselt und über Add ein neues anlegt.
Im LCS muss man zunächst die Visual Studio Online site URL angeben und dazu eben das Token (das textuell einfach dort hin kopiert wird) und anschließend das richtige Projekt auswählen.

Den Code Upgrade Service benutzen

Im LCS-Projekt gibt es eine Kachel mit dem Titel Code upgrade. Dort muss man zunächst ein neues Code-Upgrade-Projekt erstellen unter Zuhilfenahme des Button Add auf der linken unteren Seite. Man sollte dann einen treffenden Namen vergeben und gegebenenfalls eine Beschreibung hinzufügen. Für Intra-AX7-Upgrades (Minor) muss man in der Auswahlbox Version den Wert Microsoft Dynamics AX 7 selektieren.
Darüber hinaus gibt es die Option Estimation Only. Diese führt dazu, dass der Service alle Berechnungen etc. durchführt, aber nichts ins Repository der Versionskontrolle schreibt. Auf diese Art und Weise kann man eine Abschätzung über den anfallenden Aufwand erhalten.
Das Werkzeug arbeitet immer mit dem Branch /Trunk/Main, man muss nicht extra angeben, welche genaue Version von AX7 dahinter steckt. Tatsächlich steht diese in der Datei $/YourAX7Project/Trunk/Main/ax7.version, die auch die Basis für den Code Upgrade Service darstellt.

Nachdem sich der Service erfolgreich mit dem VSTS verbunden hat muss man noch die Ausführung des Ganzen in Gang setzen. Das geschieht einfach mit einem Klick auf Analyze code in der rechten unteren Ecke.

Jetzt vollbringt das Werkzeug seine Wundertaten – braucht dazu aber einige Zeit (ungefähr zwei Stunden bei unserem vergangenen Lauf). Es gibt einen Laufbalken, der auch manchmal aktualisiert wird. Man sollte ruhig bleiben, wenn es mal so aussieht, als würde sich nichts tun – wenn viel los ist, kann es sein, dass man sich in einer Warteschlange befindet oder der Fortschritt ist schlicht noch nicht visualisiert.

Nachdem der Code Upgrade Service seine Arbeit getan hat

Man erhält vom Service direkt detaillierte Berichte im Excel-Format serviert. Der Bericht MigrationSummary.xlsx_ExcelReport enthält zum Beispiel Informationen zu Objekten, die modifiziert oder automatisch abgepasst wurden, Zählungen solcher, die Konflikte aufweisen sowie eine Analyse der Abdeckung mit Form Patterns und nicht zuletzt Details darüber, welche Änderungen automatisch in Erweiterungen (Extensions) umgezogen wurden. Im Bericht TaskList.xlsm_ExcelReport findet man alle Tasks, die auch im VSTS angelegt wurden und eine Zusammenfassung, die einem sogar schon die Schätzung für den manuell zu erbringenden (Rest-) Aufwand in Stunden. Tatsächlich sah es bislang so aus, als wäre das Werkzeug gar nicht mal so übel in diesem Ratespiel

Dazu gibt es eine .zip-Datei, das die aktualisierten Metadaten enthält und außerdem zwei kleine Textdateien, wovon eine die genaue Version des Build enthält (AX7 metadata version 7.0.1186.16043_ExcelReport im aktuellen Fall) und die andere eine Liste der Models (Models upgrade_ExcelReport).

Work Items in VSTS

Der Code Upgrade Service aktualisiert nicht nur den Code für einen, sondern hilft darüber hinaus auch mit der Abarbeitung dessen, was anschließend noch erledigt werden muss. So generiert er Work Items von Typ Task im VSTS-Projekt, die einen mit recht genauen Informationen zu dem Objekt, das manueller Behandlung bedarf, versorgen. Dabei wird schon relativ deutlich beschrieben, was getan werden muss und wie groß der geschätzte Aufwand dafür ist.

Den Branch mergen

Der Code Upgrade Service hat den Branch /Trunk/Main nicht verändert, sondern stattdessen einen neuen unter $/YourAX7Project/Releases/ angelegt. Um die Entwicklung von Main auf die neue Version zu heben, muss der entstandene Branch manuell übernommen (gemerged) werden. Dazu macht man im Source Control Explorer in Visual Studio einen Rechtklick auf den Ordner des Branch (also zum Beispiel im Fall unseres CTP8-Upgrades $/YourAX7Project/Releases/7.0.1186.16043_CTP8_2015-12-18T14.33.06), und wählt dann Branching and merging / Merge…. All changes up to a specific version ist im nächsten Schritt die richtige Wahl und als Target branch sollte eben /Trunk/Main dienen. Die weiteren Schritte und Einstellungsmöglichkeiten können mit Standardwerten durchlaufen werden. Im Endeffekt erhält man Pending Changes, die dann unter Versionskontrolle gestellt werden müssen.

Tipps und Tricks

Weiterentwicklung in der alten Version

Natürlich gibt es eine Problemstellung in einem Szenario mit mehreren Entwicklern und deren offenen Entwicklungen zu Zeitpunkt des Upgrades. Wir lösen das zunächst durch die Aufforderung, möglichst wenig offene Entwicklungen zu haben (das lässt sich einigermaßen gut steuern durch den Verzicht, mit komplexeren Dingen kurz vor dem angekündigten Start des Upgrade zu beginnen). Noch wichtiger ist, dass keine Check-Ins mehr gestattet sind, nachdem der Code Upgrade Service mit seinen Berechnungen begonnen hat, bis mindestens zu dem Zeitpunkt, zu dem der Branch gemerged wurde. Wir (und das würde ich auch so empfehlen) stoppen Check-Ins sogar bis auch der manuelle Merge der Konflikte etc. vollzogen ist. Entwicklungen, die auf der bisherigen Version in den alten VMs fertiggestellt werden, kommen so lange in Shelvesets und werden später eingecheckt – wobei dann auch entstandene Inkompatibilitäten auffallen.

Projekte

Solltest du mit versionierten Entwicklungsprojekten (Solutions in Visual Studio) agieren – diese befinden sich ja dann in /Trunk/Main/Projects/ – solltest du entweder beim Merge vorsichtig sein oder auf den Merge von $/YourAX7Project/Releases/7.0.1186.16043_CTP8_2015-12-18T14.33.06/Projects gänzlich verzichten. Das Problem ist, dass der Merge die vorhandenen Projekte einfach löscht. Wir lassen deshalb die generierten Projekte weg und mergen entsprechend zunächst nur den Ordner Metadata. Solltest du den gleichen Weg gehen wollen, ist es sehr wichtig, die Datei ax7.version im Main-Verzeichnis ebenfalls manuell herüberzumergen!