Вариант 1 - структура БД (добавление полей, таблиц, процедур) меняется сразу на рабочей базе на сервере, ибо 100-гигабайтные базы копировать себе на компьютер не будешь, а реальные данные для тестов нужны. На девелоперском компьютере пишется новый функционал (файлы), затем грузятся на тестовый сервер (на нём уже конект к реальной базе), там тестируются и если всё ок, то файлы заливаются на продакшен. Можно в простейшем случае и на девелоперском компьютере тестить, если есть удалённый доступ к бд.

Вариант 2 - схема БД (с минимум данных) копируется на девелоперский компьютер, всё на нём же разрабатывается, заливается на тестовый сервер + миграции и тестируется, затем и на реальную бд накатываются миграции (как пример - миграции в doctrine) и заливается проект на продакшен.

Вообще у нас никто не имел права заливать проект на продакшен без одобрения отдела тестирования, поэтому без тестового сервера никак. Все изменения в svn или git, откатиться не проблема.

Вариант 3 - обновление CMS (тестового отдела нет, начальников нет, сам себе хозяин, повисит сайт клиента лишние n-минут - не страшно). На сервере делается дамп базы, копируются файлы проекта в архив, затем в CMS нажимается кнопка обновить и ждёшь чуда. Ошибок нет - прекрасно, есть небольшие - правим тут же, сайт отвалился - накатываем старый дамп и возвращаем файлы. Можно канешь и к себе на комп копировать эту CMS, обновлять, потом обратно на сервер закачивать, но жутко лень. Правка файлов - также напрямую на живом сервере, время экономится.

А реализация обновлялки на чем? Самопис?

Принцип обновления у многих схож - жмёшь на кнопку, идёт запрос к серверу обновлений, оттуда скачивается архив, распаковывается, запускается функция обновления, которая делает бэкап (опционально), накатывает sql-запросы (берёт их список из файла) и перезаписывает необходимые файлы (копирует их из папки обновления в папку с сайтом), затем папка с обновлением стирается. На обычных шаред хостингах открыт только ftp и http, выбор невелик. А построение самой системы обновлений - сравнение двух конкретных редакций CMS, копирование всех изменённых файлов в инсталятор, составление последовательных sql-запросов и т.д. - это уже отдельная тема, надо курить конкурентов (другие CMS), всяко нашли для себя оптимальный метод.

Я почему спрашиваю. Уже как-бы система обновлений была написана 1,5 года назад. Но возникли сложности с разделением — оказывается не только системные модули могут быть, но и разные-всякие, которых у конкретного пользователя нет.
Допустим пользователь удалил модуль «Форум». Значит этого модуля обновлять не нужно.
Когда система была монолитом, все работало. Когда прикрутили удаление модулей — на обновления пришлось забить.


Не подскажете у какой лучше это реализовано? Не хотелось бы «курить» всё подряд.
Последний раз тестировал ЦМС в 2009 г., тогда лучшим по этому параметру Вордпресс был.
Тогда уже ЦМС-ок было около 50-ти. А сейчас их в десятки раз больше.

Круто :sarcastic: lisabak.ru Сайт лисичего настроения

Замечание модератора: Эта тема была закрыта автоматически ввиду отсутствия активности в ней на протяжении 100+ дней. Если Вы считаете ее актуальной и хотите оставить сообщение, то воспользуйтесь кнопкой или обратитесь к любому из модераторов.