Jak radzisz sobie z wersjonowaniem w projekcie wielostronnym?

Wiem, że to szerokie pytanie, więc postaram się być jak najbardziej konkretny. To pytanie jest bardziej „organizacyjne” niż techniczne.

Mamy wielostronny projekt z tymi głównymi komponentami:

• Serwer hostujący podstawową logikę biznesową (modele danych)
• Backoffice dla klientów korzystających z podstawowej logiki biznesowej
• Interfejs API aplikacji (REST), który również korzysta z podstawowej logiki biznesowej
• Istnieją aplikacje na smartfony (iOS i Android) korzystające z interfejsu API aplikacji
• Istnieje inna aplikacja na tablet (Android) inna niż smartfon, która korzysta z tego samego interfejsu API aplikacji.

Wkrótce będę produkować z aktywnymi klientami. I jak każdy projekt, będę musiał utrzymywać wszystkie różne komponenty w czasie. Oznacza to, że można zaktualizować wszystkie następujące elementy:

• kod podstawowej logiki biznesowej na serwerze (używany przez back-office, API i jako efekt uboczny, przez aplikacje mobilne)
• sam interfejs API (używany w aplikacjach na smartfony i tablety)
• wszystkie aplikacje mobilne (przez appstore / googleplay)

Oczywiście części po stronie serwera (podstawowy kod logiki biznesowej i kod API) mogę natychmiast zmienić samodzielnie. Jednak nowe aplikacje mobilne muszą zostać pobrane przez klientów w sklepie z aplikacjami / googleplay i nie jestem pewien, czy są aktualne.

Czy możesz podać jakieś wskazówki, wskazówki dotyczące dobrych praktyk, aby uaktualnienia prac były płynne i bez ryzyka dla klienta?

Którego elementu potrzebuję do „wersji”? Jak upewnić się, że wszystko działa, nawet jeśli klient nie uaktualni swojej aplikacji mobilnej? Czy powinienem zmusić go do ulepszenia, aby ułatwić mi pracę?

Jednym słowem, jak powinienem się zorganizować, aby mój projekt był realizowany z czasem?

Ponieważ nie możesz kontrolować, kiedy aplikacje mobilne będą aktualizowane do nowej wersji, musisz zaktualizować przynajmniej interfejs API REST. Jeśli tego nie zrobisz, nie będzie możliwe wprowadzenie wstecznie niezgodnych zmian w tym interfejsie.

Poza interfejsem API REST dobrym pomysłem jest także wersja innych interfejsów komunikacyjnych, które przechodzą przez interfejs sieciowy. W ten sposób nie musisz również aktualizować wszystkich klientów backoffice w tym samym czasie co serwery i możesz zaimplementować stopniową migrację do nowej wersji z okresem „testów beta”.

Oprócz wersjonowania interfejsów komunikacyjnych, powinieneś również postarać się, aby zmiany były jak najbardziej kompatybilne wstecz. Idealnie byłoby wprowadzić nową wersję interfejsu, która nadal w pełni obsługuje starych klientów, aby nie zauważyli, że nic się zmieniło.

Ten post stanowi interesujący punkt dotyczący twojego pytania.

W bardziej praktyczny sposób, jeśli masz 3 elementy:

• 2 konsumentów: interfejs użytkownika i aplikacja mobilna
• 1 dostawca API: back-end

Możesz użyć typowego schematu kontroli wersji Mmp (Major.minor.patch) dla każdego z nich, ale w adresie URL zaplecza możesz umieścić coś jako http://youhost/M.m/resourceURI.

Gdy ewoluujesz, a zmiany w interfejsie API nie wpływają na umowę z konsumentami, trzymaj taką, M.mjaka jest w adresie URL. Od momentu wprowadzenia zmiany w BackEnd, która wpływa na twoich konsumentów (czy to na zmianę zachowania, czy na inny obiekt), używasz M.m+1, M+1.m+1lub M+1.m.

Sposób na utrzymanie działania polega na jednoczesnym wdrożeniu nowego zaplecza ze starym, podczas gdy użytkownicy instalują nowych klientów i powoli przerywają starsze API.

Możesz zobaczyć o wiele lepszą odpowiedź niż moja, tutaj: Versioning REST API na Stackoverflow

Zalecam zainstalowanie serwera ciągłej integracji, podłączenie go do repozytorium kodu i repozytorium migawek / wydań oraz zautomatyzowanie kompilacji. Będzie to miało wiele zalet:

1. Każdy składnik zostanie zaktualizowany w momencie jego wydania. Dotyczy to bibliotek niskiego poziomu, a także produktów końcowych.
2. Każde zatwierdzenie kodu wywoła kompilację migawki. Pomaga to zachować uczciwość programistów, zwłaszcza jeśli korzystasz z narzędzia do wysyłania wiadomości e-mail do winowajcy, który złamał kompilację.
3. Każda kompilacja może uruchamiać testy jednostkowe. To znacznie poprawia jakość kodu.
4. Każda wersja będzie oznaczona tagami, więc jeśli wymagana jest poprawka produkcyjna, łatwo jest ją rozgałęzić i wykonać poprawkę.
5. Będziesz musiał prowadzić pewnego rodzaju rejestr zgodności. (np. BackOffice 1.0.23 jest kompatybilny z REST API 2.0.267 itp.). Nie znam narzędzia, które pomoże w tej dziedzinie.

Moje doświadczenie dotyczyło narzędzi open source: SVN, Maven 2, Jenkins i Nexus, ale istnieją alternatywy dla nich wszystkich.

Nie lekceważ czasu nauki, aby przyspieszyć swój zespół. Ale kiedy osiągną prędkość, nigdy nie wrócą.

W przypadku stosunkowo niewielkiego zespołu ds. Programowania i wdrażania model zgodności klienta N-1 zastosowany przez IBM Jazz może działać całkiem dobrze

Staraj się, aby klienci i serwery miały ten sam numer wersji. [Zamiast zarządzać matrycą niezależnych wersji i ich kompatybilności]

Ustal zasady, że wersja klienta Xyy powinna współpracować ze wszystkimi wersjami serwerów powyżej Xyy, ale niższymi niż X + 2.0.0

W przypadku wersji serwerowej 4.0 najlepiej byłoby mieć wersję klienta 4.0 dla każdego typu klienta. Należy jednak zachować zgodność, aby umożliwić nieco inne wersje klientów i serwerów.

Wersja klienta 4.x powinna być kompatybilna z serwerami w wersji 4.x i wyższej, ale poniżej 6.0; Serwer 4.x powinien być zgodny ze wszystkimi klientami w wersji 3.0 i nowszej, ale mniejszej lub równej 4.x

W ten sposób możesz zaktualizować wersję na serwerze, nie martwiąc się o natychmiastowe wydanie nowych wersji klientów, ale będziesz miał tylko dobrze zdefiniowane okno zgodności do utrzymania.

Patrz: IBM Jazz Model [ https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html]

Po pierwsze, zacznijmy od sformułowania problemu trochę inaczej. Zapytałeś, które oprogramowanie potrzebujesz do „wersji”. Wersja jest przeciążonym terminem w CS i może oznaczać około 100 różnych rzeczy. Najważniejsze rzeczy, na które chciałbym spojrzeć to:

1. Kontrola wersji - Kontrola wersji to narzędzie do zarządzania konfiguracją, które pomaga śledzić migawki i historię rozwoju. WSZYSTKIE KODY POWINNY BYĆ POD KONTROLĄ WERSJI. Nie obchodzi mnie, czy to tylko skrypty wygody, które dodajesz do folderu bin, wszystko, co było warte spędzenia czasu na pisaniu, jest warte dwóch sekund na dodanie do oprogramowania do kontroli wersji.
2. Zarządzanie konfiguracją - jak kontrolować zawartość kompilacji. Całe oprogramowanie powinno mieć pewien stopień zarządzania konfiguracją. Lubię opisywać menedżerom różnicę między kontrolą wersji a zarządzaniem konfiguracją, ponieważ kontrola wersji to tylko narzędzie do śledzenia historii rozwoju, podczas gdy zarządzanie konfiguracją to wytyczne dotyczące tego, jak tworzymy historię i jak decydujemy o kodzie jest dobry.
3. Wersjonowanie oprogramowania - przypisywanie nazw do wydań kodu. Jest to rzecz, na którą wielu ludzi chwyta się, gdy po raz pierwszy widzą problem, ponieważ są przyzwyczajeni do oglądania „MineSweeper 7.1.29290149210” lub cokolwiek innego na kupowanych przez siebie rzeczach, ale szczerze mówiąc, uważam to za najmniejszą część znacznie większego problemu. Szczerze mówiąc, wystarczy użyć skrótu wygenerowanego przez 1 i nie przejmować się tym tak bardzo, że jego czytelność dla ludzi jest całkowicie w porządku.

Ponieważ jest to dla mnie najbardziej mgliste i najbardziej interesujące, skupię się na # 2. Nie ma jednego uniwersalnego rozwiązania do zarządzania konfiguracją plików cookie. Zasady, które działają dobrze dla zespołu 2 lub 3, mogą być zbyt luźne, aby zachować rozsądek w projekcie, który wymaga setek pracowników. Zasady, które działają w dużym zespole, mogą wymagać zbyt dużego obciążenia dla małego zespołu. Najprawdopodobniej będziesz musiał zbudować coś własnego, aby coś połączyć, ale skorzystam z poniższej listy jako sposobu opracowania specyfikacji systemu zarządzania konfiguracją:

1. Jak mogę śledzić wersje (i związane z nimi problemy), które obsługuję na rynku?
2. Jak zdecydować, które ścieżki programowania są gotowe do wydania na systemy produkcyjne? (Może być również gotowy na każdy inny etap procesu)
3. Kto powinien kontrolować / zarządzać konfiguracją systemu? Jaki jest przepływ pracy podczas dodawania kodu, który ma być dystrybuowany do innych programistów?
4. Jak mam kontrolować interakcje między częściami? Skąd będę wiedział, czy zmiana części spowoduje uszkodzenie reszty systemu?
5. Jak z czasem ulepszymy nasz system zarządzania konfiguracją.

Potrzebujesz pomocy w odpowiedzi na powyższe pytania? Prawdopodobnie powinieneś zatrudnić konsultanta lub inżyniera oprogramowania ... odpowiedź, która może wypełnić podręczniki i jest poza zasięgiem tego typu forum.