Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
Проблема №0 — 1С Битрикс. Я все понимаю, ко всему отношусь лояльно, но для работы просто невозможная система, код просто ужас — ни документации, ни единого codestyle.
С точки зрения разработчика, наверное, да. С точки зрения бизнеса — позволяет сравнительно не дорого решить большой класс задач. Многие интернет-магазины не смогут позволить себе написать всю движок с нуля.
Мне кажется что со своей ценовой политикой, Битрикс не самое выгодное средство для магазина. Чтобы сделать магазин на Битриксе, надо покупать редакцию «Малый бизнес», которая стоит почти 25 тыс. руб. К этому ещё нужно добавить оплату за специалиста, который сделает этот магазин на Битриксе, т.к. человек далёкий от программирования просто-напросто не осилит Битрикс. В итоге получаются достаточно большие растраты.
Хороший интернет-магазин на 1С-Битрикс, как правило, стоит от 300 000 и выше. Один только дизайн сайта обойдется в сотню. При таких масштабах проекта стоимость лицензии как-то теряется.
Битрикс — решение для стандартных сайтов- интернет-витрин. Все, что более 300тыс. -это полноценные e-commerce проекты — интернет-магазины в полном понимании этого слова. Делать на Битриксе имеет смысл, если есть опытная команда, которая уже проходила эту историю. Если команды нет, то лучше делать с нуля, прописывая архитектуру и выбирая подходящий фреймворк.
Любой инет магазин стоит столько.
В данном конкретном случае даже с точки зрения бизнеса сомнительно.
Магазин с 12 тысячами товаров и примерно таким же количеством посетителей.
Над проектом трудится больше 30 человек, в коде сайта больше миллиона файлов, ТЗ на 100 страниц.
Из 100 страниц ТЗ явно следует что от чистого битрикса при таком раскладе там осталось не так много.
Из миллиона с лишним файлов следует, что битрикс тут вряд ли оптимален, битрикс вообще склонен к пложению файлов на ровном месте по своей идеологии.
Из 30 с лишним человек трудящихся над проектом следует что бюджет весьма достаточен.
Кастюмная ЦМС тут была бы скорее всего идеальным решением даже с точки зрения бизнеса, при грамотном подходе к ее разработке разумеется.
И с точки зрения скорости внесения изменений нужных заказчику и с точки зрения стоимости этих изменений для заказчика и с точки зрения потери посетителей в ходе обновлений.
Магазин с 12 тысячами товаров и примерно таким же количеством посетителей.
Над проектом трудится больше 30 человек, в коде сайта больше миллиона файлов, ТЗ на 100 страниц.
Из 100 страниц ТЗ явно следует что от чистого битрикса при таком раскладе там осталось не так много.
Из миллиона с лишним файлов следует, что битрикс тут вряд ли оптимален, битрикс вообще склонен к пложению файлов на ровном месте по своей идеологии.
Из 30 с лишним человек трудящихся над проектом следует что бюджет весьма достаточен.
Кастюмная ЦМС тут была бы скорее всего идеальным решением даже с точки зрения бизнеса, при грамотном подходе к ее разработке разумеется.
И с точки зрения скорости внесения изменений нужных заказчику и с точки зрения стоимости этих изменений для заказчика и с точки зрения потери посетителей в ходе обновлений.
В целом да, но в частности нет.
Даже при стоимости проекта 1,5-2 миллиона и выше, с технической точки зрения логичнее создавать продукт с нуля, но с точки зрения бизнеса есть несколько преимуществ в разработке на готовой мощной CMS. Первая версия проекта появится гораздо быстрее. Намного легче применить итерацонный метод разработки. Проект можно будет отдать на поддержку другим разработчикам. Есть возможность «попробовать» на сайте много функционала и выбрать то, что нужно.
И самое главное, е-комерс слишком динамично развивается. Допустим мы сейчас исследовали рынок интернет-магазинов. Точно определили, каким должен быть сайт, чтоб быть успешным. Составили ТЗ и провели разработку с нуля. К моменту завершения работ сайт устареет, так и не родившись. А куча изменений, которые тут же придется внести, чтоб выправить ситуацию, сведут на нет всю красоту и стройность разработки.
Даже при стоимости проекта 1,5-2 миллиона и выше, с технической точки зрения логичнее создавать продукт с нуля, но с точки зрения бизнеса есть несколько преимуществ в разработке на готовой мощной CMS. Первая версия проекта появится гораздо быстрее. Намного легче применить итерацонный метод разработки. Проект можно будет отдать на поддержку другим разработчикам. Есть возможность «попробовать» на сайте много функционала и выбрать то, что нужно.
И самое главное, е-комерс слишком динамично развивается. Допустим мы сейчас исследовали рынок интернет-магазинов. Точно определили, каким должен быть сайт, чтоб быть успешным. Составили ТЗ и провели разработку с нуля. К моменту завершения работ сайт устареет, так и не родившись. А куча изменений, которые тут же придется внести, чтоб выправить ситуацию, сведут на нет всю красоту и стройность разработки.
Смотря что считать не дорого. Если не отходит от логики разработчиков битрикса то да, но если заказчик думает иначе то капец.
Например я не могу объяснять заказчику что битрикс свято верит что если я ставлю на рейтинге 5 звезд в итоге получается 3,5, клиент всегда прав и в итоге пишешь сам или покупаешь.
Или например если доставка авиа и курьером по Москве то пункт оплату курьеру должен пропадать если выбрана авиа. В итоге долгая, нудная и безрезультатная переписка с тех поддержкой, и попросту ставишь свой js что бы просто сдать.
А теги это вообще песня, при наличие больше 50000 материалов попробуйте при создании ввести тег, сплошная мука. Они так и храняться в отдельном поле через запятую, в итоге вводите вы букву что бы ввести тег а у вас полно текстовый поиск по базе. Фронт можно конечно закишировать но вот в админке все работает по живому. В итоге ребята писали теги стразу в блокноте и вставляли в строку.
Как результат Битрикс до-свидания, да здравствует Yii. Так что по проще это на Друпал, или на Yii
Например я не могу объяснять заказчику что битрикс свято верит что если я ставлю на рейтинге 5 звезд в итоге получается 3,5, клиент всегда прав и в итоге пишешь сам или покупаешь.
Или например если доставка авиа и курьером по Москве то пункт оплату курьеру должен пропадать если выбрана авиа. В итоге долгая, нудная и безрезультатная переписка с тех поддержкой, и попросту ставишь свой js что бы просто сдать.
А теги это вообще песня, при наличие больше 50000 материалов попробуйте при создании ввести тег, сплошная мука. Они так и храняться в отдельном поле через запятую, в итоге вводите вы букву что бы ввести тег а у вас полно текстовый поиск по базе. Фронт можно конечно закишировать но вот в админке все работает по живому. В итоге ребята писали теги стразу в блокноте и вставляли в строку.
Как результат Битрикс до-свидания, да здравствует Yii. Так что по проще это на Друпал, или на Yii
Проблема 0 тут процесс. 20 мину на апдейт из VCS? 60 GB репо? Внос по живому изменений на боевой сервер? Битрикс тут так вишенка на торте.
Вот уж много чего слышал про битрикс,, но про отсутствие документации первый раз слышу.
Есть несколько курсов которые проходятся в браузере:
dev.1c-bitrix.ru/learning/
и есть документация для разработчика где описаны практически все классы и методы:
dev.1c-bitrix.ru/api_help/
Чего вам не хватает в документации?
Есть несколько курсов которые проходятся в браузере:
dev.1c-bitrix.ru/learning/
и есть документация для разработчика где описаны практически все классы и методы:
dev.1c-bitrix.ru/api_help/
Чего вам не хватает в документации?
Я последний год занимаюсь практически исключительно допиливанием чужих сайтов на Битрикс, Joomla, Drupal и т.д. — внедряю юзабилити и сео-рекомендации.
Проблема Битрикса в том, что мало кто из разработчиков следует его методологии:
— пишутся свои велосипеды;
— люди лезут в ядро, после чего систему нельзя обновить;
— страницы составляются так, что их потом нельзя редактировать в WYSIWYG.
Впрочем, другие CMS тоже калечатся нашим русским программистом так, что без слез не взглянешь. Я не видел ни одной приличной доработки готовой CMS — везде сплошной говнокод. Люди явно не читали документацию, не разбирались в API.
Кастомные CMS тоже встречались, даже неплохие — но в 100% случаев у них не было поддержки. Или студия-разработчик уже закрылась или автор сменил симку и ушел в голубую даль. Такое ощущение, что большинство мелких и средних студий делают сайт «лишь бы работал в день приемки», а дальше хоть трава не расти.
Проблема Битрикса в том, что мало кто из разработчиков следует его методологии:
— пишутся свои велосипеды;
— люди лезут в ядро, после чего систему нельзя обновить;
— страницы составляются так, что их потом нельзя редактировать в WYSIWYG.
Впрочем, другие CMS тоже калечатся нашим русским программистом так, что без слез не взглянешь. Я не видел ни одной приличной доработки готовой CMS — везде сплошной говнокод. Люди явно не читали документацию, не разбирались в API.
Кастомные CMS тоже встречались, даже неплохие — но в 100% случаев у них не было поддержки. Или студия-разработчик уже закрылась или автор сменил симку и ушел в голубую даль. Такое ощущение, что большинство мелких и средних студий делают сайт «лишь бы работал в день приемки», а дальше хоть трава не расти.
--Посещаемость 10-15 тыс. человек в день
Для Битрикса это детская цифра вообще-то
--В соответствии с лицензионной политикой 1С-Битрикс, каждая лицензия на сайт позволяет использовать 2 копии системы. Одну, как продакшен сайт, вторую – для разработки.
Это где вы такое вычитали?
Про NFR-лицензии для партнёров-разработчиков автор видимо не слышал…
--В случае с 1С-Битрикс все немного сложнее. Во-первых, файлов много. У меня в проекте их более миллиона. Обычный апдейт из репозитория проходит никак не меньше 20-30 минут.
Проект из 60 гб на максимальной редакции апдейтиться из SVN за 40 секунд… Просто нужно уметь разграничивать файлы ядра, аплоада, статику и свои собственные скрипты. Ядро вообще нет смысла загонять в репозиторий(хотя даже в этом случае легко глотается СВНом) — если уж очень хочется, то можно в репозитории хранить бекап ядра, который понадобиться только 1 раз — при развёртывании проекта.
--В случае большинства веб-приложений есть четкая структура разделения приложения на слои и обновление сайта можно разделить на 2 части
В битриксе всё тоже самое.
--Во-вторых, и это куда более печально, часто при апдейте приходится делать ручные изменения и настройки через админку.
Так делают новички, а профи юзают соответствующие инструменты, которыми забит весь маркетплейс. Гики же пишут свои скрипты. Да и это проблема не столько битрикса, сколько вообще разработки крупных веб-проектов, когда после релиза невозможно тупо заливать дампы базы данных
В-общем, терпения всё читать не хватило. Могу лишь подытожить, что Битрикс не виноват в том, что у вас(не лично у автора, сколько у компании в целом) кривые руки и вам влом пройти соответствующие курсы по работе с системой, получить сертификаты(это всё бесплатно к слову), получить партнёрский статус, который даже фрилансерам и шарашкиным конторам по онлайн-заявке предоставляется и серьёзно облегчает разработку крупных проектов командой разработчиков.
Для Битрикса это детская цифра вообще-то
--В соответствии с лицензионной политикой 1С-Битрикс, каждая лицензия на сайт позволяет использовать 2 копии системы. Одну, как продакшен сайт, вторую – для разработки.
Это где вы такое вычитали?
Про NFR-лицензии для партнёров-разработчиков автор видимо не слышал…
--В случае с 1С-Битрикс все немного сложнее. Во-первых, файлов много. У меня в проекте их более миллиона. Обычный апдейт из репозитория проходит никак не меньше 20-30 минут.
Проект из 60 гб на максимальной редакции апдейтиться из SVN за 40 секунд… Просто нужно уметь разграничивать файлы ядра, аплоада, статику и свои собственные скрипты. Ядро вообще нет смысла загонять в репозиторий(хотя даже в этом случае легко глотается СВНом) — если уж очень хочется, то можно в репозитории хранить бекап ядра, который понадобиться только 1 раз — при развёртывании проекта.
--В случае большинства веб-приложений есть четкая структура разделения приложения на слои и обновление сайта можно разделить на 2 части
В битриксе всё тоже самое.
--Во-вторых, и это куда более печально, часто при апдейте приходится делать ручные изменения и настройки через админку.
Так делают новички, а профи юзают соответствующие инструменты, которыми забит весь маркетплейс. Гики же пишут свои скрипты. Да и это проблема не столько битрикса, сколько вообще разработки крупных веб-проектов, когда после релиза невозможно тупо заливать дампы базы данных
В-общем, терпения всё читать не хватило. Могу лишь подытожить, что Битрикс не виноват в том, что у вас(не лично у автора, сколько у компании в целом) кривые руки и вам влом пройти соответствующие курсы по работе с системой, получить сертификаты(это всё бесплатно к слову), получить партнёрский статус, который даже фрилансерам и шарашкиным конторам по онлайн-заявке предоставляется и серьёзно облегчает разработку крупных проектов командой разработчиков.
--В соответствии с лицензионной политикой 1С-Битрикс, каждая лицензия на сайт позволяет использовать 2 копии системы. Одну, как продакшен сайт, вторую – для разработки.
Это где вы такое вычитали?
Про NFR-лицензии для партнёров-разработчиков автор видимо не слышал…
Это ответ от тех. поддержки 1С-Битрикс. Проблему как раз и решил с помощью NFR-лицензий.
Так делают новички, а профи юзают соответствующие инструменты, которыми забит весь маркетплейс.
Вот это очень полезная для меня информация. Поищу. Можете указать, какими инструментами для этого пользуетесь Вы?
Битрикс не виноват в том, что у вас(не лично у автора, сколько у компании в целом) кривые руки и вам влом пройти соответствующие курсы по работе с системой, получить сертификаты(это всё бесплатно к слову), получить партнёрский статус
И партнерский статус и полный комплект сертификатов у каждого разработчика конечно же есть. Опыта разработки нас 1С-Битркс действительно не хватает. Собственно, статья появилась только потому, что информации, как правильно вести разработку я нигде не нашел. Тех. поддержка ответила, что у них никакой методологии и рекомендаций нет, курсов по этой теме, так же, нет. Поэтому учу все сам и делюсь информацией с читателями.
Может и есть где то рекомендации, но там нечего специально указывать.
Ядро битрикса /bitrix/modules/ вообще не нужно трогать. Свои модули добавляются рядом с битриксовскими, например /bitrix/modules/имя_модуля/. То есть у конкретного разработчика в папке с проектом /bitrix/modules/ будут только свои модули, официальных там не должно быть. Если нужно авто дополнение, то папку с официальными модулями из /bitrix/modules/ нужно подключать в свою IDE как внешнюю библиотеку.
Аналогично и с компонентами. Битриксовские компоненты /bitrix/components/bitrix/ тоже незачем каждый раз туда сюда гонять. В папке с проектом они не нужны.
Вся статика из инфоблоков хранится в папке /upload/, разработчику эту папку нет необходимости трогать, а значит и закачивать обратно на боевой сервер ее тоже не нужно.
* * *
В общем все официальное остается нетронутым, а значит его можно с чистой совестью из VCS исключить. Своих файлов у разработчиков точно не миллион. То есть объединять для выгрузки на рабочий сервер не так и много приходится.
Ядро битрикса /bitrix/modules/ вообще не нужно трогать. Свои модули добавляются рядом с битриксовскими, например /bitrix/modules/имя_модуля/. То есть у конкретного разработчика в папке с проектом /bitrix/modules/ будут только свои модули, официальных там не должно быть. Если нужно авто дополнение, то папку с официальными модулями из /bitrix/modules/ нужно подключать в свою IDE как внешнюю библиотеку.
Аналогично и с компонентами. Битриксовские компоненты /bitrix/components/bitrix/ тоже незачем каждый раз туда сюда гонять. В папке с проектом они не нужны.
Вся статика из инфоблоков хранится в папке /upload/, разработчику эту папку нет необходимости трогать, а значит и закачивать обратно на боевой сервер ее тоже не нужно.
* * *
В общем все официальное остается нетронутым, а значит его можно с чистой совестью из VCS исключить. Своих файлов у разработчиков точно не миллион. То есть объединять для выгрузки на рабочий сервер не так и много приходится.
Подписываюсь под вышесказанным.
Правила хорошего тона разработки под Битрикс требуют обычно создать рядом с components/bitrix/ какой-нибудь components/%COMPANYNAME%/, причем в данном случае, даже если потребуется переписать с нуля какой-то встроенный компонент, можно быстро переключить его в коде уже после тестирования.
Правила хорошего тона разработки под Битрикс требуют обычно создать рядом с components/bitrix/ какой-нибудь components/%COMPANYNAME%/, причем в данном случае, даже если потребуется переписать с нуля какой-то встроенный компонент, можно быстро переключить его в коде уже после тестирования.
Свои несколько копеек можно?
Делал несколько проектов на битре. С папкой upload справился симлинками :)
Вся разработка в /local ушла, там же и нужные копии компонентов.
Что не нравится в upload — когда контент-менеджеры грузят что-то, то нейминг файлов.
Очень важно не накосячить с ID инфоблоков в своем «коде» :)
Плюс битры: быстро разворачивается. Можно интернет-ларёк за пару часов развернуть и настроить. И сейчас акцент ушел полностью в Б24.
Что не нравится? Всё :)
Делал несколько проектов на битре. С папкой upload справился симлинками :)
Вся разработка в /local ушла, там же и нужные копии компонентов.
Что не нравится в upload — когда контент-менеджеры грузят что-то, то нейминг файлов.
Очень важно не накосячить с ID инфоблоков в своем «коде» :)
Плюс битры: быстро разворачивается. Можно интернет-ларёк за пару часов развернуть и настроить. И сейчас акцент ушел полностью в Б24.
Что не нравится? Всё :)
получить партнёрский статус, который даже фрилансерам и шарашкиным конторам по онлайн-заявке предоставляетсяЭто с каких пор?
Насколько мы помним — надо иметь юр.лицо (при этом даже ИП не факт что одобрят), подписать бумажный договор (что тоже не 5 минут) и еще что бы свой сайт был на битриксе (а не на чем-то другом).
p.s.: должно было уйти выше, в ответ на это habrahabr.ru/post/189630/#comment_6584870
Что за ужасы с лицензиями для разработчиков?
Заходим в «настройки» — «сайты» — «редактировать», видим блок «Доменное имя: (список доменных имен, каждое в новой строке) », забиваем туда «shop.ru, dev1.shop.ru, dev2.shop.ru» (ну или как вариант dev1.shop.studio.ru, dev2.shop.studio.ru".
PS. А главная проблема битрикса с точки зрения разработчика — это, конечно, template.php, тысячи их.
Заходим в «настройки» — «сайты» — «редактировать», видим блок «Доменное имя: (список доменных имен, каждое в новой строке) », забиваем туда «shop.ru, dev1.shop.ru, dev2.shop.ru» (ну или как вариант dev1.shop.studio.ru, dev2.shop.studio.ru".
PS. А главная проблема битрикса с точки зрения разработчика — это, конечно, template.php, тысячи их.
А сколько из этих 60 гигов приходится на картинки, можно узнать? И вообще какова структура репо, на что приходится 2-3 самых больших части?
Основной объем — картинки, видео и сопутствующие товарам архивы с ПО.
Большое количество мелких файлов принадлежит ядру 1С-Битрикс.
Большое количество мелких файлов принадлежит ядру 1С-Битрикс.
хостинг и так внешний. SVNом пользуюсь исторически. Пробовал и то и то. Существенной разницы не нашел.
Зачем загружаемый контент хранить в системе контроля версий?
Храните его отдельно от релизов, просто симлинкайте к текущему релизу. Храните их в бэкапах, если разрабу/тестеру/стейджу они нужны, он загрузит бэкап.
В системе контроля версий нужно хранить код. Картинки тоже хранятся, если они относятся к верстке. Но не контент.
Храните его отдельно от релизов, просто симлинкайте к текущему релизу. Храните их в бэкапах, если разрабу/тестеру/стейджу они нужны, он загрузит бэкап.
В системе контроля версий нужно хранить код. Картинки тоже хранятся, если они относятся к верстке. Но не контент.
У Вас ошибка в самом начале этой схемы. На управление версиями нужно тратить ресурсы. Следовательно управлять версиями нужно только тех файлов, которые изменяются и для которых это критично. Если бы у вас дизайнеры постоянно исправляли картинки товаров и вам нужно было сравнивать все версии, их нужно было добавить в репозиторий. Очевидно, что такой необходимости нет. Картинки интерфейса — да, добавить нужно, но это явно не 60Гб. Чтобы утащить картинки на dev сервер и на машины разработчиков нафиг не нужна система контроля версий. Нужен rsync, который умеет качать только те картинки, которые изменились или добавились (он вообще много всего умеет, например, скорость скачивания ограничивать свою).
Вот мой рецепт разработки и развертывания апдейтов на Битрикс (проверен годами):
1) git;
2) исключено из репозитория — все, кроме файлов, которые разработаны или кастомизированны. Исключения хранятся в .gitignore, который включен в репозиторий;
3) у каждого разработчика виртуалка с сервером и сайтом на локальной машине;
4) каждый разработчик изменения pushит в bare репозиторий;
5) по расписанию, ведущий разработчик собирает dev сервер и отдает его тестировщику на сутки. На следующие сутки все что принято тестировщиком pullится с рабочего сервера;
6) для разработчиков и для dev сервера есть скрипты (там две строчки на rsync) которые позволяют все отсутствующие локально картинки, видео и прочий контент с рабочего сервера скачать. Аналогично с БД. На самом деле мы качаем БД с реплики, а картинки с ненагруженного зеркала (до кластера пока не дошло), но можно и с рабочего, с такой посещаемостью это должно работать, если там не полная ж… со скриптами.
PS: публикация изменений на рабочий сервер занимает редко более 10 секунд (это когда ооочень много изменений).
Вот мой рецепт разработки и развертывания апдейтов на Битрикс (проверен годами):
1) git;
2) исключено из репозитория — все, кроме файлов, которые разработаны или кастомизированны. Исключения хранятся в .gitignore, который включен в репозиторий;
3) у каждого разработчика виртуалка с сервером и сайтом на локальной машине;
4) каждый разработчик изменения pushит в bare репозиторий;
5) по расписанию, ведущий разработчик собирает dev сервер и отдает его тестировщику на сутки. На следующие сутки все что принято тестировщиком pullится с рабочего сервера;
6) для разработчиков и для dev сервера есть скрипты (там две строчки на rsync) которые позволяют все отсутствующие локально картинки, видео и прочий контент с рабочего сервера скачать. Аналогично с БД. На самом деле мы качаем БД с реплики, а картинки с ненагруженного зеркала (до кластера пока не дошло), но можно и с рабочего, с такой посещаемостью это должно работать, если там не полная ж… со скриптами.
PS: публикация изменений на рабочий сервер занимает редко более 10 секунд (это когда ооочень много изменений).
Добавлю про публикацию изменений. Отличная схема апдейта вообще без простоя для php на nginx- разные директории для старого и нового кода, изменение пути в конфиге nginx и его релоад.
В описанной здесь схеме, конечно, картинки и другие медиаданные надо будет хранить отдельно от кода. Но это вообще очень хорошая практика )
В описанной здесь схеме, конечно, картинки и другие медиаданные надо будет хранить отдельно от кода. Но это вообще очень хорошая практика )
Даже не нужно менять конфиг и рестартить nginx.
nginx смотрит в директорию /site/current, которая является симлинком на текущий деплой.
Релизы деплоятся в /site/releases/1, /site/releases/2 и тд.
После деплоя симлинк /site/current меняется на директорию нового релиза.
nginx смотрит в директорию /site/current, которая является симлинком на текущий деплой.
Релизы деплоятся в /site/releases/1, /site/releases/2 и тд.
После деплоя симлинк /site/current меняется на директорию нового релиза.
По хорошему, БД бы еще и версионировать неплохо, но с системой инфоблоков Битрикса это грусть-грустинушка и печаль-печалинушка такие, что мало не покажется.
Правда, все равно это проще, чем тягать в SVN 60 бесполезных гигабайт:)
Правда, все равно это проще, чем тягать в SVN 60 бесполезных гигабайт:)
Да бросьте, версии для обычной разработки совершенно ни к чему. У вас разве несколько разработчиков одновременно выполняют задачи, связанные с изменением БД? Речь ведь о Битрикс — бОльшая часть задач все-таки в рамках API. Если делается новый сложный модуль, все равно один человек отвечает за структуру данных иначе будет бардак. Ежедневных бекапов и скрипта срочного бекапа и локального восстановления вполне достаточно.
Добавлю, что очень не помешает иметь пару актуальных копий продакшен сайта — делать rsync-ом на удалённые машины расположенные поблизости (с гигабитным каналом) — ночную и текущую.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Методология разработки на 1С-Битрикс – опыт дурака