Грамотний порядок роботи на чужому хостинзі

Чужий хостинг — це зло. Це чужа територія, де на девелопера чекає купа факапів та претензій. Цей матеріал присвячений тому як звести можливі претензії до мінімуму.

Найбільш паранормальний випадок, який зі мною траплявся — це коли на сервері дивом зберігся кеш робочої версії сторінок проекту, оригінальні файли при цьому були діряві з тонною помилок. Коли в них спробували внести доповнення, кеш оновився… Це були чи не найстресовіші 3 години за весь час роботи.

Проте більшість негараздів куди буденніші і їх доволі легко уникнути.

Хостинг з багатьма сайтами

Просимо доступ лише до того сайту, з яким працюємо в конкретний момент. Часто замовникам банально лінь подбати про роздільне харчування, але девелопер має вибити собі татуювання з цим правилом і показувати татуху клієнту по вебці.

Для чого — маючи доступ до інших сайтів Ви можете теоретично щось не туди залити. Навіть, якщо ви все робите акуратно і Ваш кіт не топчеться по клавіатурі, щось не те може зробити замовник, який може цього не помітити — і тоді він вже знатиме, що Ви могли щось не туди залити…

Витираємо ноги

Ніколи не зберігаємо дані нам паролі в браузері або файлменеджері. Це елементарна гігієна девелопера не лише на чужій території, але й загалом.

Перед редагуванням файлу чи директорії робимо дві копії: собі на комп, а згодом перейменовану копію на сервері — в новій назві можна відзначати дату редагування.

Тотальні бекапи

Після отримання доступу, але до початку реальної роботи, робимо загальну копію файлів та Бази даних. Цю копію даємо клієнту, а також залишаємо собі — клієнти такі ж люди і їм також властива віра в те, що все вийде добре саме собою.

UPD і так, трекери файлів штибу Git — наше всьо. Це звісно, якщо витрачений час на танці з установкою виправдовують себе.

DEBUG mode

Запускаємо цей режим. У вордпресі він знаходиться в кореневому файлі wp-config.php, просто замінюємо false на true:

define('WP_DEBUG', false);

Скрінимо вже наявні помилки, показуємо замовнику, а також відкладаємо собі. Це на випадок, якщо ваші оновлення могли б конфліктувати із вже наявними кодами. А також для того, щоб замовник бачив реальну картинку.

Попри те, що при більшості помилок сайт може спокійно працювати довгий час, Вам краще ставити клієнта до відома, а також фіксити за собою неполадки.

API платформи

Розширення функціоналу краще вести з допомогою розробницьких засобів самої системи. Часто простіше написати пару функцій на чистій мові, проте це може вилізти боком в майбутньому, при масштабуванні системи.

Перелік засторог не є довгим, а його дотримання вимагає часових затрат лише на початку — потім ці засоби входять у звичку і попри те, що Ви не надаєте їм значення, вони продовжують рятувати Вас від довгих годин дурної роботи.

Залишити відповідь