Migracja systemu na nowy serwer lub przywrócenie go z backupu

1. Wgraj pliki do katalogu web root. 

Najlepiej rozpakować pliki bezpośrednio na serwerze, dzięki temu będą zachowane oryginalne uprawnienia na plikach.

2. Wgraj bazę danych.

Bazę danych wgrywamy za pomocą konsoli CLI (zalecane) lub klienta bazodanowego np. DBeaver,  Database Workbench , SQLyog

mysql -P 3306 -h 127.0.0.1  -u crm -p crm < dump.sql

3. Aktualizacja plików konfiguracyjnych.

Po wgraniu plików i zaimportowaniu bazy danych zaktualizuj następujące pliki:

• config/Main.php

/** Backslash is required at the end of URL */
public static $site_URL = 'https://example.yetiforce.cloud/';

• config/Db.php

/** Gets the database server */
public static $db_server = 'localhost';
/** Gets the database port */
public static $db_port = '3306';
/** Gets the database user name */
public static $db_username = 'root';
/** Gets the database password */
public static $db_password = '';
/** Gets the database name */
public static $db_name = 'yetiforce';

Warto też sprawdzić czy niedozwolone domeny do pobierania i linkowania nie uległy zmianie:

• config/Security.php

/** Restricted domains */
public static $EMAIL_FIELD_RESTRICTED_DOMAINS_VALUES = ['yetiforce.com','github.com'];

Sprawdź czy jest włączone wymuszone HTTPS, jeśli na starym serwerze był HTTPS i włączone przekierowanie a nowy serwer nie ma aktywnego HTTPS, to moga się pojawić problemy.

• config/Security.php

/** Force site access to always occur under SSL (https) for selected areas. You will not be able to access selected areas under non-ssl. Note, you must have SSL enabled on your server to utilise this option. */
public static $forceHttpsRedirection = false;

Jeśli na serwerze mamy dostępny katalog dla kopii zapasowej, to możemy go włączyć:

• config/Components/Backup.php

/** Backup catalog path. */
public static $BACKUP_PATH = '';

4. Zweryfikuj czy konfiguracja zgadza się z wymaganiami. 

Zawsze po przeniesieniu systemu na nowy serwer, przywróceniu z backupu lub aktualizacji serwera LAMP uruchom weryfikację konfiguracji serwera zgodnie z wymaganiami z wbudowanego narzędzia do weryfikacji konfiguracji (Serwer - konfiguracja) lub artykułu "Wymagania dla serwera WWW".

Jeśli serwer nie spełnia wymogów, nie należy z niego korzystać, ponieważ może to powodować utratę danych. Jeśli jakieś parametry widnieją na żółto lub czerwono, to należy je poprawić. 

Ważnym jest również to, aby właścicielem plików był ten sam użytkownik na którym działa serwer www (apache, nginx).

5. CRON

Uruchom i zweryfikuj działanie CRON-a

6. Zarejestruj ponownie system

Przeniesienie na nowy serwer lub przywrócenie z backupu wymaga ponownej rejestracji systemu.

7. Aktaulizacja dodatków

Niektóre dodatki mogą wymagać ponownej konfiguracji podczas zmiany lokalizacji lub adresu CRM.

7.1 YetiForce Outlook Integration Panel

Wymaga ponownej reinstalacji i zainstalowania nowego pliku XML.
Stary dodatek zainstalowany w Outlook należy usunąć, pobrać nowy plik XML z panelu CRM zgodnie z instrukcją.

8. Tworzenie środowiska testowego

Jeżeli tworzymy środowisko testowe warto jest wprowadzić kilka istotnych zmian które pomogą nam w rozróżnieniu i bezpieczeństwie środowisk.

8.1 Zmienić hasła użytkowników 

8.2 Wizualne odróżnienie środowisk

Warto jest dodać komunikat o tym że jest to środowiska testowe, można to zrobić na stronie logowania oraz na górnej belce systemu CRM.

Od wersji 6.2.0 dostępna jest możliwość aby w pliku konfiguracyjnym config\Main.php ustawić dodatkowe komunikaty informacyjne.

https://doc.yetiforce.com/code/classes/Config-Main.html#property_loginPageAlertMessage

/** Header alert message */
public static $headerAlertMessage = '';
/** Header alert type, ex. alert-primary, alert-danger, alert-warning, alert-info */
public static $headerAlertType = '';
/** Header alert icon, ex.  fas fa-exclamation-triangle, fas fa-exclamation-circle, fas fa-exclamation, far fa-question-circle, fas fa-info-circle */
public static $headerAlertIcon = '';
/** Login page alert message */
public static $loginPageAlertMessage = '';
/** Login page alert type, ex. alert-primary, alert-danger, alert-warning, alert-info */
public static $loginPageAlertType = '';
/** Login page alert icon, ex.  fas fa-exclamation-triangle, fas fa-exclamation-circle, fas fa-exclamation, far fa-question-circle, fas fa-info-circle */
public static $loginPageAlertIcon = '';

8.3 Zmienić nazwę nazawcy w SMTP lub wyłączyć zadanie CRON-a wysyłające maile

Wiadomości wysyłane z nowego środowiska będą wyglądały identycznie jak z produkcyjnego, dlatego warto wyłączyć lub zmienić nazwy nadawców w SMTP aby umieć odróżnić wiadomości mailowe.

Panel: Konfiguracja systemu > Automatyzacja > CRON

Dokumentacja: CRON

8.4 Zmienić klucze API

Warto zmienić dane dostępowe do API, aby były inne na każdym z środowisk. Aby przypadkiem ktoś mając dostęp do wersji testowej nie próbował uzyskać danych z wersji produkcyjnej.

Panel: Konfiguracja systemu  > Integracja > Web service - Aplikacje

Uwagi:

W celu prawidłowego przeniesienia systemu CRM na inny serwer należy zrobić pełną kopię systemu (pliki i baza danych). Najlepiej spakować programem do kompresji danych np.

zip -r `date +"%Y%m%d_%H%M"`.zip __CRM_PATH__ -q

tar -zcvf /var/www/html/`date +"%Y%m%d_%H%M"`.tar.gz /var/www/html/

Podczas przenoszenia lub przywracania systemu nie może wystąpić żaden błąd, ponieważ później może okazać sie, że baza jest niekompletna.