Существует ли надлежащее место для базы данных подготовки?
Для коротких кодов нет, вероятно, никакого различия. Это особенно верно, поскольку таблица, содержащая эти коды, вероятно, будет очень маленькой (пара тысячи строк самое большее) и не изменяться часто (когда будет прошлый раз, когда мы добавили новый штат США).
Для больших таблиц с более широким изменением среди ключа, это может быть опасно. Думайте об использовании почтового адреса/имени пользователя от таблицы User, например. Что происходит, когда у Вас есть несколько миллионов пользователей, и у некоторых из тех пользователей есть длинные имена или адреса электронной почты. Теперь любое время, необходимо присоединиться к этой таблице с помощью того ключа, это становится намного более дорогим.
7 ответов
В моей книге промежуточная среда должна быть независимой, потому что она позволяет вам отрепетировать процедуры развертывания нового выпуска. Если вы находитесь на одном компьютере или на той же виртуальной машине, вы не получаете «полного» опыта обновления библиотек и т. П.
Лично мне нравятся виртуальные машины, потому что я могу вернуть производство на этап, а затем обновить его. Это означает, что мое обновление очень реалистично, потому что все данные крайнего случая, библиотеки и тому подобное воспроизводятся. Это хорошо ... Я не могу сосчитать, сколько раз за 9-летнюю историю нашего основного продукта не было включено библиотечный модуль или какой-либо скрипт обновления для крайних случаев попадания в базу данных, которые не были обнаружены в среды разработки и тестирования.
Что касается производственной среды ... Я бы сказал никогда не делать этого, если есть альтернатива. Обновите общую библиотеку в стадии подготовки, которая также влияет на производство, и вы почувствуете боль. Обновите код, и ваш веб-сервер перейдет в тупик, и вы вывели из строя (по крайней мере часть) свою рабочую среду.
Если вам нужно подделать это, я бы рекомендовал поделиться со средами разработки и просто понять, что обновление production make вызывает непредвиденный простой во время обновления, поскольку вы проверяете, что все работает. Нам приходилось делать это в течение первых нескольких лет по причинам бюджета, и это может работать, если вы не просто обновляете производство и не уходите.
В итоге
- Производство священно: не делитесь ничем, кроме производственные аспекты, если вы можете этого избежать.
- Виртуальные машины - ваши друзья: они позволяют клонировать рабочие среды и обновлять их с почти нулевым риском (просто скопируйте файл виртуальной машины при любых неудачных попытках обновления).
- Промежуточная база данных должна быть изолирована от разработки, чтобы избежать излишней уверенности в своей программе обновления.
В идеале вы хотели бы иметь отдельную промежуточную среду, которая отражает вашу живую среду, но фактически не существует в ней. Однако $$$ не всегда позволяет это, поэтому идеал не всегда соблюдается.
Это включает (но не ограничивается) следующее:
- Веб-серверы
- Серверы баз данных
- Серверы приложений
И все, что находится на этих машинах (физических или виртуальных), должно быть изолировано в соответствующих средах, поэтому вы не должны видеть промежуточный код на производственном сервере, и точно так же вы не должны видеть промежуточную базу данных в производственной базе данных. сервер. Они должны быть отдельными.
Кроме того, если вы используете большую внутреннюю полосу пропускания, вы можете даже изолировать сети,
Какое бы решение вы ни выбрали в конце, я бы сказал: оставьте свой рабочий сервер для производства и только для производства!
Если вы добавите на него непроизводственные ресурсы, появится риск ошибок, конечно, как вы сказали ... Но есть также риск ошибок: что, если ваше приложение сойдет с ума и, например, использует весь ЦП сервера? От этого может пострадать ваше производство.
И это, конечно, только пример; -)
На мой взгляд, лучшим решением было бы иметь другой сервер для постановки, с максимально приближенной настройкой (настоящий «клон "было бы лучше всего) к производственной установке.
Учитывая, что это может стоить довольно много для машины, используемой всего несколькими тестерами, это часто не так возможно :-( Я видел альтернативу, чтобы используйте виртуальную машину (размещенную на вашем сервере разработки, а не на рабочем сервере) : она действует как «настоящая» машина, на которой вы можете делать все, что захотите, без влияния на eiter prod или dev.
И, при необходимости, вы можете использовать несколько виртуальных машин, если необходимо, чтобы они были максимально приближены к вашим производственным настройкам.
Промежуточная БД никогда не должна находиться на одном сервере с производственной. Я бы сказал, что это нормально, если он находится на том же сервере, что и ваш сервер разработки.
Есть ряд вещей, которые могут пойти не так,
Манипулирование данными в неправильной БД
Делать что-то, что могло бы
сбей сервер. Вам может потребоваться
, чтобы перезагрузить сервер БД во время разработка и тестирование.
Как правило, я не думаю, что разработчики должны иметь доступ к живой среде. Только операции должны иметь доступ.
Как говорили другие, следует избегать сохранения непроизводственных объектов в производственной среде, как чумы. У разработчиков слишком много возможностей по ошибке добавить или изменить что-то, от чего зависит ваша производственная среда. Наш рабочий сервер изменяется только во время развертывания. Мы отслеживаем каждый файл, который был изменен, и располагаем механизмом для отката изменений с минимальными усилиями.
Если у вас нет выделенного оборудования, продолжайте делать это в своей среде разработки.
Если у вас нет специального оборудования для разработки, подготовки и производства, то размещение промежуточной базы данных на сервере SQL для разработки является распространенным решением. Я
это гораздо безопаснее, чем иметь промежуточную базу данных на производственном сервере, пытаться что-то сделать с промежуточной базой данных и отключать производственный SQL-сервер.
Наличие промежуточной базы данных на рабочем сервере рискованно. однако при достаточно напряженных этапах отладки / тестирования реальный риск для производства минимален. Это особенно верно, если нагрузка на постановку минимальна.
реальный риск для производства минимален. Это особенно верно, если нагрузка на постановку минимальна. реальный риск для производства минимален. Это особенно верно, если нагрузка на постановку минимальна.