Разве плохо развиваться на фоне производственных данных?

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

Но долгое время я работал непосредственно с производственными данными с минимальными головными болями, за исключением, может быть, нескольких ошибок, появляющихся здесь или там, таких как проблемы с орфографией, плохой альтернативный текст, ссылки, указывающие на неправильное местоположение. Похоже, это связано с отсутствием экспертной оценки с моей стороны, а не из-за работы с живыми данными.

Так почему разработка на живом сайте такой плохой практики?

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

В некоторых местах производственные данные синхронизируются с базой данных разработки с определенным интервалом, скажем, раз в неделю или по запросу разработчика, чтобы у вас были свежие данные для разработки.

Но если ваши производственные данные не подвержены риску от того, что вы делаете, например, если вы просто разрабатывали представление некоторых данных, обычно это не имеет большого значения. Теперь, если вы запускаете отчеты, которые выполняют сканирование таблиц, тогда у вас есть возможность заблокировать таблицу, и ваши существующие пользователи будут затронуты.

Я бы посоветовался с моим администратором базы данных в таких случаях, если бы не было «официального» администратора баз данных, я бы ошибся из-за осторожности. Достаточно просто создать базу данных для разработки, даже для себя. В команде это жизненно важно. В противном случае, если бы вы настаивали на том, чтобы использовать только одну базу данных, вы могли бы добавить к своим таблицам базы данных разработки префикс DEV_и чувствовать себя немного лучше. Да, это требует некоторых изменений кода, но при разработке добавление некоторых переменных во время разработки $debug = trueи т. Д. Обычно стоит усилий.

Много способов подойти к этому. Это очень зависит от вашей ситуации.

Вы НЕ хотите разрабатывать на основе производственных данных на своем производственном сервере. Есть пара огромных причин.

1. Разработка замедляет вашу производственную коробку и создает уязвимости. Что произойдет, если вы оставите свой компьютер разблокированным и уйдете?
2. Если вы совершите ошибку, люди, которые посещают ваш сайт, смогут это увидеть.
3. Если вы выполняете какое-либо обновление данных внутри транзакции в своей базе данных и не фиксируете ее немедленно, или транзакция занимает некоторое время, чтобы завершить, вы установите блокировку для всех задействованных таблиц, и вы можете вызвать тайм-аут ,
4. Некоторые системы баз данных, в частности, SQL Server, время от времени делают блокировки таблиц только с помощью операторов SELECT! Это означает, что вы можете непреднамеренно сообщать людям о времени ожидания или страницах ошибок на вашем сайте.

Я бы никогда не стал заниматься разработкой живого бокса, если это возможно. Лучше всего сделать резервную копию базы данных и страниц и поработать с копией, а затем отправить свои обновления. Один инструмент, который мне очень помог, - это SyncToy от Msft.

Ну, вы можете действительно испортить данные. Представьте, что вы оставили пункт «где». Даже если у вас есть почасовые резервные копии, это было бы трудно исправить.

Если вы не ездите без ремня безопасности, не разрабатывайте производственные данные. Просто проблема безопасности.

Если у вас есть производственные данные, разумно использовать их для тестирования, но использовать отдельную базу данных тестирования с копией этих данных. В противном случае многие вещи будут работать для ваших немногих «блабла» тестовых записей, но не для реального сценария.

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