Гонка конфигураторов с помощью экзекутора
Выгружать конфигурацию в файлы в последнее время стало супер модно. Контроль версий, Git, CI/CD и вот это вот все. Исходники как тексты сегодня нужны всем. Но возникают вопросы: а каким методом лучше и быстрее выгружать конфигурацию в файлы, а какая версия платформы справляется с этой задачей оперативнее? Моя статья постарается ответить на эти вопросы. Как говорится, заставим попотеть ваши конфигураторы. С помощью 1С Исполнителя 2.0 мы выгрузим конфигурацию ЗУП, используя платформу пяти версий, от 8.3.18 до 8.3.22.
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Поправьте BATH -> BATCH :) Bath - это не про конфигуратор и исходники:))
Ну а по сути статьи... Немного познавательно. Но практического смысла просто в выгрузке исходников - немного. По результатам выгрузки ведь важно знать автора участка кода. В случае Конфигуратора и хранилища для этого используем gitsync.
Ну а по сути статьи... Немного познавательно. Но практического смысла просто в выгрузке исходников - немного. По результатам выгрузки ведь важно знать автора участка кода. В случае Конфигуратора и хранилища для этого используем gitsync.
(3) Никита, поправьте меня, если я не прав.
В библиотеках *runner при выгрузке конфигурации в файлы под капотом запускается конфигуратор в пакетном режиме. Исходя из этого я не стал тестировать *runner а сразу протестировал конфигуратор в этом режиме.
Напротив в библиотеке precommit1c реализован собственный алгоритм разбора конфигураций. Но причину, по которой я не стал тестировать precommit1C указан в статье.
В библиотеках *runner при выгрузке конфигурации в файлы под капотом запускается конфигуратор в пакетном режиме. Исходя из этого я не стал тестировать *runner а сразу протестировал конфигуратор в этом режиме.
Напротив в библиотеке precommit1c реализован собственный алгоритм разбора конфигураций. Но причину, по которой я не стал тестировать precommit1C указан в статье.
Хорошая статья - прям два в одном - и замер производительности инструментов выгрузки, и новые примеры по 1С Исполнителю.
Но два замечания:
1. Жаль, что сбросили со счетов precommit1c (хотя не знаю что там за проблемы с управляемыми формами; пока выглядит как явно предвзятое отстранение прямого стороннего конкурента; думаю можно было бы замерить и им тоже, если там уж явно есть косяки с упр формами - то взяли бы примера ещё и другу конфигурацию без упр форм - правда такую поискать надо - сейчас в типовых почти везде есть хотя бы несколько уро. форм, даже в неуправляемых конфигурациях). Вроде бы есть ещё несколько сторонних сервисов по выгрузки конфигурации в xml файлы.
2. Автор проверил выгрузку, но почему-то не протестировал загрузку, а это тоже важно!
3. Автор говорит об усилении роли внешних инструментов в обработке исходников конфигураций 1С. В таких сценариях часто происходит не полная выгрузка/загрузка, а частичная синхронизация (и у 1С есть поддержка такого режима, в т.ч. с автоанализом изменившихся файлов) - вот в таком режиме было бы неплохо тоже протестировать. В том числе при пакетной работе (несколько выгрузок/загрузок) - тут, думаю, Агент конфигуратора проявит себя более эффективно, так что сбрасывать со счетов его не стоит.
А то получается в статье большая её часть собственно не посвящена непосредственно самим тестам - и было бы правильно её дополнить именно информацией по расширенным тестам!
Но два замечания:
1. Жаль, что сбросили со счетов precommit1c (хотя не знаю что там за проблемы с управляемыми формами; пока выглядит как явно предвзятое отстранение прямого стороннего конкурента; думаю можно было бы замерить и им тоже, если там уж явно есть косяки с упр формами - то взяли бы примера ещё и другу конфигурацию без упр форм - правда такую поискать надо - сейчас в типовых почти везде есть хотя бы несколько уро. форм, даже в неуправляемых конфигурациях). Вроде бы есть ещё несколько сторонних сервисов по выгрузки конфигурации в xml файлы.
2. Автор проверил выгрузку, но почему-то не протестировал загрузку, а это тоже важно!
3. Автор говорит об усилении роли внешних инструментов в обработке исходников конфигураций 1С. В таких сценариях часто происходит не полная выгрузка/загрузка, а частичная синхронизация (и у 1С есть поддержка такого режима, в т.ч. с автоанализом изменившихся файлов) - вот в таком режиме было бы неплохо тоже протестировать. В том числе при пакетной работе (несколько выгрузок/загрузок) - тут, думаю, Агент конфигуратора проявит себя более эффективно, так что сбрасывать со счетов его не стоит.
А то получается в статье большая её часть собственно не посвящена непосредственно самим тестам - и было бы правильно её дополнить именно информацией по расширенным тестам!
(4) Спасибо за такой подробный комментарий.
1. Если я ничего не путаю, то precommit1C :
-- раpбирает конфигурацию в свой формат, отличный от формата 1С-XML
-- формат precommit1C не иерархический а линейный
2, 3 Скрипт для тестирования выгрузки, как учебный пример, помог мне прикоснуться к Исполнителю. Я попробовал его в деле решая реальную задачу. Результат этого эксперимента - понимание, того, что исполнитель вполне удобный и мощный инструмент. Вряд ли я буду развивать тему сравнения платформ, цели такой не было. Однако, я точно буду использовать Исполнитель для реальной автоматизации разработки. И вот этими скриптами, думаю можно и нужно будет поделиться.
1. Если я ничего не путаю, то precommit1C :
-- раpбирает конфигурацию в свой формат, отличный от формата 1С-XML
-- формат precommit1C не иерархический а линейный
2, 3 Скрипт для тестирования выгрузки, как учебный пример, помог мне прикоснуться к Исполнителю. Я попробовал его в деле решая реальную задачу. Результат этого эксперимента - понимание, того, что исполнитель вполне удобный и мощный инструмент. Вряд ли я буду развивать тему сравнения платформ, цели такой не было. Однако, я точно буду использовать Исполнитель для реальной автоматизации разработки. И вот этими скриптами, думаю можно и нужно будет поделиться.
Антивирус отключали на время выгрузки? По моему опыту он влияет очень сильно на скорость загрузки/выгрузки такого количества мелких файлов. Но скорость выгрузки не самая проблемная часть во всем этом. Самое тяжелое это когда запускаешь трехстороннее объединение с файлом обновления, вот тут и 2 часа может идти сравнение.
(16) Использую Git и mergetool (2 штуки). Это эффективней в любом случае, т.к. сравнить и объединить можно даже то, что не дает сделать конфигуратор. А главное это промежуточное сохранение и возврат к процессу объединения в любой момент без необходимости запускать сравнение заново. Ни конфигуратор ни EDT не могут эффективно справляться с задачей обновления таких конфигураций как ERP. Плюс поведение конфигуратора при сравнении не всегда очевидное, в зависимости от релиза платформы появляются сюрпризы. Т.ч. делаем объединение через гит, а затем запускаем контрольное сравнение через конфигуратор, сначала с конфигурацией поставщика, а затем со старой конфигурацией, чтобы убедиться что не забыли никаких реквизитов документов или не сократили набор составных типов. Главное помнить, что конфигурация из демо-базы не подходит для объединения и обновления. Уже не раз сталкивался с тем, что конфигурация демо-базы отличается от конфигурации оригинальной конфигурации поставщика. Ну и допиливание роли ПолныеПрава головнняка преподносит.
А и еще один плюс - даже если начали процесс объединения месяц назад и весь месяц коллега допиливал рабочую базу, то его доработки потом очень легко и быстро докидываются после полного мержа. Часто даже на автомате, без необходимости решать мерж конфликты. Конфигуратор так не умеет.
А и еще один плюс - даже если начали процесс объединения месяц назад и весь месяц коллега допиливал рабочую базу, то его доработки потом очень легко и быстро докидываются после полного мержа. Часто даже на автомате, без необходимости решать мерж конфликты. Конфигуратор так не умеет.
Тесты плохие, только на скорость, без проверки качества. Не сделано самого интересного - сравненение загруженных из XML конфигураций с эталонной выгрузкой в CF с выводом в диаграмму количества расхождений.
Кто хоть раз делал такое тот поймёт. На ЗУП это особенно хорошо проявляется.
Кто хоть раз делал такое тот поймёт. На ЗУП это особенно хорошо проявляется.
(25) "покорёжено" - что обозначает этот термин?
Если я прогоню конфигурацию через преобразование CF v.1 -> XML -> CF v.2 , то, не смотря на то, сто CF v.1 и CF v.2 отличаются, как будет вести себя CF v.2?
-- не будет запускаться в пользовательском режиме?
-- не будет запускаться в режиме конфигуратора?
-- некоторые алгоритмы будут работать по другому?
-- некоторые формы, макеты, роли... будут работать и выглядеть по другому?
На все вопросы ответ один, конфигурация CF v.2 будет вести себя корректно, равно как и конфигурация CF v.1
Bторой момент, методологический.
Раз уж вы сделали преобразование CF v.1 -> XML, то все дальнейшие сравнения и объединения конфигураций проводите только с XML.
Преобразование XML -> CF v.2 нужно только для одной задачи, а именно накатить обновление на информационную базу.
Нет такой нужды или задачи, что бы сравнивать CF v.1 и CF v.2. Или я не знаю такую задачу.
Если я прогоню конфигурацию через преобразование CF v.1 -> XML -> CF v.2 , то, не смотря на то, сто CF v.1 и CF v.2 отличаются, как будет вести себя CF v.2?
-- не будет запускаться в пользовательском режиме?
-- не будет запускаться в режиме конфигуратора?
-- некоторые алгоритмы будут работать по другому?
-- некоторые формы, макеты, роли... будут работать и выглядеть по другому?
На все вопросы ответ один, конфигурация CF v.2 будет вести себя корректно, равно как и конфигурация CF v.1
Bторой момент, методологический.
Раз уж вы сделали преобразование CF v.1 -> XML, то все дальнейшие сравнения и объединения конфигураций проводите только с XML.
Преобразование XML -> CF v.2 нужно только для одной задачи, а именно накатить обновление на информационную базу.
Нет такой нужды или задачи, что бы сравнивать CF v.1 и CF v.2. Или я не знаю такую задачу.
(29) Ну вы сами все тесты проводили с базой ЗУП. Это значит что доработки выполняются со вскрытием замка (иначе зачем его выгружать), и естественно эта база требует постоянного обновления. С тотально расходящимися объектами трудозатраты на обновление растут в десятки раз.
То есть мораль проста - если база своя самописка, то наверно можно применять XML. Хотя на чем основывается уверенность что проблем не будет не ясно. Лично я вообще не уверен ни насчет существования проблемы, ни насчет его отсутствия. Если же сопровождаете "вкрытую" типовую требующую обновлений, то будут очень неприятные сюрпризы
То есть мораль проста - если база своя самописка, то наверно можно применять XML. Хотя на чем основывается уверенность что проблем не будет не ясно. Лично я вообще не уверен ни насчет существования проблемы, ни насчет его отсутствия. Если же сопровождаете "вкрытую" типовую требующую обновлений, то будут очень неприятные сюрпризы
(29) "некоторые формы, макеты, роли... будут работать и выглядеть по другому"
Неоднократно сталкивался с проблемами при загрузке конфы из XML, на разных версиях платформы приколы разные.
Из последнего, например - "слетала" привязка обработчиков форм к событиям. То есть, сам код на месте, а привязки нет и он не отрабатывает, соответственно. А задача - из дев-ветки в прод-ветку черри-пиками подтягивались коммиты по принятым в релиз задачам (с ручной обработкой конфликтов человеком - релиз-инженером). В итоге, из-за таких вот косяков платформы пришлось отказаться от этой схемы сборки релиза, хотя она успешно применялась какое-то время и даже была несколько автоматизирована с помощью специальной обработки
Так что да, мне понятна "боль" комментатора выше, когда нужно сравнить cf_1 и cf_2, чтобы убедиться, что в cf_2 ничего не сломалось
Неоднократно сталкивался с проблемами при загрузке конфы из XML, на разных версиях платформы приколы разные.
Из последнего, например - "слетала" привязка обработчиков форм к событиям. То есть, сам код на месте, а привязки нет и он не отрабатывает, соответственно. А задача - из дев-ветки в прод-ветку черри-пиками подтягивались коммиты по принятым в релиз задачам (с ручной обработкой конфликтов человеком - релиз-инженером). В итоге, из-за таких вот косяков платформы пришлось отказаться от этой схемы сборки релиза, хотя она успешно применялась какое-то время и даже была несколько автоматизирована с помощью специальной обработки
Так что да, мне понятна "боль" комментатора выше, когда нужно сравнить cf_1 и cf_2, чтобы убедиться, что в cf_2 ничего не сломалось
(25) а теперь можешь выгрузить CF_2 на исходники и сравнить их с результатом первой выгрузки?
Сравнить, например, тем же kdiff3
Есть подозрение, что там просто некоторые свойства поменяны местами и/или какие-то свойства по-умолчанию просто не выгружались/загружались
Сравнить, например, тем же kdiff3
Есть подозрение, что там просто некоторые свойства поменяны местами и/или какие-то свойства по-умолчанию просто не выгружались/загружались
(34) Да лезть, раз IDE это не показывает. Да - в этом есть некоторое неудобство - но не оно на самом деле надуманное - ситуаций, где конкретизации окончания блока вида "КонецЕсли" "КонецЦикла" реально пригодились бы в чтении кода, не так и много.
А вообще - практика "чистого кода" декларирует правило не писать длинные блоки кода и блоки большой вложенности - проводя декомпозицию кода. Тогда любой блок кода должен условно помещаться примерно "на один экран" листинга, а число вложений (локальных блоков кода; обычно тривиальные 1-2 инструкции вложения не учитывают) не должно быть больше 4-5. Вот эти правила (а не именованные индивидуальные концевики) повышают читаемость кода. Хотя и являются, в общем-то, спорными, т.к. требуют большей упаковки кода в функции, т.е. сокрытия реализации вообще от беглого просмотра. Но всё-равно, это лучше, чем простыни блоков на несколько экранов с неимоверным уровнем вложенности, да ещё и без поясняющих комментариев.
В остальном современная IDE должна интерактивно показывать и границы блоков, и что какой было начало у блока, уметь их сворачивать и разворачивать, и уметь быстро показывать содержимое функции и/или её описание, без смены основной позиции просмотра кода
А вообще - практика "чистого кода" декларирует правило не писать длинные блоки кода и блоки большой вложенности - проводя декомпозицию кода. Тогда любой блок кода должен условно помещаться примерно "на один экран" листинга, а число вложений (локальных блоков кода; обычно тривиальные 1-2 инструкции вложения не учитывают) не должно быть больше 4-5. Вот эти правила (а не именованные индивидуальные концевики) повышают читаемость кода. Хотя и являются, в общем-то, спорными, т.к. требуют большей упаковки кода в функции, т.е. сокрытия реализации вообще от беглого просмотра. Но всё-равно, это лучше, чем простыни блоков на несколько экранов с неимоверным уровнем вложенности, да ещё и без поясняющих комментариев.
В остальном современная IDE должна интерактивно показывать и границы блоков, и что какой было начало у блока, уметь их сворачивать и разворачивать, и уметь быстро показывать содержимое функции и/или её описание, без смены основной позиции просмотра кода
Скажите, вот это у вас прям работает с ожиданием выполнения?
Почему это дерьмо у меня пролетает за секунду без ожидания, а только потом конфигуратор сам себе запускается и чото делает?!!!
пер ВремяСтарта: Время = Время.Сейчас()
Конфигуратор.Запустить()
Конфигуратор.ОжидатьЗавершения()
пер ВремяЗавершения: Время = Время.Сейчас()Почему это дерьмо у меня пролетает за секунду без ожидания, а только потом конфигуратор сам себе запускается и чото делает?!!!
(39) Сам себе отвечу. Ошибка банальная, но не очевидная. Скрипт с ожиданием едет лесом, если запускать им исполняемый файл стартера C:\Program Files\1cv8\common\1cestart.exe, что допустимо в иных сценариях и мегаудобно, чтобы не выбирать версию платформы. В случае с ожиданием завершения нужно обращаться напрямую к 1cv8.exe.
Вакансии
Ведущий разработчик 1С / Team lead отдела разработки 1С
Москва
зарплата от 300 000 руб. до 300 000 руб.
Полный день
Москва
зарплата от 300 000 руб. до 300 000 руб.
Полный день