Kompatybilność usług jest problemem w każdej architekturze SOA, ale w przypadku mikro-usług staje się jeszcze bardziej widoczna. W przyszłości chce napisać post o tzw. consumer-driven contracts, które znacząco mogą zminimalizować potrzebę wersjonowania usług. W każdym razie, bardzo prawdopodobne, że w pewnym momencie zajdzie potrzeba wprowadzenia zmiany, która nie jest kompatybilna wstecz.
Jeśli nasz system składa się np. z 20 usług to musimy mieć mechanizm, który zagwarantuje nam, że nie wprowadzimy zmiany w którejś z usług, która spowoduje, że całość przestanie działać. Jednym z rozwiązań jest tzw. semantyczne wersjonowanie (semantic versioning).
Idea jest bardzo prosta. Każda z usług jest opisana wersją w następującym formacie:
Major.Minor.Patch (przykład 3.5.15)
Major to najbardziej dotkliwa zmiana wersji i dotyczy funkcjonalności, która nie jest kompatybilna z poprzednimi wersjami. Usługa 3.5.16 nie jest kompatybilna z 2.5.16.
Minor oznacza nową funkcjonalność, ale jest ona kompatybilna z poprzednimi wersjami. Może to dotyczyć zatem dodania nowej metody do usługi, co naturalnie nie powinno mieć znaczenia dla starszych klientów.
Patch dotyczy drobnych zmian typu naprawienie błędu, refaktoryzacja itp. Naturalnie jest to najbezpieczniejsza zmiana ponieważ nie zmienia nawet API\kontraktu.
Proszę zauważyć, że nie możemy polegać na standardowym wersjonowaniu, gdzie każdy commit zmienia patch. Zwykle, w wiadomości każdego commit’a podaje się numer user story albo błędu. Następnie CI może na podstawie tego, zdecydować, który segment wersji należy zmienić (major, minor, patch).
Możliwe jest również doczepianie tagu, np. 3.5.15-prealpha albo 3.5.16-release. Dla dzisiejszego postu nie ma to jednak znaczenia.
Wiemy zatem, że każda usługa jak i klient powinien mieć wersję. Konsument takiej usługi powinien mieć test jednostkowy sprawdzający jego wersje klienta z aktualnie dostępną wersją usługi. Jeśli wersja major konsumenta i usługi są różne, to wykonanie takiego testu powinno zakończyć się błędem. Dzięki temu, mamy pewność, że usługi w systemie są ze sobą kompatybilne i w momencie niekontrolowanej zmiany wersji, zostanie to wykryte w CI. Bez takich testów jednostkowych i semantycznego wersjonowania byłoby ciężko mieć kontrolę nad wszystkimi usługami i każda zmiana niosła by za sobą ryzyko, że coś zostanie popsute.