Wątek przeniesiony 2017-08-18 16:23 z Nietuzinkowe tematy przez somekind.

Wprowadzanie nowych wersji oprogramowania

0

Cześć. Nie wiem, czy dobrze umieściłem temat ale nie widziałem nic innego. Otóż chciałbym dowiedzieć się czegoś na temat (i może później zrealizować) sposobów w jakie odbywa się przełączanie aplikacji stabilnych i odwrotnie (jeśli w ogóle się to robi). Dla ustalenia uwagi przypuśćmy, że mam aplikację webową uruchomioną na wildfly i korzysta ona z bazy danych MySQL. Wypuszczam teraz nową wersje (testową) i chciałbym, żeby w razie problemów była możliwość przełączenia się na wersje poprzednią (stabilną). O ile zmiane wersji można wyobrazić sobie jak zwykłą podmianę wara to co w przypadku jak zmienia się środowisko (wersja mysql czy wildfly) - jak wtedy zrealizować takie przełączanie? Myślałem nad maszynami wirtualnymi. Tzn każda maszyna to jedna instacja oprogramowania - jeśli się wywróci (jak sprawdzić?) to odpalam maszynę z wersją stabilną. Problem też jeśli zmienia się schemat bazy danych (w ogóle czy w takim przypadku powinna być wspólna?). Jakby ktoś mógł coś opowiedź coś o tym temacie to byłbym wdzięczny albo chociaz podać jakieś materiały.

0

Raczej nikt w poważnym oprogramowaniu nie wprowadza testowej wersji od razu na produkcję. Zazwyczaj ma się co najmniej 2 serwery - produkcyjny i testowy. Testowy najlepiej żeby odzwierciedlał produkcję czyli miał taki sam soft, bazę itd. Oczywiście baza testowa i produkcyjna to dwie osobne instancje.
Jak jest potrzeba szybkiego wycofania zmian z produkcji (np. umowy zakładające maksymalny czas interwencji) to można mieć 2 serwery produkcyjne pomiędzy którymi da się szybko przełączyć (coś w stylu load balancer'a) i zawsze deployować nową wersję najpierw na jeden, a dopiero po ustabilizowaniu wszystkiego na drugi.
Takie podejście wymaga oczywiście żeby baza była gotowa na pracę z obiema wersjami, czyli np. miała nullowalne pola albo nieusuwane od razu w nowej wersji kolumny.

Oczywiście sposobów wprowadzania nowej wersji może być więcej, ale z mniej więcej takim się spotkałem i działał.

0

można np korzystać z dockera i jenkinsa. Kopia produkcji po zaktualizowaniu do nowej wersji i sprawdzeniu czy nie ma problemów poprzez testy w aplikacji przełącza się jako stabilna a druga się wyłącza i jeszcze sobie jakiś czas czeka uśpiona.

0

No o to mi właśnie chodzi. Mamy 2 wersje (produkcyjną i testową). "Włączona" jest testowa, a w razie czego jest możliwość przełączenia na produkcyjną. Tylko właśnie chciałbym wiedzieć trochę dokładniej, tzn jak fizycznie wyglądają te 2 instancje, czy są to oddzielne maszyny wirtualne, obrazy dockera? I jak wtedy wykrywać, że jedna nie działa i przełączać się na inną? Są do tego dedykowane narzędzia? Dodatkowo sytuacja z bazą. Najlepiej chyba na wersji testowej mieć kopię produkcji, tylko co przypadku jęsli np. wersja testowa działa parę dni po czym okaże się, że jest jakiś błąd i trzeba się przełączyć na wersję stabilną ze starą wersją bazy (co z danymi zapisanymi w trakcie działania wersji testowej)?

0

wszystkiego nie przewidzisz, jak masz buga później to robisz hotfixy i tyle

0
  1. Co do bazy to backup i tyle.
  2. Co do samej aplikacji to bez sensu. Albo twoja aplikacja jest gotowa aby pójść na produkcję albo nie. To co planujesz zrobic to proszenie się o fuckup nie do odwrócenia.
0

Najlepiej mieć continous deployment i wrzucać każdą zmianę oddzielnie, wtedy ryzyko wybuchu jest mniejsze. A już zupełnie zerowe przy blue-green deployment, bo w razie czego przełączasz po prostu na loadbalancerze na serwer z poprzednią wersją, i nawet nie ma przestoju.

0

O, to podejście blue-green to coś czego szukałem.

  1. Tylko tak, samo przełączanie odbywa się automatycznie? (jeśli tak to jak wykrywane są błędy)
  2. Co z bazą? Jeśli jest oddzielna w blue i green, a następuje przełączenie to dane są "z d**y"?
  3. Jeśli rozpatrywalibyśmy jednego klienta, to te 2 wersje aplikacji lepiej żeby były oddzielnymi maszynami wirtualymi, czy skorzystanie dockera?
  4. Czy są do tego przeznaczone jakieś gotowe narzędzia?
2
  1. Pewno da się zrobić automatycznie, np. jeśli wzrośnie liczba błędów/sekundę w jakimś narzędziu monitorującym typu NewRelic, Stackify czy inne APM.
  2. Raczej nie może być oddzielna.
  3. Ja stawiam na oddzielnych serwerach. Nie znam możliwości dockera w tym zakresie.
  4. O ile wiem, to np. Octopus Deploy wspiera to podejście. Jeśli masz chmurę, to takie narzędzia też powinny być dostępne (AWS i Azure przynajmniej też mają).
0

U nas dwie osobne instalacje test i prod. Przed wypuszczeniem nowej wersji kopiujemy baze prod na test i wgrywamy wersje gdzie użytkownicy sobie mogę testować!!! Jak jest oki to wchodzi na prod

Nie da się w prosty sposób ogarnąć tego tak jakbyś chciał ze wersja test i prod korzystają z tej samej bazy, wyobraż sobie ze nowa wersje wprowadza refaktor tabel....
chyba, że korzystać z NoSQL wtedy tam sytuacja jest trochę lepsza bo struktury nie są tak statyczne i można wprowadzić np wersje rekordów

0

@Szczery: oddzielenie test od prod jest oczywiste. :) Pytanie dotyczyło o tę samą bazę dla blue i green, czyli obu wersji produkcyjnych.

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