W poprzednich artykułach pokazałem, jak zautomatyzować proces budowania i wdrażania aplikacji w Azure DevOps dla Dynamics 365 Finance & Operations. Powstał kompletny pipeline, który wykonuje kompilację, analizę kodu oraz przygotowuje pakiety wdrożeniowe.
Czy to oznacza, że każde wdrożenie jest już bezpieczne?
Niestety nie.
W praktyce wiele projektów nadal boryka się z problemami, które pojawiają się dopiero po wdrożeniu:
- kod kompiluje się poprawnie, ale zawiera regresję,
- programista przypadkowo zmienił logikę biznesową,
- nowe funkcjonalności pogorszyły wydajność,
- wdrożenie przeszło pomyślnie, mimo że część testów zakończyła się niepowodzeniem.
Właśnie dlatego nowoczesny DevOps nie kończy się na CI/CD. Kolejnym etapem jest wprowadzenie Quality Gates, czyli zestawu automatycznych kryteriów jakości, które muszą zostać spełnione, zanim zmiany trafią do kolejnego środowiska.
Czym właściwie są Quality Gates?
Najprościej można powiedzieć, że Quality Gates to automatyczne „bramki bezpieczeństwa”.
Pipeline nie pyta człowieka: Czy na pewno chcesz wdrożyć?
On sam sprawdza, czy wdrożenie jest wystarczająco dobre.
Jeżeli którykolwiek z warunków nie zostanie spełniony – proces zostaje zatrzymany.
Przykładowe bramki:
- kod skompilował się bez błędów,
- liczba ostrzeżeń Best Practice nie przekracza ustalonego limitu,
- AppChecker nie wykrył błędów krytycznych,
- wszystkie testy jednostkowe zakończyły się sukcesem,
- Code Coverage wynosi co najmniej 80%,
- raport CAR nie zawiera nowych problemów,
- wdrożenie zostało zatwierdzone przez odpowiednią osobę.
Programista nie musi pamiętać o każdym z tych elementów.
Pilnuje tego Azure DevOps.
Dlaczego jest to tak ważne w D365 F&O?
Dynamics 365 Finance & Operations to system ERP obsługujący najważniejsze procesy biznesowe przedsiębiorstwa.
Błąd w kodzie może oznaczać:
- błędne księgowanie dokumentów,
- niepoprawne naliczanie podatków,
- zatrzymanie procesu sprzedaży,
- problemy magazynowe,
- błędne wyliczenia produkcji.
Dlatego organizacje wdrażające D365 coraz częściej odchodzą od ręcznej kontroli jakości na rzecz pełnej automatyzacji.
Microsoft również rekomenduje budowanie procesu ALM opartego na automatycznych kontrolach jakości oraz na odpowiedzialności zespołu za cały cykl życia aplikacji.
Jak może wyglądać przykładowa ścieżka weryfikacji?
Wyobraźmy sobie prosty scenariusz. Programista wysyła Pull Request. Automatycznie uruchamia się pipeline.
Kolejne etapy wyglądają następująco:
- Pobranie kodu z repozytorium.
- Kompilacja.
- Analiza Best Practice.
- AppChecker.
- Testy jednostkowe.
- Generowanie raportów.
- Publikacja wyników.
- Weryfikacja Quality Gate.
Dopiero wtedy zaistnieje możliwość wdrożenia.
Jeżeli którykolwiek etap zakończy się błędem – pipeline kończy pracę. Nikt nie wdroży kodu przypadkowo.
Automatyczne testy – największy sprzymierzeniec DevOps
Wiele zespołów inwestuje ogromne środki w budowę pipeline’ów, a jednocześnie praktycznie nie ma testów. To trochę tak, jakby kupić nowoczesny samochód wyposażony w system autonomicznej jazdy, ale zdemontować hamulce.
Pipeline odpowiada za automatyzację. Testy odpowiadają za jakość. Dopiero połączenie obu elementów daje realne korzyści.
W przypadku D365 F&O możemy wykorzystywać między innymi:
- SysTest,
- testy integracyjne,
- testy regresyjne,
- RSAT,
- testy wydajnościowe.
Im większa automatyzacja testów, tym mniejsze ryzyko kosztownych błędów produkcyjnych.
Approval Gates – kiedy człowiek nadal jest potrzebny
Nie wszystko warto automatyzować.
Przed wdrożeniem na produkcję często wymagane jest zatwierdzenie przez:
- kierownika projektu,
- właściciela biznesowego,
- architekta,
- administratora systemu.
Azure DevOps umożliwia skonfigurowanie tzw. Approval Gates. Pipeline zatrzymuje się przed produkcją i oczekuje na akceptację. Dzięki temu zachowujemy pełną kontrolę nad procesem, jednocześnie eliminując ręczne wykonywanie wszystkich wcześniejszych kroków.
Dane zamiast przeczucia
Jedną z największych zalet DevOps jest możliwość mierzenia procesu.
Zamiast mówić: „Wydaje mi się, że projekt działa dobrze”, możemy analizować konkretne wskaźniki.
Najczęściej monitorowane są:
- czas budowania,
- liczba nieudanych wdrożeń,
- liczba rollbacków,
- czas usunięcia awarii,
- częstotliwość wdrożeń,
- skuteczność testów.
Takie dane pozwalają szybko zauważyć pogarszającą się jakość projektu i reagować, zanim problem odczuje użytkownik końcowy.
Najczęstsze błędy
Podczas wdrażania DevOps spotykam kilka powtarzających się problemów.
- Pierwszy to brak testów.
- Drugi to ignorowanie ostrzeżeń Best Practice.
- Trzeci to ręczne omijanie pipeline’ów „bo przecież trzeba szybko wdrożyć”.
Każde takie odstępstwo sprawia, że automatyzacja przestaje być wiarygodna.
Pipeline powinien być jedyną drogą prowadzącą do wdrożenia.
Microsoft Dynamics 365 CRM
Twórz spersonalizowane doświadczenia dla swoich klientów dzięki zaawansowanym funkcjom Dynamics 365 Customer Engagement
Oferta M365Podsumowanie
Automatyzacja budowania aplikacji to dopiero początek drogi. Prawdziwy DevOps zaczyna się wtedy, gdy pipeline sam potrafi odpowiedzieć na pytanie:
Czy ten kod naprawdę nadaje się do wdrożenia?
Quality Gates sprawiają, że decyzje przestają być oparte na intuicji, a zaczynają wynikać z mierzalnych kryteriów jakości. Dzięki temu zespół zyskuje większą przewidywalność, mniej awarii oraz szybsze wdrożenia, a klient otrzymuje stabilniejszy system.
W kolejnym artykule pokażę, jak zbudować kompletny Dashboard DevOps dla Dynamics 365 F&O, który w jednym miejscu prezentuje stan pipeline’ów, wyniki testów, jakość kodu oraz najważniejsze wskaźniki projektu.
Zostaw komentarz