Continuous Integration (CI) jest praktyką częstej publikacji nowego kodu do głównego repozytorium (nawet kilka razy dziennie przez każdego programistę). Każdorazowo, gdy pojawia się nowy kod w repozytorium, następuje automatyczne zbudowanie oraz wdrożenie aplikacji i uruchomienie testów. Zaletą takiego podejścia jest wykrywanie problemów we wczesnej fazie rozwoju.
Dodatkowo umożliwia to podgląd funkcjonalności rozwijanych w projekcie podczas prac programistycznych. Częste wysyłanie kodu zwiększa jego modularność (mniejszy poziom skomplikowania), a także polepsza ogólną jakość. Przekłada się to na mniej czasu spędzonego przy analizie problemów, zatem zyskujemy więcej czasu na dodawanie nowych funkcjonalności. Zastosowanie tego podejścia pozwala uniknąć problemów z integracją i chaosu podczas wydań aplikacji. Zwiększenie przejrzystości rozwoju aplikacji zmniejsza ilość potrzebnej komunikacji w zespole.
Na początku procesu rozwoju aplikacji każdy w zespole musi przygotować dla siebie środowisko programistyczne, w którym będzie mógł wykonywać potrzebne zmiany. Obecnie możemy skorzystać z nowoczesnego środowiska jakim jest SAP Web IDE. Pomimo tego, że możemy wykonać większość prac tylko przy użyciu lokalnego środowiska programistycznego, komfortowym i rekomendowanym przez SAP rozwiązaniem jest skorzystanie z Web IDE jako pierwszego środowiska programistycznego. W razie potrzeby stworzenia nowej aplikacji, najwygodniej będzie użyć predefiniowanych szablonów dostępnych w Web IDE.
Do pobierania i wysyłania (Pull, Commit, Push) zmian z centralnego repozytorium GIT jest potrzebna konfiguracja Gerrita. Każdy programista w zależności od grupy, do której przynależy w projekcie może korzystać z repozytorium GIT oraz sprawdzać kod zmian innych członków zespołu poprzez narzędzie Gerrit. Tylko sprawdzony i zatwierdzony kod zmian zostanie domergowany w repozytorium GIT. Dodatkowo Gerrit Voter Job działający na serwerze, który buduje aplikację (Jenkins) uruchamia automatycznie proces budowania technicznej wersji testowej zawierającej najnowsze przesłane zmiany.
Kolejnym przykładem zautomatyzowanego zdarzenia w przedstawionej infrastrukturze jest wysyłanie fragmentów zasobów, które zostają docelowo przetłumaczone na wiele języków. Zlokalizowane zasoby będą pobrane do środowiska rozwojowego i testowego. Zarządzanie repozytorium zbudowanych aplikacji jest możliwe dzięki Nexusowi. Repozytorium to odpowiada również za dystrybucję stworzonych “paczek” do samodzielnego systemu ABAP UI DEV.
Testy nowych zmian, mogą być przeprowadzane w oparciu o lokalny serwer TomCat z zestawem danych testowych, a także w oparciu o wyeksponowane serwisy oData. Zatem każdy członek zespołu, jest w stanie testować aplikację bez potrzeby połączenia do backendu. Wartym rozważenia pomysłem, jest wykorzystanie centralnego serwera TomCat, z którego każdy deweloper z zespołu mógłby korzystać bez konieczności utrzymania oddzielnej instancji na lokalnym komputerze. Centralny serwer może również posłużyć jako ostatnie miejsce przed wysyłką zbudowanej aplikacji do ABAP UI DEV.
Git
Git to system kontroli wersji służący do śledzenia zmian w plikach komputerowych i koordynowania prac nad tymi plikami wśród wielu osób.
Jenkins
Jenkins jest serwerem automatyzującym proces budowania aplikacji. Docelowo służy on do przyspieszenia procesu dostarczania oprogramowania.
Nexus
Nexus to menedżer repozytorium – może on obsługiwać wiele repozytoriów równocześnie. Mogą one odgrywać różne role w procesie wypuszczania oprogramowania (repozytoria migawek i wydania). Co więcej, możliwe jest posiadanie repozytoriów obsługujących różne formaty techniczne.
Zostaw komentarz