Комментарии 22
У нас было так:
Заводится 3 версии портала: DEV, INT и LIVE. Плюс иногда возникает необходимость добавить дополнительные промежуточные версии.
Разработчики работают со своей локальной и с общей DEV версиями портала непосредственно. При этом каждый из них составляет свой кумулятивный скрипт обновления общих ресурсов (например SQL скрипт изменений в БД).
Когда очередной этап разаработки подходит к концу, на INT заливается все из LIVE и начинаются попытки применить скрипты обновлений на него (с первого раза конечно никогда не работает правильно). После доработки скриптов обновления и прохода получившегося портала через бетатестеров, на INT опять переливается все с LIVE и проводится "генеральная репетиция" применения обновлений.
Если все прошло гладко, обновления производятся на LIVE.
Заводится 3 версии портала: DEV, INT и LIVE. Плюс иногда возникает необходимость добавить дополнительные промежуточные версии.
Разработчики работают со своей локальной и с общей DEV версиями портала непосредственно. При этом каждый из них составляет свой кумулятивный скрипт обновления общих ресурсов (например SQL скрипт изменений в БД).
Когда очередной этап разаработки подходит к концу, на INT заливается все из LIVE и начинаются попытки применить скрипты обновлений на него (с первого раза конечно никогда не работает правильно). После доработки скриптов обновления и прохода получившегося портала через бетатестеров, на INT опять переливается все с LIVE и проводится "генеральная репетиция" применения обновлений.
Если все прошло гладко, обновления производятся на LIVE.
+1
Хорошо поставлено.
Самая муторная часть в этом всем это те самые кумулятивные скрипты. Писать их очень напрягает (меня, по крайней мере, ну не люблю я DDLщину), вечно что-то да забудешь. Я уже пару месяцев размышляю о том, в каком виде я хотел бы иметь средство, облегчающее миграцию схемы БД. Пока до дао и просветления далеко, но в RoR есть интересные идеи.
Самая муторная часть в этом всем это те самые кумулятивные скрипты. Писать их очень напрягает (меня, по крайней мере, ну не люблю я DDLщину), вечно что-то да забудешь. Я уже пару месяцев размышляю о том, в каком виде я хотел бы иметь средство, облегчающее миграцию схемы БД. Пока до дао и просветления далеко, но в RoR есть интересные идеи.
0
"Но не весь контент хранится в базе, часто CMS контент статических страниц хранят в .php файлах"
Представление от логики отделять нужно, иначе на выходе неизменнно получается винегрет из html и php. Smarty вам в руки, для примера.
Представление от логики отделять нужно, иначе на выходе неизменнно получается винегрет из html и php. Smarty вам в руки, для примера.
+1
Контент в php - ошибка проектирования. У нас весь контент в базе. Рабочая база реплицируется два раза в сутки на тестовую. Изменения структуры БД только на тестовой базе небольшими порциями. Если все работает - порция изменений переносится на основную базу.
0
а если контент вводится редакторами, которые не находятся в одном месте?
0
Контент в php - ошибка проектирования
Но, например, в том же битриксе контент хранится именно в пхп. И там всё сделано довольно-таки удачно и удобно
0
ага. На нем и пишем. :)
0
Не хочу спорить об очевидных вещах, но php - интерпретируемый язык, изначально не предназначенный быть оптимальным хранилищем данных. Не работал в битриксе, но думаю, что вряд ли сколь-нибудь серьезная задача работы с данными, включающая поддержку транзакций, журналируемости, обеспечения целостности, оптимизацию индексов и проч..
Конент в php возможен только в случае простейшей структуры типа конфигурационного файла, линейного списка небольшой величины.
Конент в php возможен только в случае простейшей структуры типа конфигурационного файла, линейного списка небольшой величины.
-1
Думаю, если тут слово "контент" заменить на слово "кэш", то все должно стать предельно понятно. Тут произошла ненамеренная подмена понятий, вызвавшая целую ветку споров, не относящихся к теме.
0
Не особо доверяю людям, которые говорят фразы типа "Библию не читал, но думаю, что Моисей не прав...".
Если не работали в битриксе, то ниже пример 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?
+1
не важно в каком формате храниться контент, хоть в БД, хоть в текстовых файлах храни да и в пхп скриптах можно, не суть важно, главное разделить данные и их представление с обработкой. А дальше все просто: когда билд готов, заливается на пустой сервер, туда заливаются данные с того что сейчас в обороте и теститим и правим, как только получили рабочую вещь, меняем местами рабочий сервер и этот кател для готовки.....
0
Мне показалось, что вопрос звучит следующим образом: "У нас нет организованного процесса разработки и каждый делает,что хочет. Но как сделать так, чтобы при этом у нас все было хорошо ?" IMXO никакой SVN, когда так ведут разработку, не поможет. Есть разработчики, есть процессы, есть инструменты, и нельзя пытаться подменить одно другим. Насколько я понял, кто-то меняет скрипты, за которые отвечает ваша команда. Нужно добиться, чтобы этого без согласования с вами не делали. Не все в жизни решается программами - иногда надо пойти наорать на оппонентов. Да, это неприятно, но иногда необходимо. Если у вас есть PM, поручите это ему - это как раз его работа.
-2
У меня была такая проблема. Решал так вставлял вокруг изменяемых частей уникальные идентификаторы (guid):
<!-- Ldfcpn8Vop6xCJr2wNWi -->
...
CHANGED PART HERE
...
<!-- Ldfcpn8Vop6xCJr2wNWi -->
guid позволяют однозначно сопоставить старую и новую версию страницы.
...А я все равно за старое ! Расскажу, как я бы это улаживал с контент-райтерами. Я как раз совмещаю часть обязанностей менеджера проекта. Я бы пришел к нему и сказал - слушай, ты отличный парень, как и я. Пойдем выпьем отличного (вписать правильное, но в моем случае натурального кофе с кунжутом и шоколадом). Мы пишем с стобой отличный сайт, и он станет еще лучше, если ты будешь писать свой отличный контент не сразу на наш отличный сайт, а сначала в наш отличный репозиторий....
<!-- Ldfcpn8Vop6xCJr2wNWi -->
...
CHANGED PART HERE
...
<!-- Ldfcpn8Vop6xCJr2wNWi -->
guid позволяют однозначно сопоставить старую и новую версию страницы.
...А я все равно за старое ! Расскажу, как я бы это улаживал с контент-райтерами. Я как раз совмещаю часть обязанностей менеджера проекта. Я бы пришел к нему и сказал - слушай, ты отличный парень, как и я. Пойдем выпьем отличного (вписать правильное, но в моем случае натурального кофе с кунжутом и шоколадом). Мы пишем с стобой отличный сайт, и он станет еще лучше, если ты будешь писать свой отличный контент не сразу на наш отличный сайт, а сначала в наш отличный репозиторий....
0
Делаем две версии проекта. Для разрабочиков можно в зоне .org купить домен и сделать дуступ только по определённым ip адресам (или доступ только из студии).
Конечно же целесообразно использования SVN.
А так ничего сложного. Разработали, оттестили на резервной копии - залили на публичную версию. Потестили.
Лучшая на мой взляд комбинация это ООП PHP + PostrgeSQL(MySQL)+ Smarty - очень удобно, можно добавлять, изменять, всё очень мобильно.
Конечно же целесообразно использования SVN.
А так ничего сложного. Разработали, оттестили на резервной копии - залили на публичную версию. Потестили.
Лучшая на мой взляд комбинация это ООП PHP + PostrgeSQL(MySQL)+ Smarty - очень удобно, можно добавлять, изменять, всё очень мобильно.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Коллективная работа над сайтом