Лучшая практика для просмотра данных в реальном времени на сервере разработки? - PullRequest
3 голосов
/ 07 ноября 2008

Предположение: живое / производственное веб-приложение подавляет ошибки, отображаемые конечным пользователям.

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

В настоящее время у нас есть одна база данных, обслуживающая как dev, так и live box (не моя идея - я знаю, что это брутто).

Идеи

Редактировать : Лучшие / удобные инструменты для реализации вашего предложения?

Ответы [ 6 ]

5 голосов
/ 07 ноября 2008

Мы копируем данные обратно в другую базу данных. Да, есть задержка, но она не дает людям работать с производственными серверами. Это также позволяет нам «скрывать» информацию, которую техническая поддержка (и другие люди в этом отношении) не должны видеть.

2 голосов
/ 07 ноября 2008

Резервное копирование и восстановление из live в dev на регулярной основе (один раз, два раза в день). Это не обязательно должно быть в реальном времени (так как в любом случае вы можете вводить данные со стороны разработчика, что может вызвать проблемы).

Если у вас есть данные PCI или HIPAA, убедитесь, что вы не включили их в свою среду разработки - это может нарушить законы.

2 голосов
/ 07 ноября 2008

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

1 голос
/ 07 ноября 2008

Мне, как правило, нравится иметь трехуровневую систему для веб-разработки:

Разработка Тестирование
Живите

Большую часть времени тестирование является точной копией действующей системы, за исключением того, что ошибки включаются, когда новая версия собирается переноситься в живую, она заменяется новой версией ПЕРЕД включенной версией для обнаружения проблем с обновлением.

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

0 голосов
/ 07 ноября 2008

Если ваша конфигурация позволяет это:

а. Добавьте функцию ведения журнала (если ее еще нет) для записи интересующих сообщений в файл журнала.

б. Запустите команду Unix

tail -f

, который будет передавать растущий файл журнала на вашу консоль.

http://www.monkey.org/cgi-bin/man2html?tail

Если у вас Windows, вы можете попробовать это:

http://tailforwin32.sourceforge.net/

0 голосов
/ 07 ноября 2008

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

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

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

...