ProkrastynacjaW Straszna rzecz. Szczególnie w połączeniu z ogólnym wypaleniem się tematów do opisywania. Dziś jednak zaczynamy zabawę z pewnym rozwiązaniem, które ostatnio staram się „wyczarować”.

Opis problemu

Jeżeli klient daje nam wolną rękę co do infrastruktury albo sami jesteśmy własnym klientem i mamy swobodę decydowania o tym na czym posadzimy aplikację to jest naprawdę fajnie. Gorzej jeżeli klient, na przykład duży bank, narzuca nam dość ostre ograniczenia co do dostępnej infrastruktury. Zazwyczaj w tego typu sytuacjach musimy dostosować nasze narzędzia do współpracy z narzędziami klienta. Te znowuż zazwyczaj nie posiadają żadnego rozsądnego API (poza stroną web), często działają tylko w np. IE, a całość jest doprawiona kontrolkami ActiveX i opiera się na konfiguracji domeny naszego komputera. Chcesz użyć dockera? Nie da się. Ansible by zarządzać realisami? Zapomnij. CI z opcją automatycznego deployu na serwery. Oczywiście… po sambie… i tak dalej i tak dalej.

Koniec końców pojawia się problem utrzymania aplikacji w kilku różnych wersjach ponieważ cały projekt jest rozsiany po świecie i niektóre zespoły nie wyrabiają się z zadaniami albo jakiś mendadżer średniego szczebla poczuł zew władzy i nie zgadza się na zmianę wersji jakiegoś elementu w systemie. Tak czy owak przychodzi smutny mail w rodzaju „ma działać w obu wersjach na raz i nie ważne co zrobicie”. A potem stoisz człowieku w swojej nowej Tesli S (która ma filtry powietrza by oczyszczać to co przelatuje przez kabinę), a przed tobą VW w TDi-ku…

Tu trafiamy na dwa problemy.

Wersjonowianie API

Pierwszym prostszym problemem jest utrzymanie wielu wersji API aplikacji. Jeżeli mamy szczęście to komunikacja odbywa się z wykorzystaniem API restowego, albo jakiegoś podobnego. Dzięki temu możemy spokojnie definiować w jakiej wersji przychodzi żądanie.
Obecnie problemem nie jest też utrzymywanie wielu instancji aplikacji w ramach pojedynczego serwera aplikacji. W ostateczności możemy utrzymywać wiele serwerów aplikacji, które będą hostować kolejne wersje naszego API.
O tym jak to robić opowiem w części drugiej.

Wersjonowanie schematu danych

Tu mamy grubszy problem. Często wraz ze zmianą API muszą być zmienione różne elementy w bazie danych. Małym problemem jest dodanie kolumny czy tabeli. Widoki, funkcje, procedury też nie stanowią problemu. Znacznie poważniejszym wyzwaniem jest zmiana już istniejących obiektów np. typu kolumny albo usunięcie tabeli. Można temu problemowi zaradzić i opisze to w części trzeciej.

Narzędzia itp.

Jak wspomniałem cała zabawa polega na tym, że klient bardzo mocno ogranicza nasze środowisko. Na potrzeby tego cyklu wszystko będzie zatem zrobione „po staremu”. Bez dockera, vagranta i temu podobnych. Wykorzystane zostaną spring boot i postgres. Całość na tomcat-ie 🙂