Методология разработки на 1С-Битрикс – опыт дурака

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

    Далее опишу основные проблемы, с которыми пришлось столкнуться в этом, и нескольких похожих, проектах, апробированные мною решения и результаты работ.

    Исходные данные:


    • Есть интернет-магазин на 1С-Битрикс
    • Проекту несколько лет, но только несколько месяцев назад сайт перевели на 1С-Битрикс
    • Посещаемость 10-15 тыс. человек в день
    • Каталог магазина содержит около 12 000 позиций товаров
    • Простои и отключения сайта недопустимы
    • Проект в течении полугода разрабатывался другой компанией:
      1. Есть ТЗ, примерно на 100 листов, соответствующее выполненной работе примерно на 40%
      2. Никакой документации проекта
      3. Отсутствие понимания, почему предыдущие разработчики использовали именно такие архитектурные решения.


    Разработкой программного обеспечения в целом, и web-проектов в частности, занимаюсь около 8 лет. За это время сталкивался с проектами различной сложности и, на первый взгляд, задаче не показалась мне слишком трудной. При выполнении проектов в нашей компании, как правило, применяется методология SCRUM. От нее я и начал отталкиваться.

    Первым делом, получил доступ исходному коду проекта. Поверхностно проанализировал. Согласовал с заказчиком список первостепенных задач. Составил план разработки для 3х разработчиков и, как сказал Гагарин, поехали!

    Проблема №1 – во всем виноваты разработчики


    Как это обычно и бывает, во всем виноваты все, кроме заказчика. Дизайнер сделал макет, который слишком много весит, хостер предоставил сервер, который медленно работает, разработчики сделали сайт, который все время глючит и ломается, менеджеры выполнили какие-то задачи, которые мы выполнять не просили, после перехода со старой версии сайта на 1С-Битрикс произошло резкое снижение поискового трафика и т.д. Ситуация не однозначная. С одной стороны основная ответственность конечно же должна лежать на компании разработчике. Нужно было донести до заказчика последствия всех действий с сайтом и подготовить к результату. При выполнении работы предложить целостную архитектуру будущей системы и план разработки, которого нужно придерживаться до завершения основных этапов. Провести тщательное тестирование функционала и сдать работу. С другой стороны, не редко сталкиваюсь с ситуацией, когда заказчик все сам лучше знает, потому что у него мама когда-то рисовала, а посему является лучшим дизайнером, и его 7ми летний сын прекрасно разбирается в SEO-оптимизации, потому что все время проводит за компьютером, играя в GTA.

    Кто виноват, кто прав судить не нам. В данном случае, предыдущим подрядчиком была достаточно известная надежная компания и ничего плохого об их разработке сказать не могу. Да и заказчик, объективно, переживает за свой продукт и старается его улучшить. Как оно было не знаю, для себя я нашел объяснение в недостаточном количестве аналитики предоставленной исполнителем заказчику.

    В результате:
    • Проект не доведен до логического завершения. Многие задачи брошены на середине пути
    • Проект не задокументирован. Работа части функционала не очевидна. При разработке нового функционала оказывается, что перестал работать функционал, который раньше работал и о существовании которого новый разработчик и не подозревал
    • Часть написанного предыдущим исполнителем кода приходится переписывать с нуля
    • Задуманная архитектура проекта в первые недели/месяца работы новому подрядчику не ясна. Доработка функционала одного модуля приводит к потере работоспособности функционала никак не связанного с ним модуля
    • Заказчик нервничает, исполнитель нервничает, посетители не довольны, посещаемость уменьшается, продажи падают


    Решение проблему вижу только одно: постепенно планомерно вычищать все модули сайта по очереди для доведения продукта до требуемого состояния. Какие-то ошибки были вынесены в отдельные задачи и выполнены немедленно, что-то удалось поправить параллельно с разработкой нового функционала. Результат — с каждым апдейтом, после оперативного вычищения вылезших багов, сайт становится все лучше и стабильнее.

    Проблема №2 – параллельная разработка.


    В соответствии с лицензионной политикой 1С-Битрикс, каждая лицензия на сайт позволяет использовать 2 копии системы. Одну, как продакшен сайт, вторую – для разработки. Проблема заключается в том, что разработка ведется несколькими, в моем случае, тремя, разработчиками непрерывно. В случае с классической разработкой все просто. Каждый разработчик занимается своим модулем. Затем проводится функциональное тестирование каждого модуля, все доработки сливаются в репозиторий какой-нибудь системы контроля версий, дальше это тестируется все вместе (интеграционное тестирование). Если результат нормальный –тестовая версия презентуется заказчику. После принятия тестовой версии происходит обновление продакшен-сервера. В соответствии с методологией SCRUM я определил, чтоб буду выкладывать новые версии на боевой сайт раз в неделю. Соответственно, есть 3-4 дня на основную разработку. 1 день на тестирование и исправление ошибок и пол дня на обновление боевого сервера. Сроки конечно колеблются, но правила «релиз каждый четверг» старался четко придерживаться.

    Первое с чем столкнулся, в 1С-Битрикс есть ситуации, в которых один и тот же файл одновременно задействован в разном функционале в разных концах сайта. Самое простое и очевидное решение – использовать систему контроля версий, в моем случае, SVN, которым пользуюсь во всех остальных проектах. Но для использования контроля версий необходимо, чтоб у каждого разработчика была своя собственная версия кода, которую он правит и затем сливает общий репозиторий.

    Как же быть с лицензией? Обратился в техническую поддержку 1С-Битрикс. Получил предложение докупить доп. лицензии для разработки. Мягко сказать, не обрадовался, но других предложений не получил. Выход нашел достаточно быстро. Решил использовать NFR-ключи. Благо, партнерский статус позволяет. В результате создал 5 исталяций интернет-магазина:
    • Продакшен-сервер
    • Тестовый сервер
    • 3 сервера разработки (по одному на разработчика)


    Со временем пошел еще дальше. Появилась еще отдельная инсталляция для тестера. Оказалось, что с моим везением заказчик всегда заходит на тестовый сервер в момент, когда там что-то обновляется. В багтреке возникает много лишних задач, которые уже и так выполнены, а у заказчика возникает впечатление, что мы плохо делаем свою работу.

    Сейчас использую следующую схему:
    • Каждый разработчик использует для работы только свою локальную копию
    • В оговоренное время все завершенные доработки сливаются в общую ветку в репозитории
    • QA забирает себе «смердженную» версию для тестирования
    • После тестирования и исправления ошибок происходит обновление демонстрационного сервера для заказчика
    • После проверки и акцепта заказчиком, доработки переносятся на боевой сервер.


    Из очевидных минусов такого подхода хочу выделить низкий уровень вовлеченности заказчика в разработку. Результат виден заказчику уже только на финальной стадии. Такой подход применим если у вас есть хороший аналитик, который редко ошибается и находится в постоянно контакте с заказчиком. Иначе, многие задачи придется переделывать с нуля.

    По мере построения схемы столкнулся с еще одной проблемой. Проект занимает на диске около 80Гб. Без кеша и временных файлов – около 60. Пытался по началу убрать картинки и видео из контроля версий – не получилось. Информация на сайте меняется постоянно. Тестировать нужно на актуальных данных. Первый комит сайта в репозиторий у меня шел кусками более 2х суток. Первый чекаут в папку для разработки проходит несколько часов (SVN сервер в локальной сети разработки). Если, не дай бог, случайно сделать полный апдейт папки проекта – можно уходить курить, обедать, играть в пинг-понг или керлинг. Комит только выбранных файлов или папок проходит достаточно быстро. Решение: выполнил задачу – закомить сразу десяток измененных файлов.

    Проблема №3 – обновление продакшен-сервера и совместная работа с заказчиком


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

    Тут отлично работают законы Мерфи:
    • Если что-то плохо работает на тестовом сервере – на боевом сервере это обязательно сломается.
    • Если что-то отлично работает на тестовом сервере – на боевом сервере это все равно обязательно сломается.
    • Если баг на сайте существует всего 5 секунд, его обязательно найдет кто-то из посетителей и обязательно напишет об этом в отзывах или в форме обратной связи.
    • Если сайт не работает 1 минуту во время обновления, то именно в эту минуту владелец компании будет показывать его своему другу или конкуренту (и это не смотря на согласование времени и процедуры обновления).

    Я, конечно, утрирую, но в каждой шутке есть доля шутки. Минимальная нагрузка на сайт с 4 до 6 утра. Обновлять в это время конечно бы лучше, но уж очень не хочется.

    В случае большинства веб-приложений есть четкая структура разделения приложения на слои и обновление сайта можно разделить на 2 части:
    • Обновление программного кода
    • Обновление базы данных с помощью SQL-скриптов


    В случае с 1С-Битрикс все немного сложнее. Во-первых, файлов много. У меня в проекте их более миллиона. Обычный апдейт из репозитория проходит никак не меньше 20-30 минут. Можно конечно апдейтить только измененный файлы, но тогда теряется весь смысл репозитория. Во-вторых, и это куда более печально, часто при апдейте приходится делать ручные изменения и настройки через админку. А это всегда медленно, нужно помнить все изменения, которые необходимо выполнить, велика вероятность случайно ошибиться. Можно, конечно, написать SQL скрипт, который сам внесет все нужные изменения в базу. В простейших случаях, разумеется, так и делаем. Но в большинстве случаев написание и отладка такого скрипта занимает больше времени чем сама разработка и намного больше времени, чем выполнение всех действий вручную с последующей проверкой.

    Хорошего решения проблемы пока не нашел. Сейчас обновляем настройки в базе вручную. Для минимизации ошибок составляется чек-лист со списком что нужно сделать при апдейте. Обновление стараемся производить максимально внимательно и аккуратно. После обновления всей командой проверяем основной функционал продакшен сервера и проводим дополнительное тестирование. Количество ошибок минимизировано, но полностью от багов и простоев при обновлении избавиться пока не получилось.

    Второе, с чем столкнулся, это совместная работа с заказчиком. Т.к. проект большой, над ним постоянно трудится около 30 человек. Контент-менеджеры, менеджеры по продажам, SEO-оптимизаторы, маркетологи и много еще кого. Естественно, каждый вносит в страницы сайта и настройку модулей какие-то изменения. Первым решением было забрать права у заказчика на внесение изменений в программный код сайта. Решение абсолютно правильно, но стало только хуже. Если раньше заказчик предполагал, что он так же может зайти на сайт и случайно что-то сломать, то теперь все шишки стали сыпаться только на нас. При чем. Даже если контент-менеджер криво отредактировал текст на странице и не закрыл какой-то тег – все равно виноват разработчик. Решение нашлось довольно простое. В маркетплейсе есть бесплатны модуль по контролю версий страниц. Проблему это не убрало, все равно кто-нибудь время от времени что-то да наплужит, но зато теперь появилась возможность посмотреть в любой момент времени кто менял, что менял и почему все сломалось. Результат, конечно, не ice, но кучу нервов мне экономит.

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

    Проблема №4 – «сделайте мне срочно, это же задача на 5 минут»


    Проблема относится не столько к 1С-Битрикс, сколько к доработке и поддержке работающих проектов. Часто у заказчика возникает желание сделать какую-то мелочь, но срочно и сразу на боевом сайте. Результат всегда один – ничего хорошего из этого не выходит. В лучшем случае, об этой доработке просто забудут при очередном релизе, в худшем – сервер просто упадет и его придется несколько часов восстанавливать из бекапа.

    Решение нашел только одно – никогда не идти на поводу у заказчика в ущерб надежности и безопасности. Как бы заказчик не просил, виноват всегда будет разработчик. Как говорил мне мой бывший начальник: «Я же тебя не просил сделать плохо».

    И раз уж затронули тему бекапов, хочу заметить. Бекап средствами 1С-Битрик это конечно хорошо и удобно, но очень медленно. В случае, если срочно нужно восстановить 1-2 файла или несколько значений в базе, приходится ждать пока разархивируются все 60 Гб. Здесь наиболее эффективной мне кажется следующая схема:
    • Должен происходить ежесуточный бекап файлов и базы данных в виде архива на внешний источник данных.
    • Всегда делаем бекап непосредственно перед обновлением в одном из 2х вариантов:
      1. Вариант light – Копируем всю папку проекта в соседнюю папку на сервере. Базу данных в виде дампа сохраняем в отдельный файл. Ничего не архивируем. В случае, если нужно будет восстановить какое-то значение в базе или один из файлов, все будет под рукой и легкодоступно
      2. Вариант strong – аналогично предыдущему, только базу копируем в другую базу данных MySQL. Это позволит в случае полного краха за 1-2 минуты исправить в файле хостов корневую папку сайта и проект начнет работать из соседней папки с копией базы.


    Заключение


    Спасибо всем, кто дочитал до конца. Надеюсь, мой опыт будет вам полезен. Буду рад предложениям по более удачным способам решения озвученных проблем в комментариях или в личку. Сейчас я постарался озвучить основные проблемы доработки и поддержки уже запущенных проектов с высокими требованиями к надежности. Если материал окажется интересным, планирую написать продолжение об особенностях архитектуры 1С-Битрикс, которые отличают разработку сайта на Битриксе от разработки других веб-проектов.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 38
    • +16
      Проблема №0 — 1С Битрикс. Я все понимаю, ко всему отношусь лояльно, но для работы просто невозможная система, код просто ужас — ни документации, ни единого codestyle.
      • +7
        С точки зрения разработчика, наверное, да. С точки зрения бизнеса — позволяет сравнительно не дорого решить большой класс задач. Многие интернет-магазины не смогут позволить себе написать всю движок с нуля.
        • 0
          Мне кажется что со своей ценовой политикой, Битрикс не самое выгодное средство для магазина. Чтобы сделать магазин на Битриксе, надо покупать редакцию «Малый бизнес», которая стоит почти 25 тыс. руб. К этому ещё нужно добавить оплату за специалиста, который сделает этот магазин на Битриксе, т.к. человек далёкий от программирования просто-напросто не осилит Битрикс. В итоге получаются достаточно большие растраты.
          • +6
            Хороший интернет-магазин на 1С-Битрикс, как правило, стоит от 300 000 и выше. Один только дизайн сайта обойдется в сотню. При таких масштабах проекта стоимость лицензии как-то теряется.
            • 0
              Битрикс — решение для стандартных сайтов- интернет-витрин. Все, что более 300тыс. -это полноценные e-commerce проекты — интернет-магазины в полном понимании этого слова. Делать на Битриксе имеет смысл, если есть опытная команда, которая уже проходила эту историю. Если команды нет, то лучше делать с нуля, прописывая архитектуру и выбирая подходящий фреймворк.
              • 0
                Если бы мы жили в мире стандартизованным, то было бы супер. а так как каждый в бизнесе выдумывает свои схемы, то проблема.
                Для типовых магазинов есть решения на порядки дешевле.
              • 0
                Любой инет магазин стоит столько.
            • +1
              В данном конкретном случае даже с точки зрения бизнеса сомнительно.
              Магазин с 12 тысячами товаров и примерно таким же количеством посетителей.
              Над проектом трудится больше 30 человек, в коде сайта больше миллиона файлов, ТЗ на 100 страниц.
              Из 100 страниц ТЗ явно следует что от чистого битрикса при таком раскладе там осталось не так много.
              Из миллиона с лишним файлов следует, что битрикс тут вряд ли оптимален, битрикс вообще склонен к пложению файлов на ровном месте по своей идеологии.
              Из 30 с лишним человек трудящихся над проектом следует что бюджет весьма достаточен.

              Кастюмная ЦМС тут была бы скорее всего идеальным решением даже с точки зрения бизнеса, при грамотном подходе к ее разработке разумеется.
              И с точки зрения скорости внесения изменений нужных заказчику и с точки зрения стоимости этих изменений для заказчика и с точки зрения потери посетителей в ходе обновлений.
              • +2
                В целом да, но в частности нет.
                Даже при стоимости проекта 1,5-2 миллиона и выше, с технической точки зрения логичнее создавать продукт с нуля, но с точки зрения бизнеса есть несколько преимуществ в разработке на готовой мощной CMS. Первая версия проекта появится гораздо быстрее. Намного легче применить итерацонный метод разработки. Проект можно будет отдать на поддержку другим разработчикам. Есть возможность «попробовать» на сайте много функционала и выбрать то, что нужно.
                И самое главное, е-комерс слишком динамично развивается. Допустим мы сейчас исследовали рынок интернет-магазинов. Точно определили, каким должен быть сайт, чтоб быть успешным. Составили ТЗ и провели разработку с нуля. К моменту завершения работ сайт устареет, так и не родившись. А куча изменений, которые тут же придется внести, чтоб выправить ситуацию, сведут на нет всю красоту и стройность разработки.
              • +1
                Смотря что считать не дорого. Если не отходит от логики разработчиков битрикса то да, но если заказчик думает иначе то капец.
                Например я не могу объяснять заказчику что битрикс свято верит что если я ставлю на рейтинге 5 звезд в итоге получается 3,5, клиент всегда прав и в итоге пишешь сам или покупаешь.

                Или например если доставка авиа и курьером по Москве то пункт оплату курьеру должен пропадать если выбрана авиа. В итоге долгая, нудная и безрезультатная переписка с тех поддержкой, и попросту ставишь свой js что бы просто сдать.

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

                Как результат Битрикс до-свидания, да здравствует Yii. Так что по проще это на Друпал, или на Yii
              • +7
                Проблема 0 тут процесс. 20 мину на апдейт из VCS? 60 GB репо? Внос по живому изменений на боевой сервер? Битрикс тут так вишенка на торте.
                • –4
                  Вот уж много чего слышал про битрикс,, но про отсутствие документации первый раз слышу.
                  Есть несколько курсов которые проходятся в браузере:
                  dev.1c-bitrix.ru/learning/

                  и есть документация для разработчика где описаны практически все классы и методы:
                  dev.1c-bitrix.ru/api_help/

                  Чего вам не хватает в документации?
                  • +4
                    Уточню: документация в коде, phpdoc например, который подхватит IDE, а когда «портянка» на 5000+ строк кода без единого комментария, для меня это отсутствие документации.
                    • 0
                      Еще вы не учитываете что она зачастую не актуально
                    • –2
                      Я последний год занимаюсь практически исключительно допиливанием чужих сайтов на Битрикс, Joomla, Drupal и т.д. — внедряю юзабилити и сео-рекомендации.

                      Проблема Битрикса в том, что мало кто из разработчиков следует его методологии:
                      — пишутся свои велосипеды;
                      — люди лезут в ядро, после чего систему нельзя обновить;
                      — страницы составляются так, что их потом нельзя редактировать в WYSIWYG.

                      Впрочем, другие CMS тоже калечатся нашим русским программистом так, что без слез не взглянешь. Я не видел ни одной приличной доработки готовой CMS — везде сплошной говнокод. Люди явно не читали документацию, не разбирались в API.

                      Кастомные CMS тоже встречались, даже неплохие — но в 100% случаев у них не было поддержки. Или студия-разработчик уже закрылась или автор сменил симку и ушел в голубую даль. Такое ощущение, что большинство мелких и средних студий делают сайт «лишь бы работал в день приемки», а дальше хоть трава не расти.
                    • –6
                      --Посещаемость 10-15 тыс. человек в день

                      Для Битрикса это детская цифра вообще-то

                      --В соответствии с лицензионной политикой 1С-Битрикс, каждая лицензия на сайт позволяет использовать 2 копии системы. Одну, как продакшен сайт, вторую – для разработки.

                      Это где вы такое вычитали?

                      Про NFR-лицензии для партнёров-разработчиков автор видимо не слышал…

                      --В случае с 1С-Битрикс все немного сложнее. Во-первых, файлов много. У меня в проекте их более миллиона. Обычный апдейт из репозитория проходит никак не меньше 20-30 минут.

                      Проект из 60 гб на максимальной редакции апдейтиться из SVN за 40 секунд… Просто нужно уметь разграничивать файлы ядра, аплоада, статику и свои собственные скрипты. Ядро вообще нет смысла загонять в репозиторий(хотя даже в этом случае легко глотается СВНом) — если уж очень хочется, то можно в репозитории хранить бекап ядра, который понадобиться только 1 раз — при развёртывании проекта.

                      --В случае большинства веб-приложений есть четкая структура разделения приложения на слои и обновление сайта можно разделить на 2 части

                      В битриксе всё тоже самое.

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

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

                      В-общем, терпения всё читать не хватило. Могу лишь подытожить, что Битрикс не виноват в том, что у вас(не лично у автора, сколько у компании в целом) кривые руки и вам влом пройти соответствующие курсы по работе с системой, получить сертификаты(это всё бесплатно к слову), получить партнёрский статус, который даже фрилансерам и шарашкиным конторам по онлайн-заявке предоставляется и серьёзно облегчает разработку крупных проектов командой разработчиков.
                      • +1
                        --В соответствии с лицензионной политикой 1С-Битрикс, каждая лицензия на сайт позволяет использовать 2 копии системы. Одну, как продакшен сайт, вторую – для разработки.

                        Это где вы такое вычитали?

                        Про NFR-лицензии для партнёров-разработчиков автор видимо не слышал…


                        Это ответ от тех. поддержки 1С-Битрикс. Проблему как раз и решил с помощью NFR-лицензий.

                        Так делают новички, а профи юзают соответствующие инструменты, которыми забит весь маркетплейс.


                        Вот это очень полезная для меня информация. Поищу. Можете указать, какими инструментами для этого пользуетесь Вы?

                        Битрикс не виноват в том, что у вас(не лично у автора, сколько у компании в целом) кривые руки и вам влом пройти соответствующие курсы по работе с системой, получить сертификаты(это всё бесплатно к слову), получить партнёрский статус


                        И партнерский статус и полный комплект сертификатов у каждого разработчика конечно же есть. Опыта разработки нас 1С-Битркс действительно не хватает. Собственно, статья появилась только потому, что информации, как правильно вести разработку я нигде не нашел. Тех. поддержка ответила, что у них никакой методологии и рекомендаций нет, курсов по этой теме, так же, нет. Поэтому учу все сам и делюсь информацией с читателями.
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • 0
                            Может и есть где то рекомендации, но там нечего специально указывать.
                            Ядро битрикса /bitrix/modules/ вообще не нужно трогать. Свои модули добавляются рядом с битриксовскими, например /bitrix/modules/имя_модуля/. То есть у конкретного разработчика в папке с проектом /bitrix/modules/ будут только свои модули, официальных там не должно быть. Если нужно авто дополнение, то папку с официальными модулями из /bitrix/modules/ нужно подключать в свою IDE как внешнюю библиотеку.

                            Аналогично и с компонентами. Битриксовские компоненты /bitrix/components/bitrix/ тоже незачем каждый раз туда сюда гонять. В папке с проектом они не нужны.

                            Вся статика из инфоблоков хранится в папке /upload/, разработчику эту папку нет необходимости трогать, а значит и закачивать обратно на боевой сервер ее тоже не нужно.

                            * * *
                            В общем все официальное остается нетронутым, а значит его можно с чистой совестью из VCS исключить. Своих файлов у разработчиков точно не миллион. То есть объединять для выгрузки на рабочий сервер не так и много приходится.
                            • –1
                              Подписываюсь под вышесказанным.

                              Правила хорошего тона разработки под Битрикс требуют обычно создать рядом с components/bitrix/ какой-нибудь components/%COMPANYNAME%/, причем в данном случае, даже если потребуется переписать с нуля какой-то встроенный компонент, можно быстро переключить его в коде уже после тестирования.
                        • 0
                          получить партнёрский статус, который даже фрилансерам и шарашкиным конторам по онлайн-заявке предоставляется
                          Это с каких пор?
                          Насколько мы помним — надо иметь юр.лицо (при этом даже ИП не факт что одобрят), подписать бумажный договор (что тоже не 5 минут) и еще что бы свой сайт был на битриксе (а не на чем-то другом).

                          p.s.: должно было уйти выше, в ответ на это habrahabr.ru/post/189630/#comment_6584870
                          • 0
                            Физику фрилансеру (даже не ИП) дали легко, время заняло только отправка почтой бумажного договора и потом короткое телефонное «интервью».
                            NFR получить уже немного сложнее.
                          • 0
                            Что за ужасы с лицензиями для разработчиков?
                            Заходим в «настройки» — «сайты» — «редактировать», видим блок «Доменное имя: (список доменных имен, каждое в новой строке) », забиваем туда «shop.ru, dev1.shop.ru, dev2.shop.ru» (ну или как вариант dev1.shop.studio.ru, dev2.shop.studio.ru".
                            PS. А главная проблема битрикса с точки зрения разработчика — это, конечно, template.php, тысячи их.
                            • –2
                              1С-Битрикс заблокировал мне возможность получения обновлений сайта до момента, пока я не убрал все копии, оставив только 2.
                              Доменов может ссылаться сколько угодно, но при этом, они все должны ссылаться на одну или вторую копию.
                            • 0
                              А сколько из этих 60 гигов приходится на картинки, можно узнать? И вообще какова структура репо, на что приходится 2-3 самых больших части?
                              • –1
                                Основной объем — картинки, видео и сопутствующие товарам архивы с ПО.
                                Большое количество мелких файлов принадлежит ядру 1С-Битрикс.
                                • +2
                                  Не думали хостить это вообще отдельно где то? и может стоит попробовать git вместо svn?
                                • 0
                                  хостинг и так внешний. SVNом пользуюсь исторически. Пробовал и то и то. Существенной разницы не нашел.
                                  • +6
                                    Зачем загружаемый контент хранить в системе контроля версий?

                                    Храните его отдельно от релизов, просто симлинкайте к текущему релизу. Храните их в бэкапах, если разрабу/тестеру/стейджу они нужны, он загрузит бэкап.

                                    В системе контроля версий нужно хранить код. Картинки тоже хранятся, если они относятся к верстке. Но не контент.
                                    • +2
                                      У Вас ошибка в самом начале этой схемы. На управление версиями нужно тратить ресурсы. Следовательно управлять версиями нужно только тех файлов, которые изменяются и для которых это критично. Если бы у вас дизайнеры постоянно исправляли картинки товаров и вам нужно было сравнивать все версии, их нужно было добавить в репозиторий. Очевидно, что такой необходимости нет. Картинки интерфейса — да, добавить нужно, но это явно не 60Гб. Чтобы утащить картинки на dev сервер и на машины разработчиков нафиг не нужна система контроля версий. Нужен rsync, который умеет качать только те картинки, которые изменились или добавились (он вообще много всего умеет, например, скорость скачивания ограничивать свою).

                                      Вот мой рецепт разработки и развертывания апдейтов на Битрикс (проверен годами):
                                      1) git;
                                      2) исключено из репозитория — все, кроме файлов, которые разработаны или кастомизированны. Исключения хранятся в .gitignore, который включен в репозиторий;
                                      3) у каждого разработчика виртуалка с сервером и сайтом на локальной машине;
                                      4) каждый разработчик изменения pushит в bare репозиторий;
                                      5) по расписанию, ведущий разработчик собирает dev сервер и отдает его тестировщику на сутки. На следующие сутки все что принято тестировщиком pullится с рабочего сервера;
                                      6) для разработчиков и для dev сервера есть скрипты (там две строчки на rsync) которые позволяют все отсутствующие локально картинки, видео и прочий контент с рабочего сервера скачать. Аналогично с БД. На самом деле мы качаем БД с реплики, а картинки с ненагруженного зеркала (до кластера пока не дошло), но можно и с рабочего, с такой посещаемостью это должно работать, если там не полная ж… со скриптами.

                                      PS: публикация изменений на рабочий сервер занимает редко более 10 секунд (это когда ооочень много изменений).
                                      • +1
                                        Добавлю про публикацию изменений. Отличная схема апдейта вообще без простоя для php на nginx- разные директории для старого и нового кода, изменение пути в конфиге nginx и его релоад.
                                        В описанной здесь схеме, конечно, картинки и другие медиаданные надо будет хранить отдельно от кода. Но это вообще очень хорошая практика )
                                        • +4
                                          Даже не нужно менять конфиг и рестартить nginx.

                                          nginx смотрит в директорию /site/current, которая является симлинком на текущий деплой.

                                          Релизы деплоятся в /site/releases/1, /site/releases/2 и тд.

                                          После деплоя симлинк /site/current меняется на директорию нового релиза.
                                          • 0
                                            За всех не скажу, но мы имели печальный опыт, что какой-то из используемых модулей (речь вообще не о Битриксе) опирался на используемый путь к файлам для кеширования. В итоге подцеплялись старые файлы и лезли нетривиальные баги. Помог описанный мной способ деплоя.
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                            • +1
                                              По хорошему, БД бы еще и версионировать неплохо, но с системой инфоблоков Битрикса это грусть-грустинушка и печаль-печалинушка такие, что мало не покажется.
                                              Правда, все равно это проще, чем тягать в SVN 60 бесполезных гигабайт:)
                                              • 0
                                                Да бросьте, версии для обычной разработки совершенно ни к чему. У вас разве несколько разработчиков одновременно выполняют задачи, связанные с изменением БД? Речь ведь о Битрикс — бОльшая часть задач все-таки в рамках API. Если делается новый сложный модуль, все равно один человек отвечает за структуру данных иначе будет бардак. Ежедневных бекапов и скрипта срочного бекапа и локального восстановления вполне достаточно.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                          • 0
                                            Добавлю, что очень не помешает иметь пару актуальных копий продакшен сайта — делать rsync-ом на удалённые машины расположенные поблизости (с гигабитным каналом) — ночную и текущую.

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