Przy okazji rozdzielenia platformy od aplikacji (opisanej w poprzednim poście) wypada się pochylić bardziej nad tym, jak przygotowywać nowe Rozwiązania (Solutions) w trakcie wdrożenia Dynamics 365 (i po nim). Skoro od teraz każdy moduł funkcjonalny będzie w osobnym Rozwiązaniu, to i my, partnerzy wdrażający, powinniśmy trochę bardziej serio zacząć traktować solucje i poprawki. Wiadomo, że w realnym życiu nikt poza ISV nie używa Rozwiązań Zarządzanych ;), ale wypada zacząć używać Rozwiązań i Poprawek w celu lepszego panowania nad cyklem życia naszych dostosowań w CRM’ie (Dynamics 365 for Customer Engagement, taaaa).

* standardowo, będę używał słów „rozwiązania” i „solucje” zamiennie, mimo że „solucja” to wg Słownika Języka Polskiego i CD Action coś zupełnie innego 🙂

 

Wersjonowanie Rozwiązań vs wersjonowanie Poprawek

Jak wiadomo, każde rozwiązanie przygotowywane przez nas podczas wdrażania Dynamics 365 ma numer wersji. Pierwszy numer podczas tworzenia Rozwiązania nadajemy my sami, więc wydaje się, że możemy wybrać dowolną nazwę. A jednak nie! Odkąd Microsoft wprowadził do CRM 2016 i Dynamics 365 „Aktywa” (Assets), czyli poszczególne, bardzo małe komponenty konkretnych encji, to numerowanie Rozwiązań jest wymuszane przez platformę do określonego formatu X.Y.Z.W, gdzie:

• X – numer głównej wersji Rozwiązania (major)
• Y – numer aktualizacji Rozwiązania (minor)
• Z – numer Poprawki (build)
• W – numer rewizji Poprawki (revision)

Dlatego też próba wpisania takiego numerku wersji:

…spowoduje z automatu poprawienie przez system numeru wersji na taki:

 

Każda Poprawka (Patch) do naszego Rozwiązania będzie miała później automatycznie nadawany numer będący inkrementacją trzeciego numerka (Z w numerze X.Y.Z.W).

 

Poprawki (Patches) w Dynamics 365 – co to takiego?

Poprawki (albo „patche”), jak sama nazwa wskazuje, służą do wgrywania poprawek do istniejących rozwiązań. Poprawki to nic innego jak zestaw konkretnych Aktywów dodanych do istniejącego Rozwiązania. Na przykład:

chcemy szybko zmienić konkretny widok, albo dodać nowy wykres, albo zmienić pola na formatce w docelowym środowisku – wtedy nie tworzymy nowego rozwiązania zawierającego tylko widok, wykres i formularz, ale tworzymy patch do istniejącego rozwiązania, który zawiera tylko te elementy, które chcemy zmienić.

Patche mogą być aplikowane zarówno do Rozwiązań Zarządzanych, jak i Niezarządzanych (ufff!), a więc szybko powinny się stać obowiązkowym i ulubionym elementem każdego dobrego wdrożenia Dynamics 365. Patch zawsze powstaje poprzez utworzenie go (sklonowanie) z istniejącego rozwiązania – nie można stworzyć patch’a ot tak bez istniejącego Rozwiązania. Każdy patch jest stworzony dla konkretnego Rozwiązania i nie może być używany poza kontekstem tego Rozwiązania. Oczywiście, co za tym idzie, nie można wgrać Poprawki na środowisko, w którym nie ma oryginalnego Rozwiązania, którego ta Poprawka dotyczy!

Dodatkowo, podczas próby importu Poprawki, CRM (tfu, Dynamics 365) zawsze sprawdzi, czy numer głównej wersji Rozwiązania (X) i numer aktualizacji Rozwiązania (Y) w Poprawce są takie same, jak numery Rozwiązania istniejącego już na środowisku docelowym. Nie da się więc patch’em zaktualizować numeru wersji, czy aktualizacji. Patch to patch. Zawsze trzeci numerek w numerze wersji.

 

Poprawka, a aktualizacje Rozwiązania (minor version)

Jak łatwo się domyślić, w prawdziwych wdrożeniach będziemy mieli wiele patch’y do istniejących rozwiązań. Dlatego Microsoft przemyślał sprawę i pozwala na tworzenie Aktualizacji Rozwiązania (numerek Y w X.Y.Z.W), które automatycznie uwzględniają wszystkie dotychczasowe Poprawki! Nie ma więc potrzeby pamiętania o wszystkich Poprawkach dodawanych do rozwiązania, bo każda nowa wersja Rozwiązania będzie zawierać wszystkie zmiany, które dodaliśmy wcześniej patch’ami.

 

Jak to zadziała w realnym życiu, przy wielu zainstalowanych rozwiązaniach?

Załóżmy trochę trudniejszy scenariusz niż kolejne patch’e na jednym rozwiązaniu (co oczywiście jest proste i skutkuje konkretnymi, spodziewanymi zmianami wprowadzanymi w patch’ach). Mianowicie, wprowadzamy Poprawkę do dostosowania (np. encji), które jest też komponentem innego Rozwiązania. Mamy więc taką sytuację na środowisku docelowym:

• PodstawoweRozwiazanie, 2017.0.0.0., zawiera encję „Encja” i pole „Pole Testowe” o długości 50 znaków
• InneRozwiazanie, 1983.0.0.0., zainstalowane później, też zawiera encję „Encja„, ale długość pola „Pole Testowe” jest zmieniona na 100 znaków

Przygotowujemy poprawkę PodstawoweRozwiazanie, 2017.0.1.0. (pierwszy patch) z długością pola „Pole Testowe” zmienioną na 70 znaków. Co stanie się, kiedy zainstalujemy naszą Poprawkę? 

Otóż odpowiedź różni się w zależności od tego, czy pracujemy na Rozwiązaniach Zarządzanych i Niezarządzanych:

W przypadku Rozwiązań Zarządzanych… nic się nie stanie dopóki w systemie mamy zainstalowane InneRozwiazanie. Długość pola „Pole Testowe” nadal będzie mieć 100 znaków! A to dlatego, że nasza Poprawka chce zmienić i może zmienić tylko nasze PodstawoweRozwiazanie, ale nie może zmienić drugiego rozwiązania (bo nie została dla niego stworzona)! Dlatego, w powyższym scenariuszu nasz patch zostanie „uwzględniony” dopiero, kiedy odinstalujemy InneRozwiazanie (1983.0.0.0.). Wtedy z automatu PodstawoweRozwiazanie będzie mieć numerek 2017.0.1.0. (pierwszy patch), a więc będzie zawierać wszystkie zmiany wprowadzone przez nasz patch.

W przypadku Rozwiązań Niezarządzanych oczywiście nasz patch nadpisze „Pole Testowe” tak, jak się tego spodziewamy. UWAGA! Wbrew temu, co pisze Microsoft na MSDN’ie tutaj w akapicie „Another patching example”: https://msdn.microsoft.com/en-us/library/mt593040.aspx

 

Tworzenie poprawek i aktualizacji krok po kroku

Poniżej opisuję kilka kroków, które przeprowadzą Was dokładnie przez proces utworzenia pierwszego patch’a (Z) i pierwszej aktualizacji (Y) w Dynamics 365:

1. Tworzymy Rozwiązanie i dodajemy do niego wszystkie aktywa, które ma zawierać:

2. Tworzymy pierwszą Poprawkę do Rozwiązania poprzez „Klonuj do poprawki”. Dynamics 365 automatycznie zmieni numer wersji, inkrementując trzecią cyfrę:

3. Dodajemy zmiany w Poprawce. Po dodaniu wszystkich aktywów, w systemie mamy jedno Rozwiązanie (2017.0.0.0) i jedną Poprawkę (2017.0.1.0):

4. Kiedy mamy już dużo poprawek, możemy zdecydować się na utworzenie aktualizacji Rozwiązania. Taka aktualizacja automatycznie będzie zawierać wszystkie wcześniej utworzone Poprawki, a same Poprawki znikną z systemu!

 

Aktualizacja zmieni też numer build’u, inkrementując drugą cyfrę (Y, minor) w numerze wersji Rozwiązania.

5. Podczas importu aktualizacji Rozwiązania system wykryje, że ma do czynienia z aktualizacją i pokaże nam dodatkową opcję zastosowania aktualizacji do istniejącego Rozwiązania.

 

Usuwanie poprawek

Podobnie jak w powyżej opisanym przypadku pracy z kilkoma Rozwiązaniami, usuwanie patch’y różni się w zależności od tego, czy pracujemy na Rozwiązaniach Zarządzanych, czy nie.

I tak, w przypadku Rozwiązania Zarządzanego wystarczy ze środowiska docelowego odinstalować to Rozwiązanie, a wszystkie poprawki (patch’e) zostaną usunięte automatycznie.

Natomiast, w przypadku Rozwiązania Niezarządzanego usuwanie Poprawek odbywa się „pojedynczo”, a samo Rozwiązanie nie da się usunąć, jeśli najpierw nie usuniemy jego Poprawek. System poinformuje nas o tym, jeśli zapomnimy o tej kolejności miłym błędem:

 

Podsumowanie

Mechanizm Poprawek i Aktualizacji stanowczo wspiera pracę podczas wdrażania Microsoft Dynamics 365 for Customer Engagement poprzez dobry i przemyślany, a przede wszystkim działający, mechanizm wersjonowania. Dzięki mechanizmom klonowania Poprawek i aktualizacji system sam dba o zależności między naszymi poprawkami a istniejącymi Rozwiązaniami, a dzięki temu, że wszystkie Poprawki automatycznie stają się częścią nowych aktualizacji, nie musimy się już martwić, że zapomnimy podczas importu nowej wersji Rozwiązań o jakimś komponencie.

To jedna z tych funkcji, które powinniście zacząć używać jak najszybciej!