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

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

Категория: Публикации 1С

Подробнее

Описание
Подробнее

Описание

Сразу хочу попросить прощения у сообщества за провокационный заголовок. 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 и огромное количество библиотек для него.

Каталог решений - Devops на коленке, или Иногда стоит отказаться от gitsync