Как стать автором
Обновить

Комментарии 22

У нас было так:

Заводится 3 версии портала: DEV, INT и LIVE. Плюс иногда возникает необходимость добавить дополнительные промежуточные версии.

Разработчики работают со своей локальной и с общей DEV версиями портала непосредственно. При этом каждый из них составляет свой кумулятивный скрипт обновления общих ресурсов (например SQL скрипт изменений в БД).

Когда очередной этап разаработки подходит к концу, на INT заливается все из LIVE и начинаются попытки применить скрипты обновлений на него (с первого раза конечно никогда не работает правильно). После доработки скриптов обновления и прохода получившегося портала через бетатестеров, на INT опять переливается все с LIVE и проводится "генеральная репетиция" применения обновлений.

Если все прошло гладко, обновления производятся на LIVE.
Хорошо поставлено.

Самая муторная часть в этом всем — это те самые кумулятивные скрипты. Писать их очень напрягает (меня, по крайней мере, — ну не люблю я DDLщину), вечно что-то да забудешь. Я уже пару месяцев размышляю о том, в каком виде я хотел бы иметь средство, облегчающее миграцию схемы БД. Пока до дао и просветления далеко, но в RoR есть интересные идеи.
"Но не весь контент хранится в базе, часто CMS контент статических страниц хранят в .php файлах"

Представление от логики отделять нужно, иначе на выходе неизменнно получается винегрет из html и php. Smarty вам в руки, для примера.
Не хотелось бы в данном примере привязываться к конкретной реализации самой CMS.
в нашей CMS в файле контента включается header.php и footer.php, а между ними только контент, так что всё отделено.
Контент в php - ошибка проектирования. У нас весь контент в базе. Рабочая база реплицируется два раза в сутки на тестовую. Изменения структуры БД только на тестовой базе небольшими порциями. Если все работает - порция изменений переносится на основную базу.
а если контент вводится редакторами, которые не находятся в одном месте?
так и есть, контент вводится редакторами, которые находятся в разных местах
но вводится в одну базу - главную. по этому нет зависимости от того, на каком сервере крутится php-скрипт (даже в рамках одной сессии).
Контент в php - ошибка проектирования

Но, например, в том же битриксе контент хранится именно в пхп. И там всё сделано довольно-таки удачно и удобно
ага. На нем и пишем. :)
Не хочу спорить об очевидных вещах, но php - интерпретируемый язык, изначально не предназначенный быть оптимальным хранилищем данных. Не работал в битриксе, но думаю, что вряд ли сколь-нибудь серьезная задача работы с данными, включающая поддержку транзакций, журналируемости, обеспечения целостности, оптимизацию индексов и проч..

Конент в php возможен только в случае простейшей структуры типа конфигурационного файла, линейного списка небольшой величины.
Думаю, если тут слово "контент" заменить на слово "кэш", то все должно стать предельно понятно. Тут произошла ненамеренная подмена понятий, вызвавшая целую ветку споров, не относящихся к теме.
Не особо доверяю людям, которые говорят фразы типа "Библию не читал, но думаю, что Моисей не прав...".

Если не работали в битриксе, то ниже пример php файла с контентом:


<? require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");
$APPLICATION->SetTitle("О компании");?>
<div class="content">
CONTENT COMES HERE!!!
</div>
<?require($_SERVER["DOCUMENT_ROOT"]."/bitrix/footer.php");?>


И в чём тут неправильное использование php?
Это точно файл, хранящий контент, а не кеш, данные для которого берутся из БД?
файл хранит контент, но создаётся автоматом из админки.
При изменении админка в базе обновляет поисковый индекс страницы.
Всё нормально. Это файловый кэш.
не важно в каком формате храниться контент, хоть в БД, хоть в текстовых файлах храни да и в пхп скриптах можно, не суть важно, главное разделить данные и их представление с обработкой. А дальше все просто: когда билд готов, заливается на пустой сервер, туда заливаются данные с того что сейчас в обороте и теститим и правим, как только получили рабочую вещь, меняем местами рабочий сервер и этот кател для готовки.....
Не всегда это возможно.
Я же говорю, что не в коде проблема.
Контент вводят разные люди, со многими из которых нет связи в принципе,
но у них свои статические страницы. Что-то типа SaaS
Мне показалось, что вопрос звучит следующим образом: "У нас нет организованного процесса разработки и каждый делает,что хочет. Но как сделать так, чтобы при этом у нас все было хорошо ?" IMXO никакой SVN, когда так ведут разработку, не поможет. Есть разработчики, есть процессы, есть инструменты, и нельзя пытаться подменить одно другим. Насколько я понял, кто-то меняет скрипты, за которые отвечает ваша команда. Нужно добиться, чтобы этого без согласования с вами не делали. Не все в жизни решается программами - иногда надо пойти наорать на оппонентов. Да, это неприятно, но иногда необходимо. Если у вас есть PM, поручите это ему - это как раз его работа.
показалось.
У меня была такая проблема. Решал так вставлял вокруг изменяемых частей уникальные идентификаторы (guid):

<!-- Ldfcpn8Vop6xCJr2wNWi --&gt

...
CHANGED PART HERE
...

<!-- Ldfcpn8Vop6xCJr2wNWi --&gt

guid позволяют однозначно сопоставить старую и новую версию страницы.
...А я все равно за старое ! Расскажу, как я бы это улаживал с контент-райтерами. Я как раз совмещаю часть обязанностей менеджера проекта. Я бы пришел к нему и сказал - слушай, ты отличный парень, как и я. Пойдем выпьем отличного (вписать правильное, но в моем случае натурального кофе с кунжутом и шоколадом). Мы пишем с стобой отличный сайт, и он станет еще лучше, если ты будешь писать свой отличный контент не сразу на наш отличный сайт, а сначала в наш отличный репозиторий....
Делаем две версии проекта. Для разрабочиков можно в зоне .org купить домен и сделать дуступ только по определённым ip адресам (или доступ только из студии).
Конечно же целесообразно использования SVN.
А так ничего сложного. Разработали, оттестили на резервной копии - залили на публичную версию. Потестили.

Лучшая на мой взляд комбинация это ООП PHP + PostrgeSQL(MySQL)+ Smarty - очень удобно, можно добавлять, изменять, всё очень мобильно.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории