Передовые практики промежуточной базы данных

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

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

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

Приветствуются любые общие мысли / советы / опыт.

ОБНОВЛЕНИЕ:

Спасибо за комментарии, я понял суть. Думаю, стоит подумать об этом. Принял популярный ответ.


database production staging
person Tom    schedule 19.05.2010    source источник

Ответы (2)


arrow_upward
39
arrow_downward

Пропуск постановки и внесение изменений в производство - это верный путь к катастрофе и неиспользованию. По мере того, как вы вносите эти изменения, определение второстепенного начинает меняться. Во-вторых, когда две среды уходят (т.е. постановка больше не соответствует производственной), все ломается, и вы теряете уверенность в промежуточной среде. Чтобы получить максимальную отдачу от промежуточного сервера, вы должны выполнять автоматическое развертывание на нем, полностью тестировать и только затем развертывать (автоматически) в производственной среде (независимо от того, насколько незначительно изменение). Вы также должны убедиться, что вся среда максимально похожа, и оставаться такой. Это, очевидно, включает в себя БД. Обычно я настраиваю синхронизацию ежедневно или ежечасно (в зависимости от того, как часто я создаю сайт или приложение) для поддержки БД и часто запускаю ее как часть процесса сборки.

person Steve Robillard    schedule 19.05.2010
comment
+1. Вся цель промежуточной среды - имитировать то, что вот-вот будет запущено в производство. Если в производственной среде есть изменения, которые не отражены в подготовленном вами коде, тогда зачем возиться с промежуточным сервером? - person NotMe; 19.05.2010
comment
Не могли бы вы поделиться идеей, как вы автоматически синхронизируете БД? - person geckob; 21.12.2015
comment
@geckob, это должен быть отдельный вопрос, так как он будет зависеть от конкретной БД, ОС, где вы ее запускаете (виртуальная, в центре обработки данных, в облаке) и т. д. - person Steve Robillard; 22.12.2015
comment
@SteveRobillard - А как насчет затрат? У меня большая производственная база данных, и для ее ежедневной синхронизации и автоматизированных тестов мне нужно иметь такую ​​же большую базу данных для stage, что значительно увеличивает мои ежемесячные расходы. Вы можете предложить обходной путь? - person Akshat Goel; 21.10.2017
comment
@AkshatGoel Вы уже должны оплачивать эту стоимость за счет резервного копирования или запуска набора реплик. Сказав это, вы можете использовать меньший набор данных, однако каждый ярлык, который вы используете, является ошибкой, которую вы не сможете обнаружить до начала производства. Только вы можете найти компромисс между стоимостью и безопасностью. - person Steve Robillard; 21.10.2017

arrow_upward
9
arrow_downward

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

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

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

person John Rasch    schedule 19.05.2010
comment
Я не согласен с тем, что данные не актуальны. В зависимости от системы, производственные данные могут выявить всевозможные непредсказуемые проблемы в вашей промежуточной среде ... В этом своего рода суть :) - person Dolph; 19.05.2010
comment
@Dolph - когда я говорю данные, я имею в виду что-то вроде заказов или сотрудников. Если вы храните конфигурацию любого типа в базе данных, то вы правы в том, что она определенно должна быть идентичной. Однако, если простые данные каким-то образом нарушают работу вашего приложения, это должно было быть обнаружено во время тестирования QA. Конечно, если ваша промежуточная среда и тестовая среда совпадают, то, вероятно, будет хорошей идеей часто обновлять промежуточную базу данных;) - person John Rasch; 19.05.2010
comment
Я бы согласился, в идеальном мире. Но по моему опыту, пользователи реального мира всегда находят способы генерировать данные, которых никто не ожидал. - person Dolph; 19.05.2010
comment
@Dolph: Вы имеете в виду somedomain.com?id=1; СОЗДАТЬ ТАБЛИЦУ unknown_user_data? :) ... Нет, согласен, юзеры - это поток варваров. - person Tom; 19.05.2010
comment
@Dolph Хороший момент в отношении производственных данных может выявить всевозможные непредсказуемые проблемы в вашей промежуточной среде. Существуют команды для преобразования производственных данных в достаточно похожие данные на этапе подготовки (например, анонимность путем изменения всех имен на случайное другое имя, изменение возраста и т. Д.), Чтобы снизить риск утечки данных. - person Tom Anderson; 21.01.2021