bio_bot, Живем так уже 6 лет. Первое время при merge на prod делали снимки на уровне vmware. Потом поднакопили опыт и сейчас проблем нет. Stage решает, без него граблей было бы больше.
bio_bot, У меня такой же вопрос давно висит. В данный момент у нас такая схема:
Есть два сервера 1-(dev,stage) и 2-prod. Есть локальный gitlab с настроенными хуками.
Разработчик пилит dev, пушит на gitab и делает запрос на слияние с stage, QA заходит на gitlab делает review и подтверждает merge, далее уже сам gitlab делает poll на stage, если все ок, то делают merge в прод в gitlab.
То есть у нас 3 сайта
dev.domain.com
st.domain.com
domain.com
Если надо обновить архитектуру базы, то разраб делает db_update.sql файлик c нужными правками и добавляет его в комит. На stage и dev есть пост скрипты которые контролят наличия файла db_update.sql в комите и накатывают обновление на базу, так же этот пост скрипт делает снимок текущей базы для возможности отката.
В будущем есть идея на этапе stage замутить скрипт, который будет тянуть с prod свежую базу, накатывать на нее изменения из db_update.sql запускать в докер.
Может есть лучший вариант)
Вопрос более приземленный, как синхронизировать изменения в ДБ при разработке. Новый модуль-плагин может требовать новые атрибуты или таблицы, соответственно как правильно организовать синхронизацию базы прод и дев.
Рома Алексеев, В обычных условия не покидает, но можно настроить PIM если надо)
Что бы в тебя не бросались какашками сторожилы форума, надо приходить с более подготовленным вопросом. А так, твой вопрос похож на человека который даже статью на wiki не удосужился прочитать.
> nslookup 100.64.0.1 100.64.0.1
Логично, что 100.64.0.1 знает свое доменное имя, но откуда 100.64.0.10 должен знать про pfSense.lan.vitko-core.ru? Что бы это работало, надо либо на 100.64.0.10 прописать эту запись, или прописать домена-NS на котором должна резолвиться эта запись или указать 100.64.0.1 на 100.64.0.10 как сервер пересылки.