Strategia wdrożenia web aplikacji

Strategii wytwarzania, zarządzania i wdrażania web aplikacji w zespole jest co najmniej kilka. Dzisiaj chciałbym przedstawić wam strategie, którą ostatnio sami zastosowaliśmy w projekcie.

Załóżmy, że mamy niewielki zespół ok. 4-9 osób, projekt podzielony jest na backend oraz frontend (web aplikacja oraz aplikacja mobilna). Oznacza to, że potrzebujemy przynajmniej trzech repozytoriów oraz strategii utrzymania backendu w spójności z frontendem. Chcemy uniknąć sytuacji, w której zespół backendowy wydał nową funkcjonalność, lecz zespół frontendowy, nie zdążył dostosować swoich aplikacji pod nową wersję API.

Oczywiście możemy użyć wersjonowania API lub wykorzystać strategie Feature Flags, lecz oba te podejścia dokładają swój narzut czasowy i implementacyjny. Jako że nasz projekt jest jeszcze młody, tym samym zmiany zachodzą dynamicznie, uznaliśmy, że potrzebujemy czegoś bardziej elastycznego.

W naszym przypadku mamy 3 główne branche development, test, demo oraz tworzymy feature branch dla każdej nowej funkcjonalności.

Do tej pory działaliśmy w poniższy sposób:

• Frontendowcy używali API z brancha test.
• Tworzyliśmy feature branch.
• Po skończonej implementacji tworzyliśmy Merge Request. Po przejściu Code Review mergowaliśmy feature branch do brancha development.
• Kiedy chcieliśmy wrzucić zmiany z brancha development na branch test pytaliśmy się frontendowców, czy możemy.
  • Jeżeli tak, mergowaliśmy branche.
  • Jeżeli nie, czekaliśmy na zielone światło od frontendoców.

Podejście to miało jednak duży minus. Przeważnie dochodziło do wrzucenia kilku nowych funkcjonalności do API, z którego korzystali frontendowcy, tym samym, nie zawsze zauważono, iż jedna z funkcjonalności nie powinna zostać jeszcze wrzucona. Szczególnie w przypadku funkcjonalności, które były tzw. funkcjonalnościami Breaking Change.

Obecnie mamy poniższą strategię:

• Frontendowcy używają brancha development zamiast test.
• Tworzymy feature branch.
• Po skończonej implementacji tworzymy Merge Request
  • Jeżeli zaimplementowana funkcjonalność nie zmienia obecnego "kontraktu" (o tym za chwilę opowiem) API, po skończonym Code Review od razu mergujemy feature branch do brancha development. W takim przypadku nie jesteśmy w stanie zepsuć obecnie działającego frontu, ponieważ nasza funkcjonalność nie wpływa na niego.
  • Jeżeli zaimplementowana funkcjonalność zmienia "kontrakt" API, oznaczamy Merge Request literkami BC (Breaking Change). Po skończonym Code Review, pytamy się frontendowców, czy dostosowali swoje aplikację pod nową funkcjonalność, jeżeli tak mergujemy feature branch na development, jeżeli nie feature branch, czeka na dostosowanie frontendu.

Takie podejście zawsze zapewnia nam spójność pomiędzy backendem, a frontendem. Nie jesteśmy w stanie zepsuć frontendu nowymi zmianami. Na dodatek nie musimy utrzymywać kilku wersji tego samego endpointu po stronie backendu. Oprócz tego zapewnia nam także spójność w kolejnych etapach/pozostałych branchach, np. development <-> test

Wróćmy teraz do wcześniej wspomnianej kwestii kontraktu i definicji pojęcia Breaking Change.

Za Breaking Change uznaje się zmiany, które nie są wstecznie kompatybilne z kontraktem, jakie przyjmuje API z "klientami". Przeważnie są to zmiany w parametrach, jakie przyjmuje API lub struktura odpowiedzi jakie, API zwraca. Ogólnie rzecz ujmując, jeżeli jakakolwiek zmiana po stronie API burzy komunikację z, chociaż z jednym "klientem" od strony frontendowej, zmiana ta może zostać uznana jako Breaking Change.

Oprócz powyżej opisanej strategii omawialiśmy w zespole także dwie inne, lecz tylko ta dała nam możliwość szybkiego wdrażania kolejnych funkcjonalności. Oczywiście nie twierdze, że jest to jedyna słuszna strategia, aczkolwiek w naszym przypadku się sprawdza.

Jeżeli obecnie uczestniczysz w kilku osobowym projekcie i macie problemy z utrzymaniem spójności pomiędzy API, a "klientami" frontendowymi, zachęcam do wypróbowania powyższej strategii i sprawdzenia, czy w Twoim zespole także spełni swoją funkcje.