В процессе разработки и поддержки сайта часто возникает необходимость в отслеживании истории изменений какого-либо файла и, возможно, в откате, то есть возвращении к более старой версии файла.
Необходимость эта может во многих случаях, вот некоторые из них:
Понадобилось сделать кратковременное изменение дизайна (например, под новый год)
Редактор сайта случайно испортил какую-нибудь страницу (а то и не одну) и нужно “вернуть, как раньше было”
Не дай бог завелся вирус, который записался в кучу файлов и теперь нужно найти все эти файлы и вернуть их в исходное состояние.
Год назад из дизайна удалили кусок, решив, что он больше не пригодится, но он таки вдруг понадобился.
До работы с сайтом допустили посторонних людей (например, seo-оптимизаторов), которые внесли свои изменения и нужно проверить, что же они в действительности поменяли.
Подобные задачи можно решать с помощью встроенной в 1С-Битрикс функциональности бэкапов, но это не очень удобно - нужно скачивать архив с бэкапом, вручную разыскивать изменившиеся файлы, затем, если нужно, опять их заливать на сайт. Более правильным способом будет использование систем контроля версий таких так subversion или git. Они всем хороши, но, к сожалению, не на каждый хостинг их поставишь, а даже если поставишь, то работать с ними придется через коммандную строку, что не очень удобно. Решением этих проблем (не всех, но многих) может стать новый модуль “Система контроля версий для 1С-Битрикс”. Если вы знаете, что такое svn, то этот модуль представляет из себя примерно то же самое, только попроще (пока что, планы по развитию наполеоновские), но зато встроено в админку битрикса.
На данный момент модуль умеет:
помещать в свое хранилище (репозиторий) файлы из настроенных источников данных, то есть из определенных папок на диске (см. ниже)
находить файлы, которые изменились по сравнению с последней версией, помещенной в репозиторий
показывать, что же изменилось в файле
помещать в репозиторий новую версию файла(ов) - это называется создать новую ревизию
по вашей просьбе восстанавливать файл из любой предыдущей ревизии
показывать историю изменений (ревизий) файла
добавлять в верхнюю панель кнопку для быстрого создания точки восстановления и отката к последней созданной точке восстановления
выгружать файлы, изменившиеся после определенной ревизии (поможет разработчикам модулей для Marketplace при сборке обновлений)
Теперь о том, как с этим модулем работать. Сначала нужно настроить “источники данных” - попросту говоря папку на диске, файлы из которой будут помещены в репозиторий. Добраться до настройки источников данных можно через настройки модуля. Там же можно включить, чтобы ссылка на настройку источников была в меню.
Как видно на скриншоте, нужно указать директорию, в которой будет производиться поиск файлов, расширения файлов, которые будут помещаться в репозиторий, а также поддиректории, в которых нужно и в которых не нужно искать файлы. При установке модуля автоматически настраиваются несколько источников - ядро (то есть то, что лежит в папке /bitrix), а также по одному источнику на каждый заведенный в системе сайт. Их можно использовать по умолчанию - туда попадут шаблоны, самописные компоненты, а также публичные части сайтов системы.
Итак, после того, как источники данных настроены, можно приступать к работе с модулем. Отправной точкой послужит пункт меню “Проверка изменившихся файлов” .
Сначала нужно выполнить проверку источников данных на изменения (красная стрелочка 1 на скриншоте), в процессе которой будут найдены все новые, изменившиеся и удаленные файлы. Результаты проверки будут представлены здесь же. Дальше нужно поработать с результатами проверки, то есть решить, какие изменившиеся файлы достойны занесения в репозиторий, а какие нет. Также здесь можно обнаружить файлы, которые нужно “вернуть как было” и тут же восстановить их в источнике из репозитория. Те файлы, которые изменились в источнике, но которые пока нет нужды заносить в репозиторий можно удалить из результатов проверки. У новых файлов можно посмотреть содержимое, а у удаленных - последнее содержимое из репозитория. У измененных же файлов можно что конкретно изменилось
Зеленым цветом подсвечены строки, которые появились, а красным - которые были удалены.
После того, как определен список файлов, достойный занесения в репозиторий, нужно зафиксировать (сохранить) эти изменения в репозитоирии (зеленая стрелочка 2). При сохранении нужно будет обязательно ввести описание сохраняемых изменений. В результате будет создана новая ревизия. Каждая ревизия получает свой порядковый номер (ID). Номер новой ревизии всегда больше номера прпедыдущей.
При первом использовании модуля репозиторий будет пустой, поэтому все файлы, найденные в результате проверки, будут новыми.
Следующим пунктом, про который нужно рассказать это “Файлы в репозитории”. Как понятно из названия это список всех файлов хранящихся в репозитории с возможностью разнообразной фильтрации.
Здесь можно посмотреть текущее содержимое файла в репозитории, изменения файла с предыдущей ревизии, перейти в историю изменений файла.
“Первая ревизия” - это номер ревизии, в которой файл был добавлен в репозиторий.
“Ревизия” - это номер ревизии в которой файл последний раз изменялся.
“Количество ревизий” - это число, показывающее в скольких ревизиях файл изменялся.
При удалении из репозитория фактически файл не удаляется, просто помечается удаленным и при проверке на изменения более не учитывается. Вся его история изменений в репозитории остается.
Далее идет пункт меню “Ревизии”. Это, банально, список всех ревизий. Можно перейти к просмотру файлов, входящих в ревизию, а можно восстановить все файлы измененные после данной ревизии - то есть переписать их в источнике такими, какими они были в выбранной ревизии.
Есть в модуле приятная фишка для разработчиков модулей для Marketplace. С ее помощью можно выгрузить список файлов, изменившихся после определенной ревизии
И мало того, что только выгрузить, так еще и проделать над этими файлами всякие действия, для этого есть специальное событие OnDriverAfterExport. У меня для сборки обновлений модуля в init.php прописан такой код:
AddEventHandler("karudo.vcs", "OnDriverAfterExport", "OnDriverAfterExport");
function OnDriverAfterExport($doc_root, $driver_code, $arFiles) {
global $APPLICATION;
if ('karudo_vcs' !== $driver_code) {
return;
}
foreach ($arFiles as $i) {
if (false !== strpos($i, '/lang/ru/')) {
if (file_exists($doc_root . $i)) {
$str = file_get_contents($doc_root . $i);
$str = $APPLICATION->ConvertCharset($str, 'UTF-8', 'CP1251');
file_put_contents($doc_root . $i, $str);
}
}
if (false !== strpos($i, '/install/js/')) {
if (false === strpos($i, 'compiled.js')) {
unlink($doc_root . $i);
}
}
}
}
Здесь языковые файлы перекодируются в кодировку Win1251, а также из выгрузки удаляются всякие служебные скрипты.
Еще в настройках модуля можно включить отображение специального меню в панели в пользовательской части сайта
"Создание точки восстановления" - это комбинация кнопок "Проверить на изменения" и "Зафиксировать изменения" из проверки на измененияю, а "Откат к предыдущей точке" восстанавливает из репозитория все файлы изменившиеся с последней ревизии.
Напоследок, о планах развития модуля на ближайшее время:
сохранение свойств инфоблоков в репозитории
сохранение элементов инфоблоков в репозитории
возможность синхронизации репозиториев между двумя разными битриксами
Спасибо, надеюсь вам понравится и пригодится Изменения в базе - что вы имеете ввиду? Просто отслеживать появление и изменений новых строк в таблицах? В принципе, сделать это можно, но думать надо, как это сделать правильно - ведь изменения в одной таблице могут быть связаны с изменениями в другой и отслеживать (а значит и откатывать), нужно будет все одновременно, а это не так просто. В общем, для начала, сделаю сохранение и откат инфоблоков, а потом можно будет и о всей базе думать
Система очень крутая. Крайне советую иметь на каждом боевом сервере. Тем более, как у нас часто бывает, на боевом сервере разработки
Буквально месяц назад восстанавливал один крохотный файл из 20 гигабайтного архива, уже похоронив мысленно неделю работы, если бы файла не было. Благо тогда обошлось, но с данным модулем такого бы и не было просто: начал рабочий день, прочекал. Закончил - закомитил.
В понедельник обязательно поставлю на этот злосчастный проект
Делюсь идеей как я это хотел сделать, но в твой модуль впишется просто идеально: - вешаем обработчик на изменение файлов - если это init.php меняется, то ПЕРЕД изменением создаем агента и ресторе-страничку (всегда по одному адресу лежит)
Если агент запускается, это значит изменение init.php произошло успешно, он удаляет ресторе-страничку, и себя.
Если он не запускается, значит все печально. Но ты знаешь этот постоянный url ресторе-странички, идешь по нему. Там одна кнопка - сделать все как было. Жмешь, и у тебя все как было - откатываешь изменение файла. И скрипт удаляет себя же и агент.
Как бы что этот URL будут знать все твои клиенты и он будет одинаков - неплохо, ведь уникальный URL можно и забыть. А то что его жмакнет злоумышленник - ничего страшного, ну восстановит лишь прежний init.php. Но можно и в такой создаваемый файл и проверку по IP зашить - вшивать тот IP, с которым изменяли файл.
Единственный геморр - тебе придется в этом ресторе-файле с нуля коннектиться к базе, соблсти минимальную безопасность, и прочее (хотя при вшитом IP восстановление все равно будет делать админ).
И вот тогда твой модуль будут покупать даже блондинки
Хорошо бы сделать возможность выгрузки в продакшн.Т.е. модуль стоит на dev сервере, вся разработка ведется на нем. После коммита хорошо бы иметь возможность залить все файлы на продакшн, собираются файлы из коммита и пушаться.
Деонис Перетягин какие еще могут быть способы что бы сделать такой контроль ? Так же вопрос а где на сайте хранятся эти файлы которые добавляются в ревизии ?
Вопрос по поводу своих модулей отпал, для этого надо создать ревизию поставить там абсолютный путь /srv/www/ethnomir.ru/htdocs/bitrix/modules и уже во включения добавить те модули которые необходимо контролировать
За более, чем 2 года не появилось фиксации изменений для элементов ИБ. Конечно, понимаю, что много факторов может влиять на это, высокая загруженность и т.д. Но прошу ответить на вопрос... стоит ли ожидать это и когда, если стоит?)
Антоненко Антон, думаю, намного проще научиться пользоваться уже существующими системами контроля версий (svn, git, mercurial) а не изобретать велосипед. А с элементами ИБ - делайте дампы базы данных и выборочно их накатывайте - ничего ведь сложного!
Михаил Вицен , не согласен с вами. Модуль получился отличный. Его можно использовать перед обновлением Битрикса для разбора полетов. Или для создания копии проекта, когда SEO-шники туда начинают лезть.
Очень хороший модуль. Автору большое спасибо. Очень помогает, (удобно, просто, как всегда кстати) я его называю Антистресс. Ставлю везде. Очень нужная вещь
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».