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

    Не все сайты делаются студией и после отдаются заказчику.

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

    Тут и без бинокля видно, что неплохо бы использовать для хранения php и html кода репозиторий.

    Но как это сделать правильней?
    С дизайнерами и программистами все достаточно просто, они разрабатывают код на локальных машинах и изменения вносят в репозиторий. Можно даже настроить cron, чтобы периодически последние изменения из репозитория выкладывались на online сайт.

    Но как быть с контентом?
    Контент меняется только на online версии, чтобы не усложнять дело синхронизацией данных из разных БД. Но не весь контент хранится в базе, часто CMS контент статических страниц хранят в .php файлах, из-за чего появляются новые файлы и изменения, которые приходится периодически с «online» переносить в репозиторий, и делать это вручную во избежание конфликтов версий.

    Интересно, кто сталкивался и как решал подобные задачи.
    Поделиться публикацией

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

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

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

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

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

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

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

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

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

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

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

                          <!-- Ldfcpn8Vop6xCJr2wNWi -->

                          ...
                          CHANGED PART HERE
                          ...

                          <!-- Ldfcpn8Vop6xCJr2wNWi -->

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

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

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое