Witam wszystkie Kasie i Tomeczków z #programowanie i #bazydanych !
Wiem, że dzisiaj jest już trochę przesyt tematem portalu na W, ale chciałem zacząć trochę poważniejszą dyskusję na gorąco zanim emocje opadną, bo jutro już raczej mi się nie będzie chciało. Wiadomo, że najlepiej uczyć się na cudzych błędach dlatego proponuję pochylić się nad case study (czy może Post Mortem?) tej wczorajszej udanej aktualizacji portalu kojarzonego z rogalami i Poznaniem żeby wypunktować największe grzechy oraz zastanowić się jak można to było zrobić prawilnie. Także zapraszam do zabawy w panów z obrazka poniżej.
To może zacznę:
Wiem, że dzisiaj jest już trochę przesyt tematem portalu na W, ale chciałem zacząć trochę poważniejszą dyskusję na gorąco zanim emocje opadną, bo jutro już raczej mi się nie będzie chciało. Wiadomo, że najlepiej uczyć się na cudzych błędach dlatego proponuję pochylić się nad case study (czy może Post Mortem?) tej wczorajszej udanej aktualizacji portalu kojarzonego z rogalami i Poznaniem żeby wypunktować największe grzechy oraz zastanowić się jak można to było zrobić prawilnie. Także zapraszam do zabawy w panów z obrazka poniżej.
To może zacznę:
-
Testy UI/UX strony w wersji mobilnej. Tyle się mówi o mobile first, etc., a ten portal to przecież nie jest strona w stylu wejdź i zapomnij (typu jakaś wizytówka firmy) tylko portal, na któym właściciel chcę żeby użytkownicy spędzali czas. Sam traktowałem to jako "ten serwis do przeglądania podczas siedzenia na toalecie" i obstawiam z dużą pewnością, że to podsumowuje znaczną część użytkowników. Tymczasem ta aktualizacja to splunięcie takim użytkownikom w twarz. Można się załamać patrząc na te dwie belki u góry i dołu, przyciski w lewym dolnym rogu zasłaniające przyciski i kontent i te marginesy, które pozwalają zobczyć maksymalnie dwa jednolinijkowe komentarze w jednym momencie na moim ekranie.
-
Kto w ogóle wpadł na pomysł żeby ubić całą starą aplikacje, zmigrować bazę i postawić zupełnie nową? Ja rozumiem, ze pewnie tak wyszło dużo taniej i wygodniej bo nie trzeba ciągnąć za sobą legacy, ale to trzeba nie mieć wyobraźni żeby nie pomyśleć że taka droga w jedną stronę to trochę słaba opcja w przypadku większych błędów
-
Kilkugodzinny downtime, prawdopodobnie ze względu na migrację danych. Nikt w tych czasach już chyba tak nie robi w przypadku serwisów działających 24h/7. Nie miałem do czynienia z aż tak dużymi migracjami, najczęściej dotyczyły maksymalnie jednej tabeli ale wydaje mi się że dałoby się to zrobić, wystarczyłoby rozbić migrację na kilka kroków. Jeśli jest jakaś niekompatybilna wstecz zmiana na jednej tabeli to wystarczy zrobić migrację do nowej tabeli i dodać jakiś proces, który będzie automatycznie dodawał wszystkie nowe dane trafiające do starej tabeli również do tej nowej w nowym formacie. Później wypuszczamy apkę czytającą z nowej tablei i gitara, a starą tabelę usuwamy. Jeśli jest jakieś bardziej eleganckie rozwiązanie to chętnie poczytam.
-
Jak oni mogli wgrać starą kopię bazy? A przynajmniej tak się wydaje patrząc po tym, że stare konta zostawały przywaracane itp. Przecież po to był cały ten downtime żeby chyba migrować wszystkie dane, a nie jakiś backup. Aż ciężko mi w to uwierzyć i mam jakąś teorię spiskową, że to może jakiś inny błąd? Coś w stylu zapomnieli podmienić połączenie na produkcyjną bazę i leciały jakieś dane z UATów czy coś. Chociaż nie wiem czy takie coś nie byłoby nawet jeszcze bardziej kompromitujące.
-
Ubicie APIv2 i wszystkich aplikacji, które z niego korzystały bez żadnej komunikacji. Przecież nawet w wersji z ubiciem całego starego kodu można było zrobić jakieś ogłoszenia i ewentualnie parę miesięcy temu wystawić nowe endpointy, które początkowo wołają pod spodem nawet stare API. To nie jest prawilne wersjonowanie i pewnie byłyby problemy z kompatybilnością wstecz, ale lepsze to niż całkowite ubicie.
