Continuous Integration & Continuous Delivery, a wzorcowe ułożenie projektu SAP

Napisany przez
Hubert Falkowski
CI (Continous Integration) oraz CD (Continuous Delivery lub czasami Continuous Deployment) to pojęcia, które coraz częściej pojawiają się także w kontekście projektów SAP. Stało się tak wraz z rozwojem rozwiązań chmurowych oraz rosnącą liczbą aplikacji UI5. Za co ceni je współczesny świat SAPowy?

Czym jest CI?

Continous Integration oznacza ciągłą integrację. Dla programistów jest to równoznaczne z możliwością scalania zmian kodu tak często, jak to tylko możliwe. Zmiany po wysłaniu do Git są weryfikowane za pomocą automatycznych testów.

Czym jest CD?

Najczęściej skrót ten oznacza Continous Delivery, choć czasami stoi za nim także Continous Deployment.

Pierwsze rozwinięcie oznacza szybkie i zrównoważone udostępnianie nowopowstałych zmian użytkownikom. Jest to ściśle powiązane z CI. Continous Delivery umożliwia proste wdrożenie aplikacji w dowolnym momencie.

Continous Deployment idzie o krok dalej. Jeżeli CI przebiegło bez problemów i zakończyło się sukcesem, aplikacja zostaje udostępniona automatycznie, bez konieczności jakiegokolwiek działania, choćby kliknięcia.

Jest wiele narzędzi pozwalających używać CI / CD dla aplikacji UI5. Większość z nich działa w chmurze. Niektóre są zewnętrzne, inne pochodzą od SAP, który ciągle je rozwija. Uproszczenie tej opcji powinno przede wszystkim ograniczyć konieczność instalowania wielu różnych komponentów oraz przeprowadzenie licznych konfiguracji.

Modelowy setup projektu Fiori w Hicron wygląda następująco:

modelowy projekt SAP Fiori nagłówek

Etapy przygotowania projektu:

  1. Zestawienie bezpiecznego połączenia Gateway ó Cloud connector
  2. Utworzenie struktury projektowej w GitLab
  3. Konfiguracja połączenia GitLab ó Gateway system, mającej na celu możliwość uruchomienia aplikacji automatycznie na serwerze (konfiguracja techniczna / gałęzi / code review, etc.)
  4. Przygotowanie konfiguracji dla faz CI/CD (ang. CI/CD pipelines):
    1. Build
    2. Test
    3. Stage

Etapy developmentu:

  1. W tak przygotowanym środowisku każda zmiana tworzona jest w oddzielnych gałęziach na podstawie gałęzi (ang. branch) głównej.
  2. Programista do każdej zmiany pisze testy jednostkowe które automatycznie uruchamiane są w GitLab.
  3. Po przejściu poprawnie testów każda zmiana musi przejść code review.
  4. Po poprawnym code review zmiana zostaje scalona z gałęzią główną.
  5. Po poprawnym scaleniu aplikacja jest automatycznie budowana wg pipelines (jw.) i wysyłana do systemu Gateway (DEV).

CI/CD w OData

Zakres systemów dzieli się na trzy różne wersje: do programowania (DEV), do testowania (TEST) i produkcyjny (PROD). W tej kolejności są one połączone ze sobą ścieżkami transportowymi, po których zlecenia są eksportowane z jednego systemu i importowane do następnego.

Łącząc CI/CD dla Fiori zapewniona pozostaje odpowiednia jakość kodu. CI pozwala konwertować źródła do odpowiedniego formatu, uruchamia automatyczne testy oraz tworzy obiekt developerski, który jest gotowy, by przesłać go do repozytorium SAP (na system DEV). Stamtąd system SAP przenosi zmiany do systemu testowego, a na końcu do produkcyjnego. Komunikacja pomiędzy SAP a Git odbywa się poprzez cloud connector z wykorzystaniem protokołu OData (wg standardowej implementacji).

Continuous Integration, Delivery oraz Deployment przynoszą szereg benefitów. To nie tylko stworzenie procesu integracji zmian w kodzie aplikacji oraz częstego i automatycznego wdrażania zmian. To także możliwość równoległej pracy programistów, skrócenie czasu oczekiwania na feedback od użytkowników końcowych, ułatwienie swojej pracy i zminimalizowanie opcji wystąpienia błędów dzięki code review i testom automatycznym. Zestaw tych narzędzi pozwala na minimalizowanie docelowych kosztów podczas wspierania i długoterminowego rozwoju aplikacji.

Hubert Falkowski
SAP Technology Consultant, Hicron

Ta strona używa plików cookie. Kontynuując korzystanie z tej witryny, zgadzasz się z naszą Polityką Prywatności.

Wyrażam zgodę