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 и автоматизация разработки Групповая разработка (Git, хранилище) Информационная безопасность Инструменты администратора БД Системный администратор Программист 1С 8.3 Беларусь Россия Казахстан Абонемент ($m)

Как реализовать безопасное маскирование данных в процессе CI/CD без создания промежуточных копий баз. Объясняем, как использовать инструмент pg_anon для автоматизации скрытия персональных данных при тестировании и развёртывании, сохраняя целостность и структуру информации. Материал объединяет практику Site Reliability Engineering (SRE) с задачами защиты данных, демонстрируя подход, при котором разработчики и DevOps;инженеры могут работать с реалистичными, но обезличенными данными, не нарушая требования безопасности и конфиденциальности.

1 стартмани

11.09.2026    767    0    Ninel_S    0    

0

DevOps и автоматизация разработки Администрирование СУБД Групповая разработка (Git, хранилище) Системный администратор Программист Руководитель проекта Стажер 1С 8.3 1С:Бухгалтерия государственного учреждения 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1C:ERP Беларусь Россия Казахстан Абонемент ($m)

В четвёртой части серии SRE-Suite-for-1C-platform мы переходим к практической автоматизации развёртывания отказоустойчивого кластера PostgreSQL для высоконагруженных систем 1С на Linux. В материале подробно разбирается инженерное решение без HAProxy — с использованием виртуального IP-адреса и vip-manager от CYBERTEC, обеспечивающего прямое подключение к активному мастеру без лишних задержек и точек отказа. Показана структура Ansible-модуля: подготовка ОС, развёртывание etcd, настройка Patroni с параметрами для больших нагрузок 1С. В конфигурационный шаблон Patroni автоматически закладываются параметры, критически важные для высоконагруженных баз данных, запуск vip-manager и полная автоматизация создания трёхнодового кластера. В конце — пошаговый Quick Start и планы развития модуля, включая резервное копирование, оптимизацию ОС Linux и rolling updates PostgreSQL.

1 стартмани

11.09.2026    643    0    Ninel_S    0    

0

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

Я автоматизировал доставку доработок в базы 1С, к которым можно подключиться только по RDP через шлюз. У меня не было ни SSH, ни WinRM, ни общих папок, ни права устанавливать на сервер свои программы. Каналом связи стал диск рабочей станции, проброшенный в RDP-сеанс, а исполнителем команд служит PowerShell-агент в этом сеансе. В статье расскажу о захвате объектов и помещении изменений в хранилище, динамическом обновлении боевой базы с автоматической остановкой, установке расширений и доступе к базе через MCP по COM без клиента 1С. Ещё разберу несколько неочевидных ограничений платформы и RDP, с которыми столкнулся по ходу работы. Часть из них описана на форумах, а упоминаний о других я не нашёл.

10.09.2026    654    BiLBelarus    0    

4

DevOps и автоматизация разработки Администрирование СУБД Групповая разработка (Git, хранилище) Системный администратор Программист Руководитель проекта Стажер 1С 8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Управление холдингом 1С:Зарплата и Управление Персоналом 3.x 1С:Предприятие 8. Транспортная логистика, экспедирование и управление автотранспортом КОРП 1C:ERP Беларусь Россия Казахстан Абонемент ($m)

В корпоративных инсталляциях «1С:Предприятие 8.3» под управлением PostgreSQL всё чаще проявляются архитектурные пределы масштабирования: рост числа пользователей, обязательная маркировка, плотный поток API-интеграций и высокая стоимость простоя. Вводная часть цикла разбирает ключевые факторы современной эксплуатационной нагрузки и формирует инженерную методологию эволюционной модернизации без остановки продуктивного контура. Материал основан на практическом кейсе «Торговый контур» и показывает, как определить целевые метрики (p95, MTTR, APDEX), выстроить наблюдаемость, стабилизировать работу кластера и подготовить инфраструктуру к дальнейшему масштабированию. Публикация задаёт фундамент для последующих частей, посвящённых телеметрии, оптимизации PostgreSQL, CI/CD и архитектурному росту.

1 стартмани

10.09.2026    696    0    Ninel_S    0    

5

DevOps и автоматизация разработки Linux HighLoad оптимизация Групповая разработка (Git, хранилище) Системный администратор Программист Руководитель проекта 1С:Предприятие 8 1С 8.3 1С:Документооборот 1С:ERP Управление предприятием 2 1С:Управление холдингом 1С:Комплексная автоматизация 2.х Беларусь Россия Казахстан Абонемент ($m)

Системный анализ архитектурных границ масштабирования учетных систем «1С:Предприятие 8.3» под управлением PostgreSQL в ОС Linux. Формулирование инженерной методологии сквозного проекта «Торговый контур», определение измеримых целевых показателей (p95, MTTR, APDEX) и стратегии поэтапной модернизации эксплуатационного контура без остановки промышленных учетных процессов.

1 стартмани

07.09.2026    963    Ninel_S    10    

1

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

Четыре года в интеграторе я работал с git и EDT. Git после хранилища полюбил сразу: видно, кто и что менял. С EDT сложнее: тормозит, ошибки при обновлении ERP, автономный сервер внутри него работает только с файловой базой. На новой работе команда захотела перейти на git, я развернул EDT, и оно на второй день разрушило проект при загрузке расширения. Тогда я решил дать команде git с привычным Конфигуратором и инструмент, который за минуту доносит коммит до базы через ibcmd, вместо получасовой загрузки из файлов. На новой работе разрешили ИИ, и я написал это приложение с его помощью: от чтения документации и первого ТЗ до идей в электричке. Впервые за годы снова почувствовал себя творцом, а не закрывателем задач. По дороге приросли выгрузка, объединение и проверка конфигурации по коммитам, YAxUnit и режим MCP-сервера. В статье: схемы, скриншоты, грабли и честный список ограничений. Ссылки пока нет: хочу понять, нужно ли это кому-то, кроме меня.

03.09.2026    10678    KatanaDragon511    28    

40

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

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

31.08.2026    3054    Evil Beaver    2    

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