Mam taką zagwozdkę jak w temacie. Wdrażamy teraz aplikację dla klienta klasy enterprise i mamy do niej zapewnić wsparcie techniczne, gwarancyjne itd, ale nie możemy mieć dostępu do bazy danych, a dokładniej do wybranych treści oraz dokumentów pdf, które są przez aplikację generowane. Tu jest problem bo czasami trzeba wejść przez konsolę i coś zmodyfikować.
Czy ktoś z Was miał jakieś doświadczenia z wdrażaniem takich rzeczy i może coś podpowiedzieć?
Moja jedna koncepcja jest taka, żeby napisać skrypt, który będzie robił zrzut bazy danych z przefiltrowanymi wybranymi polami. Wtedy moglibyśmy sobie pobrać taki zrzut, zdiagnozować i naprawić problem lokalnie. Jeżeli byłaby konieczna modyfikacja bazy danych prze konsolę, to moglibyśmy wpisać wymagane polecenia do pliku *.rb zamiast w konsoli, a potem uruchomić ten plik na serwerze. To pewnie też byśmy zrobili przez jakiś program uruchomieniowy, coś w stylu bundle exec rake support:load_fix SCRIPT=fix-1.rb.
Użytkownik, na którego będziemy się logować nie będzie miał dostępu do żadnych plików konfiguracyjnych, do bazy danych, do katalogu z generowanymi dokumentami itd., ale będzie mógł uruchamiać te 2 skrypty, do tworzenia zrzutu bazy i załadowania poprawki.
Co myślicie o takim rozwiązaniu?
Druga koncepcja to zastanawiam się czy mysql nie ma czasem opcji ukrycia pewnych kolumn przed użytkownikiem. O tym pomyślałem w tej chwili, więc jeszcze nie sprawdzałem w googlu czy jest to możliwe. Może ktoś wie? Wtedy mógłbym po prostu zrobić innego użytkownika, przez którego wprowadzałbym poprawki do bazy.
Co rozumiemy pod pojęciem wdrażanie aplikacji. Jesteście tylko developerami, czy również administratorami systemu na serwerze gdzie będzie działać aplikacja. Mówiąc prościej komu liczy się SLA, gdy system zrobi kernel panic?
Moim zdaniem najlepiej nie dotykać produkcji. Gdzie kucharek sześć tam nie ma co jeść. Jeśli kilka zespołów jest odpowiedzialnych za jeden serwer to później będzie wojna podczas rozwiązywania wszelkich sporów w temacie kto jest winny awarii. Kto dokonał zmian itp.
Za każdym razem, gdy nie ma się dostępu do pewnych elementów aplikacji pojawia się problem podczas debugowania oraz rozwiązywania wszelkich problemów wydajnościowych. Jeśli z punktu widzenia użytkownika aplikacja będzie działać wolno to pierwsze podejrzenie pada na Was - bo Wy odpowiadacie za aplikację. Jeśli Wy nie będziecie mieć dostępu do bazy danych to znaczy, że jest człowiek w zespole admin.db, który odpowiada za bazy danych. Nigdy nie wiesz, czy po weekendzie taka osoba nie przyjdzie do pracy z głową pełnych pomysłów i nie zacznie tuningować serwera bazodanowego i jego tuning nie spowolni działania Twojej aplikacji. Ty nic nie robiłeś, a tu nagle czasy wynonania zapytań rosną Ci o 200%.
Moim zdaniem najbardziej zdrowy i sprawdzony układ jest taki:
Nie dotykacie się produkcji
Prosicie o środowisko do testów (staging, beta, jak zwał tak zwał). Na tym środowisku wprowadzacie wszelkie zmiany. Na tym środowisku klient testuje i odbiera aplikację.
Klient dostaje instrukcję jak wgrać nową wersję aplikacji na produkcję. Nic nie stoi na przeszkodzie, aby ten proces zautomatyzować - wszystko zależy od wymagań i procedur. Dla przykładu bardzo wiele korporacyjnych aplikacji działa na serwerach, które nie mają dostępu do internetu więc deploy via github, bitbucket itp. nie wchodzi w grę i w takim wypadku sprawdza się stary dobry patch lub tar.gz.
Warto wprowadzić jakieś check-testy na produkcji, aby sprawdzić czy po wgraniu Waszej najnowszej wersji nie spadła znacząco wydajność aplikacji oraz czy krytyczne elementy aplikacji działają zgodnie z wymaganiami.
Zawsze trzeba monitorować serwery oraz aplikacje metodą ilościową tj. zużycie cpu, ram, I/O, network, response time, db query time itp.
Aplikacja musi mieć bardzo dobre logowanie wszystkich błędów.
Jeśli aplikacja wymaga debugu na produkcji z Waszej strony to umawiacie się na support w siedzibie klienta lub zdalnie przez współdzielony pulpit etc.
Jeszcze raz jasno podkreślę, że mówimy tutaj o enterprise.
Jesteśmy developerami i raczej administratorami aplikacji niż systemu. Teoretycznie kernel panic nas nie dotyczy, ale w praktyce pewnie będziemy dostawali takie zgłoszenia jeżeli to wystąpi.
Niestety nie ma takiej opcji, żebyśmy nie dotykali produkcji. Ja zaproponowałem bardzo podobne rozwiązane do Twojego ze środowiskiem testowym, na którym klient by testował wprowadzone zmiany. Niestety nie zgodził się, bo wtedy na niego spada część odpowiedzialności. Dodam, że ta cała kwestia dotyczy wyłącznie naprawiania usterek w działaniu aplikacji, a nie wdrażania nowych funkcjonalności.
Skończyło się na tym, że będziemy mieć dostęp do produkcji. Ale generalnie uważam temat za ciekawy, jak zaprojektować aplikację, żeby ją potem można było rozwijać i naprawiać bez dostępu do przechowywanych danych. Będę drążył na spokojnie
):