Devops на коленке, или Иногда стоит отказаться от gitsync

08.12.20

Разработка - DevOps и автоматизация разработки

В этой публикации описывается опыт выгрузки конфигурации в исходный код, ускорение выгрузки за счет отказа от использования gitsync в пользу своего решения.

Файлы

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование Скачано Купить файл
Devops на коленке, или Иногда стоит отказаться от gitsync:
.os 9,85Kb
10 2 500 руб. Купить

Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний

Оформите подписку на компанию для решения рабочих задач

Оформить подписку и скачать решение со скидкой

Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

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

Напомню, проект gitsync живет на гитхабе, основной адрес: github.com/oscript-library/gitsync, плагины, расширяющие его функциональность: github.com/khorevaa/gitsync-plugins

Как было

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

Сообщить(ТекущаяДата());
Сообщить("Запускаю выгрузку хранилища");
Команда = Новый Команда;
Команда.УстановитьСтрокуЗапуска("gitsync sync -u user -p pass tcp://server.local/erp E:\erp\src\cf E:\erp");
КодВозврата = Команда.Исполнить();
Сообщить(Команда.ПолучитьВывод());

Скрипт, естественно, написан на православном oscript, для единообразия все, что там запускается, исполняется через  1commands (конечно, в начале скрипта пишем #Использовать 1commands, чтобы магия заработала).

Скрипт работал, отрабатывал не быстро, но в целом все было хорошо.

А в чем собственно проблема?

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

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

Ну долго и долго, подождем?

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

Надо ускоряться

Как и многие другие, мы работаем с разделением хранилища конфигурации для разработки и рабочей базы. Разработчики живут в своем хранилище, рабочая база - в своем. При подготовке релиза специально обученный человек выгружает cf из хранилища разработки и делает сравнение-объединение с базой, подключенной к хранилищу рабочей базы, для переноса нужных изменений в продуктив. Для ускорения этого процесса ранее мы сделали скрипт, который делает очень простую вещь - при появлении новой версии в хранилище для разработки, он сохраняет cf файл с этой версией. Скрипт также оповещает ответственных лиц о появлении новой версии (отправляет письмо):

Подсказку дал stepan96. Хм, а если у нас уже есть готовый cf, может быть воспользоваться им?

По сути, ничего особенного не потребуется. Увидим, что в папке с cf появился новый, ранее не выгруженный в исходники файл, выгрузим его. В oscript есть возможность работы с файловой системой, есть библиотека для запуска различных команд конфигуратора, есть библиотека для работы с гит. Звучит несложно. Надо только решить ряд вопросов:

  • Как понять, что этот cf уже обрабатывался, а этот - нет? Воспользуемся тем же механизмом, что использует gitsync - будем читать и писать файл VERSION в корне конфигурации.
  • Откуда взять описание версии (автор, дата, комментарий) - у нас же голые файлы cf? Действительно проблема. Не хочется лезть за описанием в хранилище конфигурации, другой скрипт уже читал хранилище. Так пусть этот скрипт, что выгружает cf из хранилища заодно кладет рядом файл с описанием, мы его прочитаем и используем.
  • Как связать пользователей хранилища и e-mail для выгрузки в гит? Используем тот же файл AUTHORS, что использует gitsync.

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

Сначала обеспечили наличие файлов с описанием версии при выгрузке cf из хранилища. Этого удалось добиться с помощью библиотеки json и процедуры, которая преобразует структуру с описанием версии в json формат и сохраняет в текстовый файл с расширением .cfinfo:

За выгрузку в исходники отвечает простой код:

Процедура ВыгрузитьВИсходникиИнкрементно(ФайлВыгрузки)
	
	ВременныйКаталог = ВременныеФайлы.СоздатьКаталог();

	Конфигуратор = Новый УправлениеКонфигуратором();

	Конфигуратор.СоздатьФайловуюБазу(ВременныйКаталог);
	Конфигуратор.УстановитьКонтекст("/F" + ВременныйКаталог, "", "");
	Конфигуратор.ЗагрузитьКонфигурациюИзФайла(ФайлВыгрузки);

	Параметры = Конфигуратор.ПолучитьПараметрыЗапуска();
	Параметры.Добавить("/DumpConfigToFiles");
	Параметры.Добавить("E:\erp_pmt\src\cf");
	Параметры.Добавить("-update");

	Конфигуратор.ВыполнитьКоманду(Параметры);
	РезультатВыполнения = Конфигуратор.ВыводКоманды();
	
    УдалитьФайлы(ВременныйКаталог);

КонецПроцедуры

И основной текст скрипта:

ПутьКПапкеВыгрузок = "E:\Config_ERP_Develop_Repo";

ПоследняяОбработаннаяВерсия = ПоследняяОбработаннаяВерсия().НомерВерсии;
Сообщить(СтрШаблон("Последняя обработанная версия - %1", ПоследняяОбработаннаяВерсия));

ПоследняяВерсия = ПолучитьПоследнююЗагруженнуюВерсию(ПутьКПапкеВыгрузок);

Если ПоследняяОбработаннаяВерсия >= ПоследняяВерсия Тогда
	Сообщить("Нет новых версий для выгрузки в исходники!");
КонецЕсли;

Пока ПоследняяОбработаннаяВерсия < ПоследняяВерсия Цикл

	ПоследняяОбработаннаяВерсия = ПоследняяОбработаннаяВерсия + 1;

	ВыгрузитьВИсходникиИнкрементно(СтрШаблон("%1\%2.cf", ПутьКПапкеВыгрузок, ПоследняяОбработаннаяВерсия));
	ЗаписатьИнформациюОНовойВерсии(ПоследняяОбработаннаяВерсия);
	СделатьКоммитВерсии(ПоследняяОбработаннаяВерсия);

КонецЦикла;

Полный скрипт приложен в файле публикации.

Скрипт работает очень быстро:

  • инкрементная выгрузка включена "из коробки"
  • не тратится время на сбор конфигурации из хранилища

Вызывается легко, не нужно указывать никаких параметров:

Команда = Новый Команда;
Команда.УстановитьСтрокуЗапуска("oscript E:\erp_pmt\tools\cf_to_git.os");
КодВозврата = Команда.Исполнить();

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

Как бонус, переопределил перенос комментария из хранилища в коммит гита. Теперь комментарий предваряется словами "Хранилище конфигурации версия хххх". Посмотрите, как изменился список коммитов:

 так было

 так стало

Нагляднее, правда?

Спасибо сообществу за gitsync, за oscript и огромное количество библиотек для него.

Вступайте в нашу телеграмм-группу Инфостарт

git increment gitsync devops oscript

См. также

DevOps и автоматизация разработки Нейросети Программист 1С 8.3 Россия Бесплатно (free)

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

26.08.2026    415    YA_2159986692    0    

0

DevOps и автоматизация разработки Мониторинг Тестирование QA Программист 1С:Предприятие 8 Бесплатно (free)

Платформа 1С давно вышла за рамки учетных систем. Сегодня это полноценная среда для создания сложных, высоконагруженных и распределенных приложений. А значит, и стек технологий современного разработчика кардинально изменился. Систематизируем весь инструментарий, который превращает 1С-программиста в инженера: от EDT и Git до автотестов на YAxUnit, контейнеризации приложений в Docker, мониторинга в Prometheus и организации шины данных на Kafka. Разберемся, зачем каждый инструмент нужен, как он вписывается в жизненный цикл разработки и с чего начать его внедрение.

25.08.2026    14014    mrXoxot    49    

63

Linux DevOps и автоматизация разработки Программист 1С 8.3 Беларусь Россия Казахстан Бесплатно (free)

Разворачивание полноценной CI/CD инфраструктуры для 1С на Linux — это не просто дань моде, а жесткая необходимость для бизнеса, который не может позволить себе простои из-за ошибок человеческого фактора.

25.08.2026    554    Ninel_S    0    

1

DevOps и автоматизация разработки Программист 1С 8.3 1С:Управление торговлей 11 Россия Бесплатно (free)

Полный цикл разработки расширения 1С в пакетном режиме DESIGNER: выгрузка, правка, гейт компиляции, применение к базе и контроль результата — без единого клика в конфигураторе. Разбираю семь мин, на которых подорвался лично: почему LoadConfigFromFiles возвращает нулевой код на битом модуле, зачем нужен Xvfb, как pgrep находит сам себя, кто держит базу и как отличить работающий сеанс от забытого, и почему после рестарта сервера база остаётся закрытой. Платформа 8.3.27, УТ 11.5, сервер на Linux.

24.08.2026    2426    YA_2159986692    7    

14

Интеграция Нейросети DevOps и автоматизация разработки Распознавание документов и образов 1C:ERP 1С:КА 1С:УНФ Химическая промышленность Горнодобывающая промышленность Металлургическая промышленность Россия Платные (руб)

От чертежа до себестоимости — за минуты, а не дни. ИИ-Технолог автоматически распознаёт чертежи и техническую документацию (включая фото, сканы, PDF, Excel), рассчитывает нормы времени, формирует технологические маршруты, оценивает возможность изготовления и точную себестоимость. Интеграция с 1С (ERP, MES, КА, УНФ) и отраслевыми нормативами (ГОСТы).

366000 руб.

18.06.2026    1362    0    2    

0

DevOps и автоматизация разработки Программист 1С:Предприятие 8 Бесплатно (free)

Технический разбор нашего конвейера разработки на 1С: песочницы, Gitea, сборка, проверки и CLI backend'ы. Основной CLI - cursor; также поддерживаются codex, claude и экспериментальный mimo.

16.06.2026    5370    Aleksandr    5    

8

DevOps и автоматизация разработки Программист Бесплатно (free)

Использование современных DevOps-практик в разработке и сопровождении активно внедряется в стек 1С. Мы в MagnitTech активно используем Docker, в том числе и для контейнеризации 1С-приложений, что позволяет ускорить развертывание, улучшить отказоустойчивость и упростить масштабирование. Рассмотрим лучшие практики создания Dockerfile и нюансы работы в контейнере для сервера приложений и сервера взаимодействия 1С – с какими сложностями мы столкнулись и как их преодолели.

26.05.2026    3122    daniloffartur    1    

5
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. user1503726 08.12.20 19:14 Сейчас в теме
Спасибо, очень полезный материал.
gubanoff; +1 Ответить
2. Evil Beaver 8412 30.12.20 12:12 Сейчас в теме
А нельзя ли эти доработки прислать в состав gitsync?
pavlo; artbear; Totoro; gubanoff; +4 Ответить
Для отправки сообщения требуется регистрация/авторизация