Pięć najlepszych praktyk ALM (Application Lifecycle Management) w Power Platform

Na wstępie od razu uwaga - to jest post o najlepszych praktykach ALM na wysokim poziomie, a nie tutorial jaką zmienną wstawić w kroku Power Platform Unpack Solution 

Kiedy ostatnio u sporego Klienta znów zobaczyłem jak „ktoś” (Power Platformowiec, ale taki udawany – od Canvas i uczenia jak wystawić listę Sharepoint na zewnątrz organizacji poprzez Power Pages, serio) przenosi aplikacje canvas pojedynczo na środowisko produkcyjne, a dodatkowo Klient był ewidentnie zaskoczony, że istnieje coś takiego, jak Rozwiązania (będę używał wymienne z angielskim Solutions) pomyślałem, że napiszę niedługo ten post. Świat low-code to nie jest świat klikania appek bez rozumienia jak nimi zarządzać i co to są Rozwiązania i kontrola wersji!

Mam nadzieję, że poniższe kroki będą stanowiły dla Klientów ściągawkę i pozwolą odróżnić szarlatanów od canvasów od low-code i fusion developerów z doświadczeniem i z prawdziwego zdarzenia.

Zasada 1 – Nawet proste aplikacje low-code powinny być pakowane w Solutions

Każda, nawet najprostsza aplikacja i 1 flow powinny być zamknięte w Rozwiązaniu (Solution) dla dobra aplikacji i Klienta. Koniec.
Jak nie wiesz jak zrobić solucję, albo co to jest, to nie oszukuj Klientów, że znasz się na Power Platform.

Microsoft robi wszystko, żeby umożliwić pakowanie (prawie) wszystkich komponentów budowanych w Power Platform w Solutions, dlatego nie ma już tłumaczenia, że coś trzeba przenieść poza Rozwiązaniem. A już tłumaczenie, że tak jest szybciej, jest kompromitacją.

Co może i powinno być częścią Rozwiązania?

W skrócie – wszystko, co budujesz w make.powerapps.com może i powinno być częścią rozwiązania (w poniższym obrazku zamień „Entity” na „Table”):

Zasada 2 – Nie używaj domyślnego środowiska (Default Environment), ani domyślnego wydawcy (Default Publisher)

Każdy tenant ma coś takiego, jak domyślne środowisko o nazwie [Nazwa tenanta (Default)]. To jest środowisko widziane przez każdego użytkownika i nie powinno być używane do budowania jakiejkolwiek aplikacji poza osobistym testowaniem funkcji Power Platform. Warto pamiętać, że każdy użytkownik (również każdy nowy) automatycznie dostaję rolę Maker w tym środowisku.

W ogóle zaleca się zmianę nazwy tego środowiska na coś bardziej właściwego w stylu „Środowisko dla każdego”. Więcej na ten temat wraz z instrukcją można poczytać tutaj: https://learn.microsoft.com/en-us/power-platform/admin/environments-overview#the-default-environment

Dodatkowo, pilnuj też, żeby Twoje Solutions miały właściwego Wydawcę (Publisher) i nie używały domyślnego dla danego środowiska!

Prefix w nazwie Twoich tabel i pól w stylu „crc1e_” naprawdę pokazuje, że nie masz pojęcia czym jest Power Platform.

Zasada 3 – Zmień podejście z bazowania na środowiskach na bazowanie na kontroli źródeł i wersji (to niefortunnie brzmi po polsku, chodzi o source control – Git, TFVC, Gitlab, svn, cokolwiek)

Traktuj każdy swój projekt Power Platform’owy i low-code’owy jak każdy inny projekt programistyczny! Przestań bazować na tym, że na środowisku DEV (albo jeszcze lepiej… na swoim 30-dniowym trialu) masz wszystko, więc to jest „źródło prawdy” w Twoim projekcie!

Źródłem prawdy i źródłem źródeł (kodu i komponentów specyficznych dla Power Platform) powinien być system do kontroli wersji i paczki w nim przechowywane.

Pięć lat temu można było bazować na środowiskach i rozwiązaniach Dynamics 365 (poza kodem, który wtedy też już był w VSTS, albo TFS), bo nie było tak dużo narzędzi udostępnianych przez Microsoft, które pozwalają na zarządzanie cyklem życia aplikacji w Power Platform. Ale to się zmieniło! Teraz, budując Pipeline w Azure DevOps masz do wyboru wszystkie komponenty wymagane do poprawnego zarządzania kodem i elementami Dynamics 365 i Power Platform (kod, Solutions, XML’e, świadomość tabel, pola itd). A jak nie widzisz gotowego kroku, to zawsze możesz użyć YAML.

Zasada 4 – Automatyzuj cały deployment i miej pomysł jak to zrobić zanim zaczniesz robić cokolwiek w Power Platform

Nie czekaj z automatyzacją ALM, bo skończy się jak zwykle – jak już powstaną pierwsze komponenty, to zaczną krążyć same jako pojedyncze elementy, albo w najlepszym wypadku pojedyncze Rozwiązania. Zanim zaczniesz projekt, zbuduj sobie (przynajmniej koncepcyjnie, żeby być gotowym jak powstaną pierwsze aplikacje) pipeline w Azure DevOps i ustal poszczególne środowiska i kroki.

Nie pozwalaj poszczególnym developerom w jednym projekcie zarządzać cyklem życia aplikacji na różne sposoby!

Oczywiście, książkowy ideał to „jednorazowe” (disposable) i wyizolowane środowiska developerskie, w sensie takie, które wykorzystywane są do zbudowania konkretnej funkcjonalności i później „usuwane”. A aktualna baza kodu i komponentów powinna być zawsze brana od nowa z platformy source control. To ideał i pewnie trudno ekonomicznie osiągalny, ale jedno przynajmniej można osiągnąć – środowiska developerskie izolowane dla każdego developera, które zawsze dają gwarancję, że baza kodu i komponentów są aktualne. Nie używajcie środowisk developerskich współdzielonych przez kilku programistów, u których baza do pracy różni się od bazowego kodu w platformie source control.

Zasada 5 – Zacznij używać Center of Excellence Starter Kit

Jeśli robisz duże rzeczy w Power Platform i nie używasz jeszcze Power Platform Center of Excellence Starter Kit, to zacznij go używać (https://github.com/microsoft/coe-starter-kit/releases/tag/CoEStarterKit-February2023). Nie tylko po to, żeby wiedzieć co dzieje się na Twoich środowiskach dzięki jednemu z gotowych dashboardów w Power BI, albo co powoduje zmiana w polisie DLP, ale przede wszystkim dlatego, że CoE Starter Kit ma mnóstwo narzędzi, które wspierają zarządzanie cyklem życia aplikacji (Application Lifecycle Management).

Jeśli nie widziałaś wartości w CoE Starter Kit do tej pory, to ALM Accelerator for Power Platform powinien Cię przekonać. ALM Accelerator for Power Platform zawiera prostą aplikację Canvas, która łączy się do Azure Pipelines i środowiska Power Apps i pozwala z jednego miejsca kontrolować cykl życia aplikacji Power Platform, np. pozwala na przekazywanie zmian między środowiskami jednym kliknięciem, zarządzanie pull requestami, czy usuwanie istniejących rozwiązań na środowiskach developerskich, żeby zastąpić je aktualnymi rozwiązaniami z systemu kontroli wersji.

Więcej o ALM Accelerator for Power Platform można przeczytać tutaj: https://powerapps.microsoft.com/en-us/blog/introducing-the-alm-accelerator-for-power-platform/

Zasada bez numeru, bo miało być 5 – Wg Microsoft zawsze używaj tylko Rozwiązań Zarządzanych (Managed Solutions), kiedy przenosisz zmiany na środowiska inne niż developerskie

Taaaaaaaaaki żarcik. Za każdym razem, jak ktoś z MS kolejny raz powie, że w prawdziwym życiu i w realnym projekcie zawsze powinno się używać tylko solucji zarządzanych, to pokażcie mu tego mema, na moją odpowiedzialność: