Słów kilka o liczbie środowisk developerskich w projektach Dynamics 365 / Power Apps

Tytułem wstępu…

Rozpoczynając wdrożenie nowego systemu opartego o platformę Dynamics 365 Customer Engagement lub Microsoft Power Apps wielu z nas zastanawia się pewnie, ilu organizacji będziemy potrzebować do prac projektowych. Przez wiele lat powszechnie stosowanym podejściem było posiadanie środowisk developerskiego, testowego i produkcyjnego. Czasem w projektach pojawiały się organizacje pre-produkcyjne (zwane również „stagingowymi”) oraz przeznaczone do szkoleń użytkowników. Proces przenoszenia dostosowań oraz kodu między środowiskami był w tym układzie prosty. Efekty pracy konsultantów i programistów przenoszone były z instancji developerskiej na testową, a następnie na kolejne środowiska. Po akceptacji klienta rozwiązanie trafiało na produkcję.  

W miarę wzrostu świadomości organizacji, pojawienia się powszechnie dostępnych narzędzi typu Git, oraz systemów umożliwiających automatyzacje procesu budowania oraz wdrażania aplikacji (DevOps), opisany powyżej proces przestał być jednak wystarczający. Pojawiły się pytania o to, w jaki sposób śledzić zmiany w dostarczanym rozwiązaniu i jak dostarczać poprawki po wdrożeniu produkcyjnym, nie blokując jednocześnie procesu tworzenia nowych funkcjonalności. Pewnym przełomem było udostępnienie przez Microsoft narzędzi umożliwiających „rozpakowanie” rozwiązania do plików XML i ponowne złożenie go w całość ze wspomnianych plików. Jednak dopiero upowszechnienie i szeroka adopcja procesu Gitflow w projektach Power Apps/Dynamics/Dataverse (niepotrzebne skreślić) nadała sens ich wykorzystywaniu w formie innej niż do tworzenia przechowywanej w repozytorium kodu zapasowej kopi rozwiązania.

Wdrożenia systemów Dynamics 365 i Power Apps są bardzo różne. Począwszy od kilkudziesięciudniowych przedsięwzięć, nad którymi pracują zazwyczaj maksymalnie 2 osoby („ktoś” od gadania z klientem i „ktoś techniczny”), a skończywszy na wieloletnich projektach, w których zaangażowane są ogromne zespoły konsultantów i developerów. W tym drugim przypadku tematem, który trzeba zazwyczaj zaadresować przed rozpoczęciem prac implementacyjnych jest konfiguracja środowisk developerskich, która umożliwi równoczesną pracę wielu osób bez wzajemnych interferencji, wchodzenia sobie w drogę i negatywnego wpływu na wydajność innych członków zespołu. Poniżej znajdziecie opis dwóch najczęściej spotykanych przeze mnie w ciągu ostatnich lat konfiguracji i procesów wytwarzania oprogramowania w projektach wdrożeń systemów Dynamics 365 CE lub aplikacji zbudowanych o platformę Microsoft Power Apps.    

„Jeden, by wszystkimi rządzić”

Posiadają pojedyncze środowisko, developerskie nasze możliwości są mocno ograniczone. Proces dostosowywania aplikacji odbywa się w tym przypadku na wspólnej instancji systemu. Zmiany w aplikacji są następnie eksportowane do repozytorium kodu, a później ponownie „składane” do postaci solucji Dataverse oraz importowane na środowiska docelowe. Eksportując rozwiązanie do repozytorium kodu konsultanci lub developerzy muszą uważać na to, by faktycznie wyeksportować tylko ten fragment rozwiązania, którego są autorami, a nie efekty pracy swoich kolegów.  

Zalety posiadania pojedynczego, współdzielonego środowiska developerskiego:

  • Niższy całkowity kosz posiadania i utrzymywania środowiska.
  • Niewielkie prawdopodobieństwo konfliktów podczas procesu scalania kodu z różnych gałęzi
  • Potencjalnie krótszy czas dostarczania kolejnych funkcjonalności (w środowisku developerskim od razu powstaje ostateczna paczka dostosowań, która będzie wdrażana na kolejne środowiska).
  • Brak konieczności posiadania zaawansowanej wiedzy na temat wewnętrznej struktury solucji oraz tworzących ją plików XML przez członków zespołu projektowego.
  • Zdecydowanie mniejsze ryzyko błędów przy pakowaniu rozwiązania lub zbudowania nieprawidłowego rozwiązania, którego nie jesteśmy w stanie zaimportować na środowisko docelowe (sytuacja związana najczęściej z nieprawidłowymi plikami XML, które powstały w wyniku automatycznego scalania kodu z kilku gałęzi).

Wady:

  • Problemy z równoległą pracą nad współdzielonymi komponentami rozwiązania (biblioteki rozszerzeń .NET, zasoby sieciowe), które stanowią całościowe jednostki wdrożeniowe. Przykładowo – w momencie, kiedy 2 developerów pracuje jednocześnie lokalnie nad tą samą biblioteką JavaScript i wgrywa ją na środowisko developerskie za pomocą rozszerzeń do Visual Studio – może dojść do sytuacji, w której nie są oni w stanie przetestować swojego kodu na środowisku developerskim, ponieważ nadpisują sobie wzajemnie przekazywane do systemu zmiany.
  • Częste „straty” historii zmian w repozytorium kodu. W przypadku, w którym developerzy pracują nad dostosowaniami równolegle i eksportują dokonane zmiany do repozytorium kodu, bardzo łatwo może dojść do sytuacji, w której z rozpędu utworzą commit fragment dostosowań, którego nie są autorami. W podejściu tym repozytorium kodu pełni bardziej rolę systemu do przechowywania kopii zapasowej solucji niż faktycznej platformy do śledzenia jej zmian.

Może tak każdy osobno?

Posiadając wiele środowisk developerskich, możemy pokusić się o bardziej zaawansowaną konfigurację. Tym razem każdy developer lub konsultant może pracować na swoim własnym środowisku, nie wchodząc w drogę innym członkom zespołu. Ma to szczególne znaczenie w przypadku pracy nad współdzielonymi komponentami (skomplikowana formatka, biblioteka JavaScript, rozszerzenie systemu zaimplementowane jako plugin .NET itp.).

Zalety posiadania wielu środowisk developerskich:

  • Każdy developer lub konsultant dysponuje w pełni wyizolowanym środowiskiem pracy. Może z niego korzystać i wykonywać na nim dowolne operacje (w tym „psucie” 😉) bez konieczności oglądania się na innych.
  • Pełna historia zmian w repozytorium kodu. Developer nie ma możliwości wrzucenia do Gita zmian, których faktycznie samodzielnie nie „popełnił”.

Wady:

  • Częste problemy ze scalaniem fragmentów rozwiązania pochodzących z osobnych gałęzi kodu. Bądźmy szczerzy – dostępne na rynku narzędzia nie najlepiej radzą sobie ze scalaniem i rozwiązywanie konfliktów w plikach XML, które to używane są do przechowywania informacji o dostosowaniach aplikacji Dataverse. Ich ręczne poprawianie może być niestety drogą przez mękę z uwagi na brak sensownej dokumentacji oraz brak oficjalnego wsparcia producenta systemu w tym obszarze.
  • Brak możliwości weryfikacji, w jaki sposób nasze zmiany wpływają na całość systemu oraz modyfikacje innych osób do momentu, w którym nie zostaną one wdrożone na współdzielone środowisko.
  • Wymagana wiedza na temat zewnętrznej struktury plików w momencie wystąpienia problemów ze scalaniem dostosowań. Z uwagi na brak dokumentacji jest to wiedza, którą możemy pozyskać jedynie „w boju”. Jeżeli więc masz w projekcie trzech „świeżaków” to prawdopodobnie masz problem.
  • Potencjalne problemy z budowaniem rozwiązania Dataverse oraz wdrażaniem go na środowisko docelowe, wynikające z nieprawidłowego automatycznego scalania plików solucji.
  • Dodatkowa praca potrzebna na utrzymywania indywidualnych środowisk developerskich.
  • Oczywiście, również dodatkowy koszt związany z ich posiadaniem oraz utrzymywaniem w chmurze

Plusy dodatnie i plusy ujemne

Który z powyższych sposobów pracy jest lepszy i wpływa pozytywnie na wydajność zespołu? Jak to zwykle bywa w IT – nie istnieje jednoznaczna odpowiedź na to pytanie. W punktach, z którymi mogliście się zapoznać powyżej, starałem się zebrać podstawowe wady i zalety obu rozwiązań. To, które lepiej sprawdzi się w Waszym projekcie, musicie ocenić samodzielnie.

Co po wdrożeniu?

Po wdrożeniu produkcyjnym systemu sytuacja staje się zazwyczaj jeszcze ciekawsza. Biznes oczekuje zazwyczaj w takim przypadku prowadzenia prac rozwojowych (polegających zazwyczaj na tworzeniu nowych oraz rozbudowie lub modyfikacji istniejących funkcjonalności) oraz jednoczesnego naprawiania błędów w istniejącym rozwiązaniu. Oczywiście w mniej skomplikowanych projektach proces ten daje się „ogarnąć” jedną z opisanych powyżej konfiguracji. W przypadku bardziej zaawansowanych rozwiązań konieczne jest niestety posiadanie dodatkowych środowisk developerskich i testowych, tak by prace nowymi „ficzerami” oraz „bug-fixami” mogły być prowadzone w wyizolowanych środowiskach. To już jednak temat na nowy, osobny, artykuł.

Total Views: 196 ,
Be the first to comment

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *