Wyślij zapytanie Dołącz do Sii

Bazując na swoim doświadczeniu, zespół zajmujący się Microsoft Dynamics 365 Finance and Operations przygotował kilkanaście modyfikacji (modeli) do aplikacji, które w głównej mierze dotyczą dostosowań do wymogów polskiego prawa. Niestety nasze prawo nie słynie ze stabilności, co pociąga za sobą konieczność ciągłych poprawek i prac nad narzędziami.

Po rozdystrybuowaniu modeli wśród klientów stanęliśmy przed wyzwaniem, jakim było dokładna identyfikacja wersji naszych produktów, a co za tym idzie – możliwość szybkiego udzielenia pomocy. Oczywiście najprostszym rozwiązaniem jest ręczne zarządzanie numerami modeli. Jednakże modele koegzystują w środowisku, są łączone (buildowane), a następnie testowane w różnych konfiguracjach, więc numer ostatniej poprawki w pojedynczej modyfikacji nie był wystarczający.

Potrzebna była cecha, która z jednej strony pozwoli na sprawdzenie wersji pojedynczej funkcjonalności, a z drugiej pomoże sprawdzić, czy ta wersja jest „kompatybilna” z innymi. Z artykułu dowiecie się, jak ją znalazłem.

Problem

W CC Dynamics 365 pojawił się pomysł na aktualizację wersji podczas build. Nie znalazłem gotowego narzędzia, które przed wykonaniem build zaktualizowałoby wersję w deskryptorze zapisanym w xml. Numer wersji miał posiadać numer changeseta ostatniej zmiany. Deskryptor dla D365 zapisany w formacie xml według zamierzeń ma zawierać informacje o wersji jak niżej:

Informacje o wersji w deskryptorze
Ryc. 1 Informacje o wersji w deskryptorze

Koncepcja

Ten przypadek jest wykonywany podczas build z użyciem Microsoft-Hosted Agent w Azure DevOps Pipelines. Aktualizacja wersji zostanie wykonana jako krok w pipeline przez skrypt napisany w PowerShell z wykorzystaniem Rest API. Repozytorium jest w TFVC.

Działanie skryptu

Działanie skryptu
Ryc. 2 Działanie skryptu

Autoryzacja

Aby zweryfikować numer changeseta ostatniej zmiany dla konkretnego modelu i zrobić checkin zmian dla pliku deskryptora, używam poleceń kontroli wersji Team Foundation z poziomu PowerShell, autoryzując się przez token OAuth. Korzystając z DevOps pipelines, należy pamiętać o wyrażeniu zgody na dostęp do OAuth token przez zmienną System.AccessToken. Dzięki takiemu rozwiązaniu autoryzacja przebiegnie bez wyświetlania okna logowania oraz podawania nazwy użytkownika i hasła.

Autoryzacja
Ryc. 3 Autoryzacja

Weryfikacja autora zmiany

Sprawdzenie autora zmiany odbywa się przez Rest API, a autoryzacja z wykorzystaniem PAT. Osobisty token dostępu powinien mieć pełne uprawnienia do odczytywania, zapisywania i zarządzania kodem oraz repozytorium.

Zadania

Pierwszym krokiem jest wygenerowanie listy modeli zawierających plik deskryptora, który ma zostać zaktualizowany. W tym przypadku sprawdziło się wylistowanie katalogów przez Get-ChildItem, wskazując ścieżkę Metadata w repozytorium.

$Solutions = @(Get-childitem Metadata)

Pętla Foreach uruchamia się dla każdego wylistowanego modelu osobno i zawiera zadania wymienione w dalszej części artykułu.

Foreach ($Solution in $Solutions) {
…
}

Ostatnią zmianę można zweryfikować komendą tf history, która po dodaniu parametru /stopafter:1 wskaże informację o ostatniej zmianie w formie tabeli. Z pomocą PowerShell należy zapisać jedynie numer changeseta do zmiennej (w tym przypadku $SolutionVersion) (po więcej informacji odsyłam do artykułu).  

Kolejnym krokiem jest weryfikacja autora zmiany, aby wykluczyć zmiany wprowadzone przez użytkownika „Build Service”, który dokonuje aktualizacji deskryptora podczas uruchomienia zautomatyzowanego pipeline. Używając Rest API i polecenia GET, zostanie zwrócona informacja o autorze changseta konkretnego pliku w repozytorium. (po więcej informacji odsyłam do artykułu).

Po wskazaniu ścieżki deskryptora należy uruchomić pętlę Foreach oraz instrukcję if wykluczającą wyżej wspominanego użytkownika „Build Service” i wprowadzić zmiany w pliku xml, używając wcześniej utworzonej zmiennej z numerem changeseta. VersionBuild, VersionMajor i VersionMinor zostają zaktualizowane z użyciem Get-Date.

foreach ($DescriptorFile in $DescriptorPath) {
if ($result.author.displayName -ne "ProjectName Build Service (OrganizationName)") {

$Day = (Get-Date).day # VersionBuild
$Month = (Get-date).month # VersionMajor
$Year = (Get-Date).year # VersionMinor 

$xml = New-Object XML
$xml.Load($file)
$VersionBuild = $xml.SelectSingleNode("//VersionBuild")
$VersionBuild.InnerText = $Day
$VersionMajor = $xml.SelectSingleNode("//VersionMajor")
$VersionMajor.InnerText = $Year
$VersionMinor = $xml.SelectSingleNode("//VersionMinor")
$VersionMinor.InnerText = $Month
$VersionRevision = $xml.SelectSingleNode("//VersionRevision")
$VersionRevision.InnerText = $SolutionVersion
$xml.Save($file)
}

W instrukcji else pozostają obecne wartości ostatniego changeseta, natomiast wartości zawierające datę zostają zaktualizowane.

Na końcu instrukcji if oraz else, należy użyć komendy tf checkin do zatwierdzenia zmian w deskryptorze.

tf checkin $DescriptorFile /comment:"Updated model $Solution version to $Day.$Month.$Year.$SolutionVersion in $SolutionDescriptor"

Po zatwierdzeniu zmian wersja zostaje zaktualizowana. W przypadku zmiany wykonanej przez Build Service aktualizacja numeru changseta jest pomijana.

Repozytorium DevOps
Ryc. 4 Repozytorium DevOps
Plik deskryptora
Ryc. 5 Plik deskryptora
Update model parameters Visual Studio
Ryc. 6 Update model parameters Visual Studio

Używając opisanego skryptu, należy pamiętać o wyłączeniu innych kroków związanych z wersjonowaniem w pipeline.

Wersjonowanie
Ryc. 7 Wersjonowanie

Po wdrożeniu paczki na środowisko D365 możesz sprawdzić wersję modelu, korzystając z platformy.

Sprawdzenie wersji modelu
Ryc. 8 Sprawdzenie wersji modelu

Zakończenie

Artykuł przedstawia moje rozwiązanie przedstawionego we wstępie problemu z dokładną identyfikacją wersji naszych produktów. Poza odświeżaniem tokenu PAT skrypt nie wymagał ode mnie jakichkolwiek działań. Skrypt, jako krok w pipeline, uruchamiany jest cyklicznie przed każdym build. Wszelkie zamierzenia zostały spełnione.

***

Jeśli interesuje Cię tematyka Dynamics 365, zajrzyj koniecznie do innych artykułów naszych autorów.

5/5 ( głosy: 27)
Ocena:
5/5 ( głosy: 27)
Autor
Avatar
Mateusz Witkowski

Administrator Systemowy w CC Dynamics 365. Interesuje się chmurą oraz automatyzacją procesów z wykorzystaniem PowerShell i Azure DevOps

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Może Cię również zainteresować

Pokaż więcej artykułów

Bądź na bieżąco

Zasubskrybuj naszego bloga i otrzymuj informacje o najnowszych wpisach.

Otrzymaj ofertę

Jeśli chcesz dowiedzieć się więcej na temat oferty Sii, skontaktuj się z nami.

Wyślij zapytanie Wyślij zapytanie

Natalia Competency Center Director

Get an offer

Dołącz do Sii

Znajdź idealną pracę – zapoznaj się z naszą ofertą rekrutacyjną i aplikuj.

Aplikuj Aplikuj

Paweł Process Owner

Join Sii

ZATWIERDŹ

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?