Рекомендации по организации промежуточной базы данных
Я собираюсь развернуть в производство довольно сложный сайт и впервые нуждаюсь в промежуточной среде, где я могу тестировать вещи в более реалистичной среде, особенно в отношении некоторых внешних служб, которые не могут быть запущены локально.
Мой общий план состоит в том, чтобы сначала разработать и протестировать локально, протолкнуть простые изменения (небольшие исправления ошибок, HTML/CSS, JS и т. д.) непосредственно в производство, а для более крупных изменений-сначала в промежуточный поддомен для тщательного тестирования, а затем в производство.
Я не думаю, что мне нужно синхронизировать промежуточную и производственную базы данных (иногда достаточно ручного обновления), но мне интересно, есть ли какие-либо общие рекомендации по обслуживанию промежуточной среды по отношению к производственной среде, особенно когда речь заходит о базах данных.
Любые общие мысли/советы/опыт будут оценены.
Обновление:
Спасибо за комментарии, я понял суть. Думаю, оно того стоит. потребовалось некоторое время, чтобы подумать об этом. Принял популярный ответ.
2 ответа:
Обход постановки и внесение изменений в производство-это рецепт катастрофы и неиспользования. По мере того, как вы вносите эти изменения, определение minor начинает меняться. Во-вторых, когда две среды расходятся (т. е. постановка больше не соответствует производству), все ломается, и вы теряете уверенность в промежуточной среде. Чтобы получить максимальную отдачу от промежуточного сервера, вы должны выполнять автоматическое развертывание на нем, полностью протестировать и только затем развернуть (автоматизировать) в производство (независимо от того, насколько незначительны изменения). Вы также должны убедиться, что вся окружающая среда максимально похожа, и оставаться таким образом. Это, очевидно, включает в себя БД. Обычно я настраиваю синхронизацию ежедневно или ежечасно (в зависимости от того, как часто я создаю сайт или приложение) для поддержания БД и часто запускаю ее как часть процесса сборки.
Как человек, разрабатывающий программное обеспечение инструмент, который помогает на каждом этапе процесса развертывания, я могу сказать, что наилучшей практикой, когда речь заходит о промежуточных средах, является точное отражение вашей производственной среды . Это включает в себя идентичную схему базы данных (данные не актуальны, иногда резервное копирование/обновление нормально), ту же версию операционной системы, обновленные пакеты обновления, настройки веб-сервера и т. д.
В идеальном мире функциональное или пользовательское тестирование это не обязательно делать в промежуточной среде, поскольку цель промежуточной среды заключается только в тестировании развертывания в рабочей среде. Однако в практическом мире иногда допустимо, чтобы промежуточная среда также была вашей функциональной средой или средой тестирования UA.
Каждый раз, когда вы изменяете настройку или изменяете конфигурацию на рабочем сервере, вы должны изменить настройку на промежуточном сервере, это гарантирует, что если вы можете развернуть свое приложение на промежуточном сервере, то оно будет, с большим вероятность, развернуть в производство без ошибок.