Как вы CM приложение с управляемым контентом
У нас есть веб-приложение, которое содержит множество контента, который может изменять системный оператор (например, новости и события). Время от времени мы публикуем новые версии программного обеспечения. Программное обеспечение помечается и хранится в системе Subversion. Тем не менее, я немного не уверен, как лучше контролировать версии контента, который может быть изменен независимо. Какие механизмы используют люди, чтобы гарантировать, что контент хранится и контролируется версиями таким образом, чтобы сайт можно было воссоздать или, по крайней мере, контролировать версии?
Ответы 3
Храните все в БД и присваивайте каждой транзакции в БД метку времени. таким образом вы можете хранить стандартные резервные копии БД и загружать контент сайта в любую дату, если произойдет худшее.
Когда вы определяете два набора файлов, которые имеют свой собственный жизненный цикл (файлы программного обеспечения с одной стороны, «новости и события» с другой, вы знаете, что:
- вы не можете версировать их вместе одновременно
- вы не должны ставить ту же этикетку
Вам необходимо сохранить файлы «новостей и событий» по отдельности (либо в VCS, либо в базе данных, как предлагает Ян Джейкобс, либо в CMS - системе управления контентом), и найти способ связать буксирное соединение вместе (идентификатор, отметка времени, мета-метка, ...)
Не забывайте, что вы говорите не только о двух разных наборах файлов с точки зрения жизненного цикла, но также о разных наборах файлов с точки зрения самой их природы:
Рассмотрим терминологию, введенную в этом вопросе SO "Является ли управление активами надмножеством системы контроля версий" С.Лотт
- программные файлы: Информация об инфраструктуре, что «представляет обработку информационного актива предприятия». Ваш код является частью этого актива и управляется VCS (системой контроля версий) в рамках дисциплины управления конфигурацией.
- «новости и события»: Информация о предприятии, то есть данные (не обрабатываются); это часто делится между менеджерами контента и реляционными базами данных.
Так что не все должно попадать в Subversion.
Я полагаю, что часть ответа зависит от того, какую CMS вы используете и как разработано ваше веб-приложение, но в целом я бы рассматривал такие данные, как новости или события, как «контент». Другими словами, это не часть вашего приложения - это данные, которые ваше приложение обрабатывает.
Конечно, между вашим кодом CMS и кодом вашего приложения будут возникать проблемы с версией. Вы можете справиться с этим, определив интерфейс между ними. Лично я бы опубликовал данные в веб-приложении как XML, что дает вам возможность использовать схему XML для точного определения того, что CMS требуется для создания и что веб-приложение должно ожидать от обработки.
Это должно означать, что большинство изменений в веб-приложении могут быть внесены без соответствующего изменения в рендеринге данных. Когда этого требуют изменения функциональности, вы можете создать новую версию схемы и продолжить работу. В этом сценарии я бы проверил схему с кодом веб-приложения, но YMMV.
Это непросто и снова усложняется, если вам нужны дополнительные поля данных в вашей CMS. Ожидайте, что вы спланируете довольно сложный процесс выпуска (также в зависимости от того, насколько сложен ваш сценарий Dev-Test-Acceptance-Production.)
Если вы не используете CMS, вам следует подумать об этом. (Конечно, если операция очень мала, она все равно может попасть в категорию, где допустимо выполнение ее вручную.) Простое помещение необработанных данных в систему управления версиями не решает проблему - вам нужно иметь возможность контролировать формат, в котором ваши данные публикуются в веб-приложении. Почти наверняка этот формат должен быть предназначен для использования программным обеспечением и поэтому обычно не подходит для ручного редактирования людьми, которые пишут новости или события.