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?
Odpowiedzi:
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.
źródło
Ten post stanowi interesujący punkt dotyczący twojego pytania.
W bardziej praktyczny sposób, jeśli masz 3 elementy:
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.m
jaka 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żywaszM.m+1
,M+1.m+1
lubM+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
źródło
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:
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ą.
źródło
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]
źródło
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:
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ą:
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.
źródło