ne0d1n5 мая 2008 в 11:43

Коллективная работа над сайтом

1 мин

2.7K

Веб-разработка *

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

lucky4me 5 мая 2008 в 12:20

http://www.pbell.com/index.cfm/2008/2/27…

paladin 5 мая 2008 в 13:05

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

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

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

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

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

ostapbender 5 мая 2008 в 15:51

Хорошо поставлено.

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

chill84 5 мая 2008 в 13:05

"Но не весь контент хранится в базе, часто CMS контент статических страниц хранят в .php файлах"

Представление от логики отделять нужно, иначе на выходе неизменнно получается винегрет из html и php. Smarty вам в руки, для примера.

ne0d1n 5 мая 2008 в 14:32

Не хотелось бы в данном примере привязываться к конкретной реализации самой CMS.
в нашей CMS в файле контента включается header.php и footer.php, а между ними только контент, так что всё отделено.

1602 5 мая 2008 в 14:16

Контент в php - ошибка проектирования. У нас весь контент в базе. Рабочая база реплицируется два раза в сутки на тестовую. Изменения структуры БД только на тестовой базе небольшими порциями. Если все работает - порция изменений переносится на основную базу.

ne0d1n 5 мая 2008 в 14:34

а если контент вводится редакторами, которые не находятся в одном месте?

1602 6 мая 2008 в 05:42

так и есть, контент вводится редакторами, которые находятся в разных местах
но вводится в одну базу - главную. по этому нет зависимости от того, на каком сервере крутится php-скрипт (даже в рамках одной сессии).

unnamed777 5 мая 2008 в 15:38

Контент в php - ошибка проектирования

Но, например, в том же битриксе контент хранится именно в пхп. И там всё сделано довольно-таки удачно и удобно

ne0d1n 5 мая 2008 в 16:05

ага. На нем и пишем. :)

1602 6 мая 2008 в 05:46

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

Конент в php возможен только в случае простейшей структуры типа конфигурационного файла, линейного списка небольшой величины.

paladin 6 мая 2008 в 06:20

Думаю, если тут слово "контент" заменить на слово "кэш", то все должно стать предельно понятно. Тут произошла ненамеренная подмена понятий, вызвавшая целую ветку споров, не относящихся к теме.

ne0d1n 6 мая 2008 в 06:25

Не особо доверяю людям, которые говорят фразы типа "Библию не читал, но думаю, что Моисей не прав...".

Если не работали в битриксе, то ниже пример 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?

Sannis 6 мая 2008 в 08:05

Это точно файл, хранящий контент, а не кеш, данные для которого берутся из БД?

ne0d1n 6 мая 2008 в 08:13

файл хранит контент, но создаётся автоматом из админки.
При изменении админка в базе обновляет поисковый индекс страницы.

1602 6 мая 2008 в 10:19

Всё нормально. Это файловый кэш.

Daedmen 5 мая 2008 в 15:16

не важно в каком формате храниться контент, хоть в БД, хоть в текстовых файлах храни да и в пхп скриптах можно, не суть важно, главное разделить данные и их представление с обработкой. А дальше все просто: когда билд готов, заливается на пустой сервер, туда заливаются данные с того что сейчас в обороте и теститим и правим, как только получили рабочую вещь, меняем местами рабочий сервер и этот кател для готовки.....

ne0d1n 5 мая 2008 в 16:09

Не всегда это возможно.
Я же говорю, что не в коде проблема.
Контент вводят разные люди, со многими из которых нет связи в принципе,
но у них свои статические страницы. Что-то типа SaaS

Nulldevice 5 мая 2008 в 21:07

Мне показалось, что вопрос звучит следующим образом: "У нас нет организованного процесса разработки и каждый делает,что хочет. Но как сделать так, чтобы при этом у нас все было хорошо ?" IMXO никакой SVN, когда так ведут разработку, не поможет. Есть разработчики, есть процессы, есть инструменты, и нельзя пытаться подменить одно другим. Насколько я понял, кто-то меняет скрипты, за которые отвечает ваша команда. Нужно добиться, чтобы этого без согласования с вами не делали. Не все в жизни решается программами - иногда надо пойти наорать на оппонентов. Да, это неприятно, но иногда необходимо. Если у вас есть PM, поручите это ему - это как раз его работа.

ne0d1n 6 мая 2008 в 05:52

показалось.

Nulldevice 6 мая 2008 в 22:14

У меня была такая проблема. Решал так вставлял вокруг изменяемых частей уникальные идентификаторы (guid):



...
CHANGED PART HERE
...



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

mrTempl 7 мая 2008 в 08:17

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

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий