Continuous delivery

0

Witam,
czy komuś z was udało się wdrożyć tą koncepcje "Continuous delivery"
Widziałem wiele prezentacji jednak żadna nie odpowiedziała mi na pytanie jak rozwiązać problemy typu:

  • jak wypuścić automatycznie wersję skoro użytkownicy na niej pracują co z ich sesjami,
  • co ze zmianami które zmieniają model danych/reorgi to nieraz musi trwać
0

jak wypuścić automatycznie wersję skoro użytkownicy na niej pracują co z ich sesjami

Musisz mieć co najmniej dwa serwery. Po wrzuceniu nowej wersji na serwery robisz:

  1. Wypinasz serwer 1 z load balancera
  2. Czekasz 30 minut
  3. Restartujesz serwer 1,
  4. Gdy serwer 1. działa, to włączasz go w load balancerze
  5. Wypinasz serwer 2 z load balancera
  6. Czekasz 30 minut
  7. Restartujesz serwer 2,
  8. Gdy serwer 2. działa, to włączasz go w load balancerze

Oczywiście nie rozwiązuje to problemu użytkowników, których sesja trwa więcej niż 30 minut.
Ewentualnie możesz zainteresować się tematem "session failover", np. http://wildfly.org/news/2014/03/14/Http-Session-Failover-WildFly/

co ze zmianami które zmieniają model danych/reorgi to nieraz musi trwać

Zmiany muszą być kompatybilne wstecz (do czasu kolejnego wdrożenia).
Np. chcesz usunąć kolumnę X z tabeli Y.
W pierwszym wdrożeniu usuwasz wszystkie odwołania do tej kolumny z aplikacji. Samej kolumny nie usuwasz.
Przy kolejnym wdrożeniu dopiero możesz usunąć tę kolumnę.

0

Dzięki za odpowiedz , Ciekawi mnie temat wypiecia sewera z balancera bo na apache mod_balancer jak oznacze node jak disabled to automatycznie żaden ruch do niego nie idzie również ten z zalogowanych sesji :-(. Chyba, że jest jakiś przełączni o którym nie wiem co mówi apache aby już nie forwardował nowego ruchu na ten serwer. Chyba, że mowa o innych balancerach

0

Sesję można trzymać jako współdzieloną w ramach clustra i wdrażać nowe wersje kolejno na serwerach (w przypadku naprawdę dużych systemów na grupach serwerów). Generalnie nie różni się to znacząco od problemu "padu" serwera w clustrze. Jedyna różnica polega na tym, że "pad" jest kontrolowany. Trochę innym podejściem jest zachowanie bezstanowości aplikacji. Na wszystkich poziomach. Można to zrobić i nawet nie jest to trudne, bo po prostu nie ma sesji, a jednym z elementów komunikacji jest wymiana tokenów bezpieczeństwa w ramach żądania (coś w rodzaju odcisku palca). Trochę z tym zabawy, ale wiele API z dużych serwisów działa w ten właśnie sposób.
Zmiana struktury danych jest trudniejsza. Dwu krokowe modyfikacje jak opisał je @__krzysiek85 są pewnym wyjściem, ale jeżeli bardzo często wypuszczasz nowe wersje (jak np. fejsbók, który robi to co 10 minut), to średnio się to sprawdzi. Prostsze jest eliminowanie użycia i pozostawienie danych.

0

Masz racje, że posiadając aplikację bezstanową lub trzymając informację o zalogowanym użytkowniku na centralnym serwerze (token) sytuacja staje się o wiele bardziej prostsza. Jednak tworzymy aplikacje w JSF 2, Vaadin, WIcket gdzie w sesji trzymany jest stan View. Mało tego w większości przypadków syf który siedzi w sesji wogólne nie jest serializaowany wieć ewentualny session replication tez nie zadzaiałą...

0

Czy używaliście "Session Failover" z WildFly?
Na slajdach (http://wildfly.org/news/2014/03/14/Http-Session-Failover-WildFly/) wygląda to bardzo dobrze, ale jak jest w praktyce? Szczególnie interesuje mnie narzut wydajnościowy.

0

Narzut jest, ale nie aż tak duży gdy porównasz z zyskami. Bawiłem się tym z ciekawości i nie trafiłem na problemy, ale znając życie jak ruszysz z czymś większym to będzie wesoło.

@Szczery, sesja Vaadin się serializuje (przynajmniej w teorii o ile trzymasz kontrakt Serializable i nie wpychasz do niej nie serializowanych elementów). Raczej spróbowałbym jakoś rozseparować elementy serializowane i nieserializowane i wtedy ocenić czy te drugie są do czegoś przydatne/czy nie da się ich serializować.

1

Podczas poszukiwań też natknełem się na ciekawe rozwiązanie tomcat 7
http://java-monitor.com/forum/showthread.php?t=1288

0

W Tomcacie 6 > http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html

Swoją drogą pytanie czy ten miks co wymieniłeś wcześniej - Vaadni, JSyFy, Wicket to w ramach jednej aplikacji?

0
Szczery napisał(a):

Podczas poszukiwań też natknełem się na ciekawe rozwiązanie tomcat 7
http://java-monitor.com/forum/showthread.php?t=1288

Jeżeli dobrze zrozumiałem, to tomcat ma na raz dwie wersje aplikacji w różnych class loader'ach.
Może to powodować wzrost zapotrzebowania na pamięć.

Niektóre biblioteki mają też błędy (np. związane z ThreadLocal), które skutkują tym, że nie można usuwać z pamięci klas, które były załadowane tym samym class loaderem. W konsekwencji trzeba co pewien czas robić restart serwera.

0

Koziołek:
Nie takiego miksu nie mamy. Zazwyczaj są to osobne projekty..ale przez klienta są widziane jako jeden produkt. Np panel klienta w JSF a panel Amin w Vaadin

__krzysiek85:
Ten parallel deployment w Tomcat to ma tak jak napisałeś podwójny narzut + problemy np mamy cache clustrowalny co automatycznie jak wstaje aplikacja to dodaje się do clustra. A tak naprawdę wstają Od razu wszystkie aplikacje w tomcat tylko jedna z nich "najnowasza" jest bindowana. Podejście takie ma zalezy bo czas przełączenia pobiedzy aplikacjami jest minimalny.

Swoją drogą przydało by się jakieś programistyczne api REST do mod_balancer apache

1 użytkowników online, w tym zalogowanych: 0, gości: 1