Backend

Czy SFDX Unlocked Packages nadaje się do twojego projektu?

2 marca 2020 Stefan Abramiuk

W styczniu 2019 roku Salesforce udostępnił funkcjonalność nazwaną Unlocked Packages. Jest to kolejna funkcjonalność rozszerzająca możliwości SFDX CLI (Command Line Interface), a jej celem ułatwienie przenoszenia metadanych pomiędzy środowiskami. Czy zrewolucjonizuje ona sposób wdrażania aplikacji w środowiskach Salesforce? Zobaczmy jakie mamy opcje i wyciągnijmy wnioski.

Stefan Abramiuk. Technical Architect w PolSource. Pracuje w branży IT od 8 lat. Poza Salesforce zajmował się programowaniem w takich językach jak ANSI C, C++ oraz Java. Dołączył do warszawskiego zespołu PolSource 3 lata temu. Zaczął jako Senior Software Developer. Od dwóch lat w roli Technical Architect’a. Posiada 5 certyfikatów Salesforce i jest na ścieżce do Certified Technical Architect. Prywatnie interesuje się astrofizyką oraz muzyką.

Nauczyliśmy się już, że Salesforce jest samodzielnie żyjącym organizmem, przez co znacznie różni się od środowisk opartych na Javie czy Node JS. Przez brak dostępu bezpośrednio do systemu operacyjnego, dostęp ograniczony jedynie poprzez interface (API), swoją strukturą przypomina bardziej SaaS (Software as Service) niż typowy PaaS.

Ograniczenia API sprawiają, że operacje takie jak deployment często stają się dużo bardziej skomplikowane. Tu niestety nikt nie obieca, że da się zrobić rollback w poniedziałek po deploymencie w piątek. Metadata API rządzi się swoimi prawami, których nie da się obejść a dostępne narzędzia mają zbyt proste funkcjonalności, aby w pełni nam pomagać. Oczywiście, są zapaleńcy, którzy piszą własne aplikacje klienta Metadata API i czasami, takie narzędzia pojawiają się na GitHubie, jednak bez utrzymania szybko stają się zbyt stare. To też uniemożliwia używanie ich komercyjnie. A więc, czy jedyną drogą ma być utrapienie? Może zacznijmy od odrobiny teorii.

Salesforce daje nam kilka modeli rozwoju aplikacji, które opierają się o ten sam ALM (Application Lifecycle Management).

Układam je w taką oto strukturę:

1. Org Based

a) Change Sets
b) Managed/Unmanaged Packages

2. Org-Code hybrid

3. Source Code based

a) SFDX/Metadata API
b) Unlocked Packages

Każdy z nich ma swoje zastosowanie zależne od stopnia złożoności naszego wdrożenia. Oczywiście, żaden z tych modeli nie wyklucza użycia systemu kontroli wersji (VCS).

Spis treści

Org Based

Change Sets

Przykładowa struktura przenoszenia funkcjonalności poprzez change sety

Dla tych, którzy nie wiedzą jeszcze co to są change sety, w skrócie mogę opisać to, jako paczkę tworzoną z komponentów na środowisku (sandboxie) przez programistów/administratorów. Model ten jak najbardziej nadaje się do małych wdrożeń, gdyż nie wymaga dodatkowych narzędzi oraz jest prosty w obsłudze.

Managed/Unmanaged Packages

Instalowanie paczki zawsze odbywa się z środowiska developerskiego

W zasadzie powinienem rozdzielić te dwa typy, gdyż zazwyczaj mają inny cel. Jednak z punktu widzenia dostarczania oprogramowania oba procesy wyglądają identycznie. Podobnie jak przy change setach, paczkę tworzymy na środowisku developerskim, aby potem można zainstalować na innym środowisku. Wymaga to niestety oddzielnego środowiska developerskiego, które jest naszym Source of Truth. Kod zawarty w Managed Package jest zamknięty do wglądu i edycji. Można wystawić API na potencjalne rozszerzenia, więc zyskujemy pełną kontrolę nad tym co będzie się działo po zainstalowaniu. Unmanaged Packages znowu zostawia otwarty do edycji kod, który może zostać zmieniony przez programistę po zainstalowaniu.

Org-Code Hybrid

Metadata API świetnie nadaje się do przenoszenia metadanych pomiędzy środowiskami

Może nie wiecie, ale ten model jest obecnie najszerzej używany. Developer ma Sandbox, na którym tworzy funkcjonalność, by potem wyciągnąć komponenty przy pomocy Metadata API. Takie komponenty w postaci plików takich jak XML przenoszone są na kolejny org. Oczywiście pewnie wszyscy używają teraz GITa jako repozytorium tych komponentów, ale model ten jest dalej trudno zarządzalny przy dużej liczbie programistów lub przy wielu zespołach dostarczających równolegle oprogramowanie na to samo środowisko produkcyjne.

Source Code based

Teraz odwracamy wszystko, co było opisane wyżej. Stawiamy nasze repozytorium jako źródło prawdy (source of truth).

SFDX/Metadata API

Przykład modelu procesu implementacji oraz deploymentu przy użyciu SFDX oraz narzędzia CI

Od kiedy powstał SFDX życie wielu programistów stało się dużo prostsze. Ogromną elastyczność dostaliśmy wraz z pojawieniem się Scratch Orgów. Programiści mogą prawie całkowicie niezależnie dostarczać funkcjonalności i dostarczać jedynie metadane. Zmiana organizacji struktury katalogów i plików umożliwia w końcu organizację tych metadanych. Pomaga to w znacznym stopniu przy zarządzaniu paczkami, które mamy dostarczać.

Źródło grafiki: salesforce.com

Pewnie widzieliście już ten lub podobny schemat. Widać na nim jedną wadę tego rozwiązania. Dostarczanie oprogramowania na konkretne środowisko dalej odbywa się podobnie jak w modelu hybrydowym. Co prawda bierzemy paczkę z naszego repozytorium, ale samo załadowanie jej na inne środowisko nie zawsze jest gładkie.

Znowu możemy spotkać się z wielokolorowym procesem, problemem z zależnościami między komponentami i przede wszystkim zależnością od docelowego środowiska. No i gdzie nasz słynny poniedziałkowy rollback?

Unlocked Packages

Paczka zostaje utworzona na środowisku Deb Hub jednak powstaje z metadanych trzymanych na przykład w CVS (GIT)

W końcu dotarliśmy do sedna, a zarazem najnowszej funkcjonalności znanej też pod nazwą Second Generation Packages (2GP). Czym ona różni się od wszystkiego co opisałem do tej pory? Jest to kolejna hybryda, ale tym razem między SFDX/Metadata API oraz Unmanaged Packages. W tym modelu funkcjonalność tworzymy na scratch orgach, a jej kod dostarczamy do repozytorium jak w poprzednim punkcie. Różnica jest natomiast w tym, co dzieje się dalej.

Na podstawie metadanych zebranych w plikach możemy utworzyć paczkę z nazwą i numerem wersji. Paczkę taką możemy zainstalować na dowolnym środowisku bądź dowolnym scratch orgu. Model doskonale nadaje się do wdrożeń wewnątrz pojedynczej organizacji, raczej nie nadaje się, aby sprzedawać swoją aplikację klientom, gdyż kod zostaje otwarty do wglądu i edycji jak w przypadku Unmanaged Packages.

Unlocked Packages. Co dzieje się pod maską?

Kilka komend na start

W przypadku Managed czy Unmanaged Packages komponenty do paczki dodajemy przez UI. Jeżeli ktoś miał okazję już to robić, wie jak bardzo mozolna jest to czynność, oraz ile jest tam możliwości popełnienia błędu. W przypadku Unlocked Packages wskazujemy katalog bądź katalogi, które chcemy uwzględnić i cała sprawa jest zamknięta.

Więc mamy nasz “kod” i co potem?

Potem tworzymy paczkę nadając jej nazwę i wskazując źródło:

sfdx force:package:create -n HelloWrold -d "<mój opis>" -r force-app -t Unlocked -v DevHubOrg

Nasz plik sfdx-project.json wygląda wtedy mniej więcej tak:

{
   "packageDirectories": [
      {
         "path": "force-app",
         "default": true,
         "package": "HelloWrold",
         "versionName": "ver 0.1",
         "versionNumber": "0.1.0.NEXT"
      }
   ],
   "namespace": "",
   "sfdcLoginUrl": "https://login.salesforce.com",
   "sourceApiVersion": "43.0",
   "packageAliases": {
      "HelloWrold": "0Hoxxx"
   }
}

Kolejny krok to stworzenie wersji naszej paczki. Możemy nadać hasło/klucz, które zabezpieczy przed nieautoryzowanym użyciem.

sfdx force:package:version:create -p HelloWrold -d force-app -k test1234 --wait 10 -v DevHubOrg

Jeżeli wszystko jest ok, otrzymamy numer wersji naszej paczki i od tej pory możemy ją instalować na naszych sandboxach oraz scratch orgach. W zależności od modelu przyjętego w projekcie, możemy tworzyć wiele wersji składających się razem na release i ostatecznie oznaczyć jedną dopuszczoną do zainstalowania na produkcji.

Operację taką wykonuje się komendą promote w następujący sposób:

sfdx force:package:version:promote -p 04t...

Co powinno się znaleźć w paczce?

Jak napisałem wcześniej, paczkę należy przygotować i świetnie się do tego nadaje elastyczna struktura folderów SFDX. Możemy stworzyć oddzielny folder dla każdej paczki wewnątrz folderu force-app, lub zamiast folderu force-app, lecz w takim przypadku należy pamiętać aby zaktualizować plik sfdx-project.json. Dzięki temu podczas tworzenia paczki wskazuję tylko jeden folder np. force-app/paczkaB.

Oczywiście można zechcieć umieścić wszystko w jednej paczce i w pewnych przypadkach nie jest to złe. Ale jeżeli mamy kilka zespół dostarczających rozwiązanie na to samo środowisko produkcyjne trzeba pomyśleć o strukturze paczek.

Warto stworzyć paczkę bazową – taką część wspólną pozostałych rozwiązań, oraz co najmniej jedną paczkę dla każdego z zespołów. Paczka bazowa nie powinna być zależna od żadnej innej, natomiast paczka konkretnego zespołu lub projektu może (ale nie musi) być zależna od paczki bazowej.

Jeżeli ułożymy to odpowiednio w folderach stworzenie paczki jest banalnie proste:

Kiedy tworzyć paczkę?

Paczkę tworzymy, aby dostarczyć oprogramowanie na inne środowiska. To znaczy tyle, że musi ona zawierać jakieś skończone i przetestowanie elementy tworzące spójną całość. Raczej nie często zdarza się sytuacja, gdzie chcemy dostarczyć pojedynczy task na UAT (User Acceptance Test) zaraz po jego zakończeniu. Dlatego moja propozycja przedstawiona na diagramie poniżej opiera się o dwa sposoby deploymentów.

1. Metadata API – dla DEV i QA, Scratch Org

2. Unlocked Packages – dla wszystkich pozostałych środowisk

Programiści pracują jak zawsze na scratch orgach lub sandboxach deweloperskich. Zespół QA pracuje na sandboxie QA. Gdy sprint jest zamykany, dostarczone funkcjonalności zbierane są w jednym miejscu w repozytorium (może to być branch lub tag), aby stworzyć z nich wersję paczki. Zwróćcie uwagę, że dzięki temu nie musimy mieć branchy w repozytorium dla środowisk takich jak UAT, czy PreProd. Mamy 100% pewność, że kod, który instalujemy na SIT trafia potem na Produkcję.

Gdzie jest haczyk?

Chyba każdy od razu zacznie szukać ograniczeń licencji czy podobnych problemów rozwiązań cloud-based. Całe szczęście rozwiązanie jest całkowicie darmowe. Co do ograniczeń, to można ich jedynie szukać przy wspieranych typach metadanych. Wszystkie różnice pokazuje jasno Metadata Coverage Report. Jedna rzecz, która od razu rzuca się w oczy to brak wsparcia dla Communities. Musimy jednak pamiętać, że jest to dość nowe rozwiązanie i jeszcze pewna droga je czeka, zanim będzie w pełni funkcjonalne.

Podsumowując

Mam nadzieję, że zachęciłam was choć odrobinę do zwrócenia uwagi na Unlocked Packages. Z mojego doświadczenia widzę, że rodzi się coraz większa potrzeba u klientów do modularyzacji rozwiązań, przeprowadzania szybkich deploymentów, a także opcji rollbacku. Czy Unlcoked Packages sprosta tym potrzebom? Sądzę, że już niedługo tak.

Warto o tym pisać, testować i zadawać pytania. Salesforce dość aktywnie śledzi ruch na swoich forach, a więc widząc zainteresowanie oraz feedback może zwiększyć nacisk na tą funkcjonalność. Zachęcam także do przejrzenia trailhead w kontekście Unlocked Packages i spróbowania samemu.

Źródła: