Podczas wdrażania systemu klasy ERP Microsoft Dynamics 365 F&O czeka nas wiele wyzwań. Jednym z nich jest konieczność dostosowania się do nowego podejścia w temacie zadań administracyjnych związanych z Zarządzaniem Cyklem Życia Aplikacji (ALM – Application Lifecycle Management).
Wiele zmieniło się, względem poprzednich wersji systemu, w kwestii koniecznych do wykonania zadań administracyjnych. Przykładem zmiany metodyki w najnowszej wersji popularnego AX-a jest chociażby inny sposób przenoszenia kodu między środowiskami. Ma to bezpośredni wpływ na zwiększenie nakładów pracy wymaganej na zadania administracyjne.
W serii trzech artykułów przedstawię najważniejsze zagadnienia techniczne związane z automatyzacją w Dynamics 365 F&O. Liczę jednak, że „AX-owi wyjadacze” zainspirują się do poszukania alternatywnego, bardziej optymalnego sposobu konfiguracji automatyzacji.
W pierwszym artykule z serii znajdziecie opis podstawowych komponentów automatyzacji oraz zapoznacie się ich rolą i sposóbem działania w ramach systemu Dynamics 365 F&O.
Automatyzacja zadań
W systemie Dynamics 365 F&O wiele zadań administracyjnych zostało niejako wymuszonych na pracownikach IT. Oczywiście, poprzednie wersje systemu także wymagały odpowiedniej obsługi. Jednak była tam relatywnie większa swoboda w kwestii metody realizacji tych zadań.
Osobiście odbieram tę zmianę i wymuszenie dobrych praktyk w systemie Dynamics 365 F&O bardzo pozytywnie. Nowe metodyki dają większe poczucie komfortu i stabilności przy obsłudze systemu. Przepływ pracy nad zadaniami (typu przenoszenie kodu między środowiskami czy backup bazy danych) zdecydowanie obliguje administratora do zastosowania dobrych praktyk podczas ich realizacji.
W celu wyjaśnienia potrzeby automatyzacji najpierw omówię z czym musi mierzyć się administrator systemu Dynamics 365 F&O. Poniższe diagramy obrazują dwa scenariusze, których dosłownie nie da się uniknąć podczas wdrażania i potem utrzymania Dynamics 365 F&O.
Przenoszenie kodu między środowiskami
Przepływ pracy z kodem wygląda następująco:
- Programista tworzy kod źródłowy na maszynie developerskiej.
- Kod źródłowy jest wrzucany do repozytorium kodu (w tym przypadku repozytorium w Azure DevOps).
- Na maszynie buildowej kod jest kompilowany i tworzone są pliki wynikowe (pliki .dll).
- Kod wynikowy jest przenoszony z maszyny buildowej na środowisko Tier 2+.
- Ze środowiska Tier 2+ kod wynikowy jest transferowany na środowisko produkcyjne.
Przygotowanie backupu bazy danych
Przepływ pracy podczas przygotowania backupu bazy danych wygląda następująco:
- Uruchamiane jest tworzenie kopii bazy danych ze środowiska produkcyjnego na środowisko Tier 2+.
- Z poziomu środowiska Tier 2+ backup bazy danych jest transferowany do LCS Asset Library w formie pliku .bacpac.
- Ostatni krok to pobranie pliku bazy danych z Asset Library i przygotowanie go do użycia na maszynach deweloperskich. Podczas tej operacji baza danych zostanie przekonwertowana z formatu .bacpac na .bak.
Do tej operacji można wykorzystać skrypt PowerShell popularnej biblioteki wytworzonej pod Dynamics 365 F&O o nazwie „d365fo.tools”, a w niej funkcję, „Import-D365Bacpac”.
Bez automatyzacji wszystkie powyższe zadania muszą być inicjowane i nadzorowane przez administratora manualnie. Najczęściej w porze znaczniej odbiegającej od standardowych godzin pracy biznesowej.
Na szczęście dynamiczny rozwój systemów z rodziny Microsoft Dynamics 365, a przede wszystkim osadzenie infrastruktury najnowszego AX-a w chmurze Azure, otwiera wiele nowych i ciekawych możliwości. Korzystając z dobrodziejstw usług chmurowych, jesteśmy w stanie zautomatyzować wiele czasochłonnych prac.
Zadania, które najłatwiej jest przełączyć w tryb automatyzacji to właśnie te, dotyczące prac stricte administracyjnych.
Doświadczenie naszego Centrum Kompetencyjnego pokazuje, że wdrożenie automatyzacji w procesach:
- buildowania,
- releasowania,
- backupowania bazy danych,
przynosi wymierne korzyści w sferze:
- kosztów,
- zaoszczędzonego czasu,
- i – co nie mniej ważne – zaoszczędzonych nerwów 🙂
Komponenty automatyzacji
W systemie automatyzacji dla najnowszego AX-a warto poznać następujące cztery główne elementy.
Środowisko wykonawcze
Jest to wirtualna maszyna, w obrębie której realizowane są faktyczne prace dotyczące automatyzacji. W przypadku D365 F&O jest to najczęściej maszyna w warstwie Tier 1, czyli maszyna developerska lub buildowa. Alternatywą jest środowisko wykonawcze hostowane w chmurze Azure, wykorzystujące Microsoft Hosted Agenta. Istotną cechą tego środowiska wykonawczego jest mniejsze przystosowanie do Dynamics 365 F&O. Na takim środowisku brak wielu komponentów „klasycznego” środowiska programistycznego, np. SQL Serwera, przez co nie da się wykonać synchronizacji bazy danych.
Azure Pipeline
Ograniczając definicję jedynie do kontekstu automatyzacji w D365 F&O, jest to usługa Azure DevOps, w której określamy zadania w procesie automatyzacji. Tutaj wybierzemy i sparametryzujemy dokładne kroki, które z wykorzystaniem Agenta i skryptów wykonawczych zostaną wykonane na wybranym środowisku.
Azure Pipeline Agent
Jest to program, działający jako usługa uruchomiona w ramach środowiska wykonawczego. Dla D365 F&O preinstalowany na dysku developerskiej lub buildowej maszyny wirtualnej. W razie potrzeby można też go doinstalować. Może również występować w formie specyficznego typu Azure Pipeline Agenta, osadzonego w ramach środowiska wykonawczego chmury Azure dostarczanego przez Microsoft, dedykowanego pod szybkie buildy.
Odpowiada za pobranie kroku z definicji Pipeline’a w Azure Pipeline i zlecenie wykonania go na środowisku wykonawczym. Do wykonania poszczególnych kroków Agent korzysta ze skryptów wykonawczych.
Skrypty wykonawcze
Do wykonania poszczególnych kroków Pipeline’a Agent potrzebuje instrukcji. Takimi instrukcjami są dla niego skrypty wykonawcze. Pliki te przechowują kod, z użyciem którego realizowany jest krok Pipeline’a. Najczęściej skrypty wykonawcze występują w formie plików PowerShell. Często są przechowywane i modyfikowane trwale na środowisku wykonawczym.
Należy dodać, że nie jest to jedyny sposób pracy z tymi skryptami. Zdecydowanie korzystniejszym podejściem (w znacznej większości przypadków) jest ich przechowywanie w repozytorium kodu. Przy odpowiedniej konfiguracji (swoją drogą banalnie prostej) Agent Pipeline pobierze do realizacji skrypty wykonawcze, a ich aktualna treść będzie przetwarzana jedynie w kontekście bieżącego uruchomienia Pipeline’a. Pozwala to na wygodne i elastyczne modyfikowanie plików pomiędzy poszczególnymi uruchomieniami Pipeline’a.
Kolejną istotną cechą jest fakt, że skrypty wykonawcze mogą być definiowane w wielu formach. Daje to ogromne możliwości w kwestii tego, co i w jaki sposób można zautomatyzować. Ograniczeniem są jedynie możliwości środowiska wykonawczego, możliwości wybranego języka skryptowego, chociaż tak naprawdę… ograniczeniem jest tylko nasza wyobraźnia ?
Interakcje między komponentami
Powyższe komponenty współpracują ze sobą w procesie automatyzacji. Poniższy diagram obrazuje sposób interakcji pomiędzy poszczególnymi komponentami.
W ramach usługi Azure Pipeline zdefiniowane są poszczególne kroki Pipeline’a. Na środowisku wykonawczym, w obrębie określonej puli agentów, znajdują się Agenci Azure Pipeline. Pula Agentów Azure Pipeline określa z jakich agentów i z jakich środowisk wykonawczych może używać dany Pipeline. Pula w umowny sposób grupuje Agentów i jest zdefiniowana w ramach usługi Azure Pipeline.
Pojedynczy agent komunikuje się z usługą Azure Pipeline i pobiera kolejno pipeline’owe taski. Następnie, pojedynczy task jest wykonywany na środowisku wykonawczym z użyciem jego zasobów i z wykorzystaniem skryptów wykonawczych, aż do pobrania oraz wykonania ostatniego taska z definicji Azure Pipeline.
Uwaga! Komunikacja w tym systemie jest inicjowana jedynie od strony Agenta Azure Pipeline. Otwiera to ogrom możliwości w kwestii konfiguracji środowiska wykonawczego. Moim zdaniem Microsoft zastosował tutaj wzorzec komunikacji, który jest po prostu architektonicznym majstersztykiem ? Jako że treść tego artykułu jest tylko wstępem, to rozwinę ten temat w kolejnych artykułach z serii.
Zakończenie
Artykuł przedstawia podstawowe zagadnienia automatyzacji w Azure dla Dynamics 365 F&O. Jego forma jest nieco skondensowana – pomija niektóre mniej znaczące, lecz wciąż istotne szczegóły. Wyszedłem z założenia, że najważniejsze jest zrozumienie wysokopoziomowej logiki. Pozostałe definicje łatwo znaleźć, doczytać i zrozumieć z dostępnych materiałach dokumentacji.
Mam jednak nadzieję, że artykuł pozwoli pojąć podstawy automatyzacji systemie D365 F&O, jej ideę i schemat działania. Jest to kluczowe do implementacji z pełnym zrozumieniem.
W następnym artykule opiszę porównanie metod przechowywania środowiska wykonawczego.
Zachęcam do podzielenia się opinią na temat treści tego artykułu oraz dalszego śledzenia bloga.
Źródła wartościowych materiałów
- Artiste.info – blog, którego autorem jest Adrià Ariste Santacreu. Bardzo dużo materiału o automatyzacji zadań administracyjnych w D365 F&O, ale nie tylko. Autor dzieli się również wiedzą i pomysłami dot. wykorzystania narzędzi i usług około Dynamicsa, które z nim współgrają i mogą usprawnić działanie systemu. Treści pisane są w formie „tutoriali”, dzięki temu można uczyć się poprzez praktykę. Szczerze polecam.
- Biblioteka PowerShell wspomagająca pracę z systemem Dynamics 365 F&O – kod biblioteki jest open source, a pomysł jej stworzenia należy do Mötza Jensena, ale w tej chwili rozwija ją już kilka osób. Bardzo przydatne narzędzie w codziennej pracy z zadaniami administracyjnymi pod Dynamics 365 F&O.
- MsDyn365FO – blog autorstwa Paula Heisterkampa w tematyce Dynamics 365 F&O. Chociaż treści dotyczących samej konfiguracji automatyzacji nie ma tam wiele, to autor dzieli się naprawdę ciekawymi pomysłami na rozwiązanie pospolitych problemów np. automatyzacji odpowiedniego przygotowania środowiska po przeprowadzeniu backupu bazy danych z PROD. Wiele interesujących i przydatnych treści.
- Dokumentacja Microsoft dot. automatyzacji z wykorzystaniem Azure Pipelines.
- Dokumentacja Microsoft dot. automatycznych buildów wykorzystujących Microsoft Hosted Agentów.
***
Jeśli interesują Cię inne artykuły z obszaru Dynamics 365, zachęcamy do lektury: Integracja Dynamics 365 Supply Chain Management z przewoźnikami oraz Komponenty niestandardowe w Power Apps.
Zostaw komentarz