Salesforce Release Train: praktyczne podejście do zarządzania wydaniami
Opublikowany: 2022-03-11Zarządzanie wydaniami, jak sama nazwa wskazuje, to proces zarządzania, planowania, planowania i kontrolowania tworzenia oprogramowania na różnych etapach i środowiskach; w tym testowanie i wdrażanie wersji oprogramowania (Humble & Farley, 2011).
Jest to dość duży temat sam w sobie i można go z czasem udoskonalić, próbując różnych iteracji z zespołami programistycznymi i dopasowując potrzeby biznesowe lub wersje funkcji. Postaramy się omówić branżowe praktyki zarządzania metadanymi, budowania CI i zarządzania piaskownicą w celu zarządzania pociągiem wydań organizacji .
Ale czym jest pociąg do wydania?
Pociąg wydania to przyrostowa i przewidywalna technika dostarczania funkcji. Wymaga to od dewelopera skonfigurowania formalnego procesu w celu podjęcia wszelkich zmian wprowadzonych w środowisku programistycznym i wdrożenia ich w środowisku produkcyjnym.
Pociąg wydania można ogólnie podzielić na trzy segmenty:
- Zarządzanie metadanymi
- Budowanie ciągłej integracji
- Zarządzanie piaskownicą
Zarządzanie metadanymi
Metadane to dane, które dostarczają informacji o innych danych. Salesforce zapewnia bogaty i wydajny model metadanych za pośrednictwem interfejsu Metadata API . Metadane aplikacji opisują i obejmują zestaw metod, które zapewniają programistyczny dostęp do kodu źródłowego i konfiguracji Twojej organizacji.
Metadata API to najlepszy sposób na zarządzanie dostosowaniami w Salesforce. Obsługuje metody create , read , update i delete . Możesz użyć Change Sets, Force.com IDE i Ant Migration Tool do migracji metadanych z jednej organizacji do drugiej, ponieważ wszystkie one zapewniają migracje za pośrednictwem interfejsu API.
Każde narzędzie ma swoje zalety, a przy wyborze jednego z nich należy wziąć pod uwagę kilka rzeczy:
Tabela 1: Porównanie narzędzi do migracji metadanych
| Zmień zestawy | Force.com IDE | Narzędzie do migracji mrówek |
|---|---|---|
| Zestawy zmian to sposób na wdrażanie komponentów za pośrednictwem standardowego interfejsu użytkownika Salesforce. | Force.com IDE (Eclipse) jest przeznaczone głównie do programowania Apex, ale może być używane do celów wdrażania. | Ant Migration to potężne narzędzie wiersza poleceń, przeznaczone do migracji zmian/metadanych między środowiskami. |
| Zwykle używany do migracji niewielkiej liczby komponentów. | Deweloperzy zwykle używają IDE do migracji zmian do środowiska testowego lub tymczasowego. | Ant Migration służy do migracji dużych ładunków i wymaga zaawansowanej znajomości interfejsu Salesforce Metadata API. |
| Połączenie między organizacjami musi być nawiązywane ręcznie, więc nie nadaje się do zautomatyzowanych wdrożeń. | Można go użyć do wdrożenia w dowolnej organizacji, ale wymaga wykonania pewnych czynności ręcznych, które są podatne na błędy. | Automatyczne wdrożenia można bardzo łatwo zaplanować. |
| Przeznaczony do użytku przez administratorów. | Ukierunkowany na programistów Salesforce, ponieważ rozwijanie kodu jest jego głównym zastosowaniem. | Nastawiony na inżynierów DevOps. |
| Dodawanie zależności jest bardzo łatwe i przyjazne dla użytkownika. | Dodawanie zależności jest dość łatwe, ponieważ zapewnia interfejs użytkownika typu „wskaż i kliknij”. | Wdrożenie zwykle kończy się niepowodzeniem z powodu brakujących zależności. |
| Nie pozwala na destrukcyjne zmiany. | Pozwala na destrukcyjne zestawy zmian, ale proces jest dość żmudny. | Umożliwia destrukcyjne zestawy zmian. |
Metadata API świetnie spełnia swoje zadanie podczas opracowywania i migracji zmian na platformie Force.com. Ale jest mały haczyk – nie wszystkie metadane Salesforce są obsługiwane przez Metadata API. Oficjalna dokumentacja zawiera listę nieobsługiwanych komponentów.
Jeśli Twoja organizacja wprowadza zmiany, które nie są obsługiwane przez interfejs API metadanych, musisz ręcznie zreplikować te zmiany w organizacji docelowej. Najlepszym sposobem śledzenia tych zmian jest arkusz kalkulacyjny. Jeśli musisz uciekać się do tego podejścia, zawsze zaleca się, aby jedna osoba wprowadzała te zmiany i je śledziła.
Byłaby to dobra ogólna lista kolumn, których można użyć do śledzenia tych zmian w arkuszu kalkulacyjnym:
- Nazwa składnika
- Rodzaj komponentu
- Zmiana właściciela
- Opis funkcjonalności
- Mapowanie możliwości
- Zależność z innymi komponentami
- Imię i nazwisko recenzowanego/recenzenta
- URL
- Nazwa/identyfikator organizacji
- Inne komentarze
Kontrola wersji i ciągła integracja
Migracja zmian do środowiska produkcyjnego powinna przebiegać płynnie, ponieważ jest to tylko powtórka wprowadzania zmian w środowisku testowym i pomostowym. Mimo to zawsze istnieje szansa, że sprawy potoczą się na południe, a wtedy potrzebujesz planu awaryjnego. Bardzo ważne jest, aby zachować kopię zapasową metadanych organizacji i do tego służą kontrola wersji i kompilacja CI .
Kontrola wersji jest absolutną koniecznością dla każdej organizacji. Umożliwia programistom współpracę, wydajną i bezpieczną pracę. Zarządzanie rozwojem i migracją kodu dla wielu deweloperów, w wielu piaskownicach jest wyzwaniem w Salesforce. Salesforce ma również własny harmonogram wydań i konserwacji. Te aktualizacje zapewniają nowe funkcje, ale mogą wprowadzić zmianę w interfejsie API metadanych, która może spowodować uszkodzenie kompilacji CI. Tak więc, poza sytuacjami, w których programiści nadpisują nawzajem swoje zmiany, kontrola wersji pomaga w budowaniu strategii wycofywania zmian. Posiadanie strategii wycofywania jest koniecznością, gdy Twoja aplikacja działa na Force.com.
Poniższy schemat blokowy przedstawia praktyczną strukturę kontroli wersji i CI. Postaramy się krótko opisać, co przedstawia diagram.
- Deweloper zaewidencjonowałby swoją zmianę w systemie kontroli wersji.
- Serwer CI/Jenkins wdrożyłby najnowszą kompilację do piaskownicy CI i uruchomiłby klasy testowe.
- Jeśli wdrożenie w kroku 2 zakończy się pomyślnie, zmiany są scalane z gałęzią kontroli jakości.
- Następnie CI wdrożyłby najnowsze zatwierdzenie z gałęzi QA do piaskownicy QA.
- Jeśli kontrola jakości odrzuci zmiany z powodu niepowodzenia testu, kroki od 1 do 3 należy wykonać ponownie, dopóki kontrola jakości nie usunie zmian.
- Gdy zmiany przejdą testy w QA, są one scalane z gałęzią Master.
- Najnowsze zmiany z gałęzi Master są wdrażane do piaskownicy Master.
W zależności od potrzeb organizacji można dodać więcej oddziałów. Ale powyższa struktura działa dobrze dla struktur rozwoju na poziomie średnim i korporacyjnym.
Zarządzanie piaskownicą
Aby jak najlepiej wykorzystać proces DevOps w Twojej organizacji, bardzo ważne jest skonfigurowanie struktury piaskownicy. Zanim zagłębimy się w to znacznie głębiej, omówmy różne typy piaskownic, które oferuje nam Salesforce.
Piaskownica to prawie dokładna kopia metadanych produkcyjnych. Piaskownice są zwykle używane do celów programistycznych, testowych, przejściowych i szkoleniowych. Istnieją cztery rodzaje piaskownic i przy wyborze piaskownicy należy wziąć pod uwagę. Piaskownice Full Copy mogą kosztować dużo pieniędzy!
Poniżej znajduje się tabela z ograniczeniami narzuconymi przez Salesforce dla różnych piaskownic.
Tabela 2: Porównanie limitów
| Deweloper | Zaawansowany programista | Kopia częściowa | Pełna kopia | |
|---|---|---|---|---|
| Dane produkcyjne | Nie | Nie | TAk | TAk |
| Przechowywanie danych | 200 MB | 1 GB | 5 GB (10 tys. rekordów na obiekt) | Pełne dane |
| Okres odświeżania | 1 dzień | 1 dzień | 5 dzień | 29 dzień |
Widzimy, że cena nie jest jedyną różnicą między piaskownicami.
Piaskownica dla deweloperów ma jednodniowy okres odświeżania, co sprawia, że nadaje się do programowania, ale może pomieścić tylko 200 MB danych i nie ma danych produkcyjnych. W przeciwieństwie do tego, piaskownice z pełną kopią mają dokładną kopię danych produkcyjnych; nawet identyfikatory rekordów są takie same. Może to sprawić, że świetnie nadaje się do testowania i testowania, ale 29-dniowy okres odświeżania utrudnia uzyskanie najnowszych metadanych i danych produkcyjnych w pełnej piaskownicy kopii.
Poniższa tabela jest praktyczną regułą wyboru piaskownic:
Tabela 3: Przypadki użycia przy wyborze piaskownicy
| Deweloper | Zaawansowany programista | Kopia częściowa | Pełna kopia | |
|---|---|---|---|---|
| Rozwój | TAk | TAk | Nie | Nie |
| Kontrola jakości | TAk | TAk | TAk | Nie |
| Test integracyjny | Nie | Nie | TAk | TAk |
| Test danych partii | Nie | Nie | TAk | TAk |
| Szkolenie | Nie | Nie | TAk | TAk |
| UAT | Nie | Nie | TAk | TAk |
| Test obciążenia | Nie | Nie | Nie | TAk |
| Inscenizacja | Nie | Nie | Nie | TAk |
| Trening użytkownika | Nie | Nie | Nie | TAk |
Poniżej znajduje się typowa struktura organizacyjna, która jest przyjęta dla projektów średniej wielkości. W przypadku klientów na poziomie korporacyjnym struktura organizacji staje się bardziej złożona, ale zasadniczo jest zgodna z poniższym modelem.
Programowanie Salesforce odbywa się zwykle w piaskownicy deweloperskiej (czerwona), a zmiany są przenoszone do piaskownicy integracji (zielonej), która jest zwykle piaskownicą dla programistów lub częściową piaskownicą kopii. Następnie zmiany z wielu piaskownic integracji są przenoszone do piaskownicy zbiorczej (żółtej), która powinna być piaskownicą częściowej kopii.
Jeśli Twoja organizacja ma jakiekolwiek integracje z systemem innej firmy, który wymaga przeprowadzenia testów integracyjnych i testów obciążeniowych, musisz mieć stabilny zestaw danych, który nie zmienia się od wydania do wydania. Dlatego lepiej jest mieć dla niego pełną kopię lub częściową piaskownicę kopii.
Zmiany te są następnie przenoszone do piaskownicy testowania integracji, gdzie przeprowadzane są testy. Następnie zmiany są przenoszone do pomostowej piaskownicy, która powinna być pełną kopią piaskownicy. Wszystkie klasy testowe są uruchamiane przed wdrożeniem. Należy przeprowadzić weryfikację wdrożenia, aby upewnić się, że wdrożenie przebiega bez żadnych problemów.
Ten proces pomaga nam upewnić się, że zmiany przechodzą przez wiele rund testów i par oczu. Ma to poważny minus polegający na tym, że opracowywanie, testowanie i wdrażanie zmian zajmuje dużo czasu.
Bardzo często istnieje pilna potrzeba wykonania poprawek lub łat. Aby szybko się z nimi uporać, należy zachować piaskownicę deweloperską, która wypychałaby małe łatki bezpośrednio do piaskownicy rollup.
Jak wspomniano wcześniej, piaskownica jest prawie dokładną repliką metadanych produkcyjnych, ale nie do końca. Istnieje oficjalna lista komponentów/funkcji, które są wyłączone w piaskownicy.
Inną rzeczą do rozważenia podczas odświeżania piaskownicy jest to, że kopiuje ona tylko metadane i dane produkcyjne. Nie ma możliwości skopiowania metadanych z jednej piaskownicy do drugiej ani nawet utworzenia pustej piaskownicy bez żadnych konfiguracji metadanych (takich jak bezpłatne organizacje programistyczne). Czasami staje się to wyzwaniem w rzeczywistych sytuacjach. Salesforce planuje rozwiązać ten problem i ta funkcja może wkrótce stać się ogólnie dostępna.
Dodatkowo, jeśli masz jakieś wrażliwe dane w produkcji, do których uważasz, że Twój zespół programistów lub testerów nie powinien mieć dostępu, możesz utworzyć szablony piaskownicy dla w pełni i częściowo skopiowanych piaskownic.
Co wziąć pod uwagę podczas wdrażania
Omówiliśmy branżowe praktyki zarządzania cyklem życia aplikacji w ekosystemie Salesforce. Zarządzanie metadanymi i piaskownicą odgrywa bardzo ważną rolę w tworzeniu pakietów wdrożeniowych i ładunków. W przypadku dużych i złożonych aplikacji Salesforce kontrola wersji pomaga upewnić się, że zmiany metadanych są śledzone, a także pomaga w tworzeniu strategii wycofywania zmian.
Zarządzanie piaskownicą ma kluczowe znaczenie w przypadku dużych lub złożonych projektów. Ale piaskownice są kosztowne w ekosystemie Salesforce, zarówno pod względem zasobów finansowych, jak i czasu. Sformułowanie strategii zarządzania piaskownicą jest zawsze krytyczne dla procesu zarządzania wydaniami.
Zostawimy Ci kilka dodatkowych punktów, o których warto pamiętać podczas następnego wdrożenia:
- Za jednym razem można wdrożyć tylko 10 000 plików lub plik ZIP o wielkości 39 MB. Oczywiście, jeśli ładunek jest zbyt duży, musisz podzielić pakiet na wiele części, a następnie wykonać wdrożenie.
- Jeśli wdrożenie nie powiedzie się z powodu błędu
request timeout, spróbuj usunąć obiekty, pola niestandardowe i profile z pakietu. Wdrożenie tych składników trwa dłużej. - Jeśli typ pola zostanie zmieniony lub nastąpiły zmiany w hierarchii ról, mogą wystąpić duże opóźnienia spowodowane ponownym obliczeniem danych, które wymagają trochę czasu na ukończenie.
- Salesforce blokuje każdy komponent, który jest aktualnie używany przez użytkownika w systemie. Jeśli spróbujemy wdrożyć w tym czasie, wdrożenie się nie powiedzie.
Mamy nadzieję, że ten przegląd pomoże Ci podczas następnej wersji Salesforce.