Mój poprzedni artykuł wprowadził Was w świat Pipeline, praktyk DevOps oraz korzyści z wykorzystywania DevOps Pipelines dla D365 F&O.
W drugiej części serii przedstawię praktyczne informacje dotyczących użycia automatyzacji zadań za pomocą Pipeline DevOps (będę używał polskiego słowa „potok” zamiast angielskiego „pipeline”) na przykładzie systemu ERP D365 F&O wdrażanego przez moje Centrum Kompetencyjne. Skupię się m.in. na sprawdzaniu wytwarzanego kodu przez naszych programistów za pomocą automatu potoku DevOps. W artykule opiszę sposób wdrożenia i używania środowiska obsługującego ciągłą weryfikację wytwarzanego kodu.
Automatyzacja potoku
W ramach automatyzacji potoku znajduje się: automatyczny przegląd kodu, weryfikacja BP, AppChecker oraz CarReport, weryfikacja synchronizacji, weryfikacja kompilacji i wdrożenia raportów oraz inne.
W ramach prac wdrożeniowych wprowadzających produkt bardzo często wdrażamy automat potoku umożliwiający weryfikację kodu wytwarzanego przez naszych programistów.
Podstawowe wymagania umożliwiające stworzenie takiego automatu zależą od doświadczenia:
- jeśli masz już doświadczenie związane z potokami DevOps, oznacza to, że znasz już elementy konfiguracji potoku w DevOps.
- jeśli nie masz doświadczenia, powinieneś zacząć od oficjalnej dokumentacji Microsoft dotyczącej potoków DevOps.
Potoki kompilacji i weryfikacji kodu
Potok kompilacji i weryfikacji kodu w DevOps to zbiór ustawień, które z jednej strony kontrolują proces kompilacji kodu, a z drugiej proces weryfikacji kompilowanego kodu. Ustawienia obejmują takie elementy jak m.in.:
- gałąź kontroli wersji, która powinna zostać zbudowana,
- niestandardowe skrypty programu PowerShell i wyzwalacze (zaplanowane kompilacje/weryfikacje po wystąpieniu zmiany).
Wykorzystujemy standardowe potoki DevOps Azure.
Istniejące potoki kompilacji w usłudze DevOps można znaleźć, przechodząc do sekcji Pipelines -> Pipelines w lewym menu konfiguracyjnym.
Domyślny widok pokazuje potoki z ostatnimi kompilacjami
Tworzenie nowego potoku kompilacji/weryfikacji DevOps
Jeśli chcesz utworzyć nowy potok kompilacji/weryfikacji DevOps, dobrym rozwiązaniem jest sklonowanie istniejącego potoku zamiast tworzenie nowego od podstaw. Oczywiście możesz też edytować istniejące potoki, a także zapisać istniejący potok jako szablon.
Istnieje także możliwość utworzenia nowego potoku od postaw. Jeśli chcesz to zrobić, musisz wywołać przycisk „New pipeline” (Nowy potok) w prawym górnym rogu DevOps:
Podczas tworzenia potoku należy dokonać ustawienia kilku elementów, które będą potrzebne w procesie kompilacji/weryfikacji.
Agent pool (Pula agentów potoku)
Pierwszym elementem do ustawienia jest pula agentów potoku. W głównym widoku tworzenia potoku kompilacji/weryfikacji możesz ustawić pulę agentów potoku. Standardowo nie musisz tego zmieniać. Podczas wdrażania środowiska kompilacji z usługi Lifecycle Services możesz wybrać/ustawić pulę agentów, które następnie będą dostępne w usłudze DevOps.
Możesz kontrolować, która gałąź zostanie zbudowana, za pomocą tych dwóch ustawień w opcjach Get sources (Pobierz źródła) oraz Build the solution (Kompiluj rozwiązanie):
W zmiennych kompilacji/weryfikacji możesz nadzorować różnego rodzaju ustawienia, które DevOps udostępnia dla kompilacji/weryfikacji D365 F&O. Jeśli chcesz przeprowadzić szczegółową weryfikację wytworzonego kodu, warto nie pomijać standardowych opcji DevOps.
Możesz użyć Tiggers (wyzwalaczy), aby kontrolować, kiedy kompilacja/weryfikacja powinna się rozpocząć. Ciągła integracja, opisana w poprzednim artykule, oznacza, że kompilacja/weryfikacja powinna być wyzwalana po każdej zmianie kodu.
Ponieważ kompilacja/weryfikacja kodu w niektórych przypadkach może zająć więcej czasu, warto rozważyć planowanie kompilacji i kompilować kod w określonych porach dnia np. co noc, w południe:
Punktem kulminacyjnym całego procesu kompilacji/weryfikacji kodu D365 F&O jest dodanie własnych skryptów PowerShell umożliwiających wykorzystanie mechanizmów weryfikacji i oceny wytworzonego kodu z uwzględnieniem takich mechanizmów jak weryfikacja BP, Appchecker, CarReport i inne elementy.
Poniżej przedstawiam fragment jednego ze skryptów:
/p:BuildTasksDirectory="$(Pipeline.Workspace)\NuGets\Microsoft.Dynamics.AX.Platform.CompilerPackage\DevAlm"
/p:MetadataDirectory="$(Build.SourcesDirectory)\Metadata"
/p:FrameworkDirectory="$(Pipeline.Workspace)\NuGets\Microsoft.Dynamics.AX.Platform.CompilerPackage"
/p:ReferenceFolder="$(Pipeline.Workspace)\NuGets\Microsoft.Dynamics.AX.Platform.DevALM.BuildXpp\ref\net40;$(Pipeline.Workspace)\NuGets\Microsoft.Dynamics.AX.Application1.DevALM.BuildXpp\ref\net40;$(Pipeline.Workspace)\NuGets\Microsoft.Dynamics.AX.Application2.DevALM.BuildXpp\ref\net40;$(Pipeline.Workspace)\NuGets\Microsoft.Dynamics.AX.ApplicationSuite.DevALM.BuildXpp\ref\net40;$(Build.SourcesDirectory)\Metadata;$(Build.BinariesDirectory)"
/p:ReferencePath="$(Pipeline.Workspace)\NuGets\Microsoft.Dynamics.AX.Platform.CompilerPackage" /p:OutputDirectory="$(Build.BinariesDirectory)"
/p:CompilerMetadata="$(Build.BinariesDirectory)"
Na zakończenie
W artykule skupiłem się na aspektach praktycznych dotyczących automatyzacji zadań za pomocą Pipeline DevOps na przykładzie systemu ERP D365 F&O wdrażanego przez moje Centrum Kompetencyjne. Skupiłem się na automatyzacji kompilacji i wydań wytwarzanego przez nas oprogramowania. Mam nadzieję, że wpis będzie dla Was pomocny 😊
Zostaw komentarz