Przeniesienie aplikacji ScriptCase na nowy serwer – lista kontrolna

W skrócie: aplikacja ScriptCase działa na nowym serwerze tylko wtedy, gdy zgadzają się trzy rzeczy: wersja PHP z potrzebnymi rozszerzeniami, środowisko produkcyjne ScriptCase w wersji, w której generowano aplikację, oraz połączenie z bazą danych. Przeniesienie trzeba najpierw przetestować na nowym serwerze z kopią bazy, a przełączyć dopiero, gdy najważniejsze procesy działają.

Przeniesienie wygenerowanej aplikacji wydaje się proste: skopiować pliki, skopiować bazę, gotowe. W praktyce często zawodzi przez szczegóły, które kiedyś ustawiono na starym serwerze i o których zapomniano.

Przed przeniesieniem: inwentaryzacja

• Jaka wersja PHP działa na starym serwerze? Wywołanie phpinfo() w pliku testowym pokaże wersję i załadowane rozszerzenia. Plik potem trzeba usunąć.
• W jakiej wersji ScriptCase aplikację ostatnio generowano?
• Jaka baza danych (MySQL, MariaDB, PostgreSQL, SQL Server …) i w jakiej wersji?
• Czy są usługi dodatkowe: zadania cron dla raportów, wysyłka maili, katalogi na wgrywane dokumenty, połączenia z innymi systemami?
• Czy istnieje plik projektu ScriptCase, gdyby trzeba było generować ponownie?

Lista kontrolna dla nowego serwera

1. Wersja PHP

Wersja PHP musi pasować do wersji ScriptCase, w której generowano. Jeśli nowy serwer oferuje tylko nowsze PHP, aplikację trzeba wcześniej wygenerować w aktualnej wersji ScriptCase. Patrz Aplikacja ScriptCase na PHP 8.

2. Rozszerzenia PHP

Rozszerzenia trzeba porównać ze starym serwerem. Zwykle potrzebne są sterowniki bazy (np. mysqli, pdo_mysql, pgsql albo sqlsrv), mbstring, gd, zip, xml, curl i intl. Których dokładnie wymaga Państwa wersja, podaje dokumentacja ScriptCase. Gdy brakuje rozszerzenia, często nie działają tylko pojedyncze funkcje, np. eksport do PDF albo wykresy, a wychodzi to na jaw dopiero po kilku dniach.

3. Ustawienia PHP

• max_input_vars: duże formularze i edycja w siatce wysyłają wiele pól. Przy zbyt małej wartości dane po cichu przepadają.
• upload_max_filesize i post_max_size: dla wgrywania dokumentów.
• memory_limit i max_execution_time: dla dużych raportów i eksportów.
• Strefa czasowa (date.timezone): inaczej znaczniki czasu się nie zgadzają.

4. Środowisko produkcyjne

Wygenerowane aplikacje potrzebują bibliotek środowiska produkcyjnego ScriptCase. Muszą one pasować do wersji ScriptCase, w której generowano. Trzeba je przenieść razem z aplikacjami albo utworzyć na nowo przez deployment w ScriptCase.

5. Połączenie z bazą danych

Dane dostępowe do bazy przy przenosinach prawie zawsze się zmieniają: serwer, użytkownik, hasło, czasem port. Połączenie trzeba dostosować w środowisku produkcyjnym. Warto też sprawdzić kodowanie i porównywanie znaków bazy, inaczej polskie i niemieckie znaki nagle wyświetlą się błędnie.

6. Prawa zapisu

Foldery na pliki tymczasowe, wgrywane pliki i generowane dokumenty muszą być zapisywalne dla serwera WWW. Po kopiowaniu przez FTP uprawnienia często się nie zgadzają.

7. Bezpieczeństwo

• HTTPS z ważnym certyfikatem.
• Obszary administracyjne środowiska produkcyjnego zabezpieczyć silnym hasłem i, jeśli się da, ograniczyć do wybranych adresów IP.
• Wyłączyć wyświetlanie błędów na produkcji.
• Stary serwer wyłączyć dopiero wtedy, gdy nowy co najmniej tydzień działa stabilnie, a potem bezpiecznie usunąć tam dane.

Testy przed przełączeniem

Testować powinny osoby, które codziennie pracują z aplikacją, a nie tylko dział IT. Typowe sprawdzenia: logowanie, dodanie i zmiana rekordu, wyszukiwanie, raport w PDF, eksport do Excela, wgranie dokumentu, wysyłka maila. Dopiero wtedy powtórzyć przeniesienie z aktualną bazą i przełączyć.

Profesjonalna pomoc

Przenoszę aplikacje ScriptCase na nowe serwery, w razie potrzeby generuję je w aktualnej wersji i dbam o to, żeby dzień po przeniesieniu wszyscy mogli normalnie pracować. Więcej w usłudze programista ScriptCase.