Чи погано розвиватися на тлі виробничих даних?

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

Але тривалий час я працював безпосередньо з виробничими даними з мінімальними головними болями, за винятком, можливо, декількох помилок, що повзуть тут чи там, такі речі, як проблеми з написанням, неправильний текст alt, посилання, що вказують на неправильне місце. Це, мабуть, пов’язано з відсутністю експертної оцінки з мого боку, а не через роботу з прямими даними.

То чому ж розвивається на живому сайті така погана практика?

Якщо під час розробки ви запускаєте команди SQL, що включають INSERTабо UPDATEна існуючих таблицях баз даних, ви ризикуєте в тій мірі, в якій ці таблиці баз даних є критично важливими.

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

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

Я б звернувся до свого адміністратора бази даних у таких випадках, якщо немає "офіційного" DBA, я б помилявся з боку обережності. Досить просто створити базу даних про розробку навіть для себе. Для команди це життєво важливо. Якщо цього ви не наполегливо хотіли б використовувати лише одну базу даних, ви можете DEV_встановити таблиці своїх баз даних розробок і почувати себе трохи краще. Так, для цього потрібні певні зміни коду, але в розробці додавання змінних під час розробки $debug = trueтощо, як правило, варто докласти зусиль.

Дуже багато способів наблизитись до цього. Це дуже залежить від вашої ситуації.

Ви НЕ хочете розвиватися на основі виробничих даних на виробничому сервері. Існує пара величезних причин.

1. Розробка уповільнює виробничу коробку і створює вразливості. Що станеться, якщо залишити комп’ютер розблокованим і піти подалі?
2. Якщо ви помилитесь, люди, які відвідують ваш сайт, можуть бачити це.
3. Якщо ви робите будь-який тип оновлення даних у Транзакції у вашій базі даних, і ви не здійснюєте її негайно або транзакція потребує певного часу, ви закінчите, ви поставите блокування на всі задіяні таблиці, і ви можете спричинити час очікування .
4. Деякі системи баз даних, зокрема SQL Server, робитимуть блокування таблиці часом лише для операторів SELECT! Це означає, що ви можете ненавмисно давати людям тайм-аути або сторінки помилок на вашому сайті.

Я б ніколи не займався розробкою роботи в прямому ефірі, якщо це можливо. Найкраще робити резервну копію Бази даних та сторінок та працювати з копією, а потім натискати свої оновлення. Одним із інструментів, який допоміг мені тонну, є SyncToy Msft.

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

Якщо ви не їдете без ременя безпеки, не розробляйте виробничі дані. Просто питання безпеки.

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

А для розвитку на основі даних про виробництво в реальному часі - пам’ятайте закони Мерфі «Все, що може піти не так, піде не так», і так легко зробити невелику помилку з великими поганими наслідками.