Size: a a a

1С, БСП, DevOps и Архитектура

2021 August 11

NG

Nikita Gryzlov in 1С, БСП, DevOps и Архитектура
в корне репозитория
источник

Е

Евгений in 1С, БСП, DevOps и Архитектура
вот я не пойму почему такие крайности или ломать типовое или всё в расширение или +100500 расширений? Почему нельзя действовать проще - все данные(реквизиты, объекты, нетиповые модули) делаются в конфе, а изменения форм и модулей типового делаются в расширении с дерективой &ИзменениеИКонтроль. Тогда и проверка сводится к просмотру ошибок(в нормальном состоянии их нет) и сравнение работает вполне комфортно и обновление больше похоже на типовое..
источник

K

KovAlexey in 1С, БСП, DevOps и Архитектура
Да в целом такой подход неплох был бы. Если бы EDT был законченным продуктом
А так все равно. Как не крути, сейчас просто нет удобного решения, которое бы позволяло держать и расширения, и доработки типовой в консистентном состоянии
А проверять на такие ошибки уже на уровне сборки той же из сорцов и тестов - уже слишком поздно

Но это уже мое имхо. Сейчас просто не видно целостной картины в случае работы в конфигураторе.
источник

Е

Евгений in 1С, БСП, DevOps и Архитектура
а при чем тут EDT, конечно понимаю - интересное решение, но я пользуюсь конфигуратором, в котором это всё удобно сделано: подключаем Araxis Merge в настройках сравнения и все изменения и ошибки выводим в трехсторонее сравнение  - объединяем и полученное добавляем в расширение... ну а типовое обновление - просто проверяем, на наличие двоеного изменения(что вряд ли есть при правильном подходе)
источник

K

KovAlexey in 1С, БСП, DevOps и Архитектура
как вы конфу сравниваете с расширением в конфигураторе?
источник

Е

Евгений in 1С, БСП, DevOps и Архитектура
единственное неудобство это надо обновлять формы в расширений, если они изменились - с этим да - не очень удобно
источник

Е

Евгений in 1С, БСП, DevOps и Архитектура
&ИзменениеИКонтроль
источник

Е

Евгений in 1С, БСП, DevOps и Архитектура
расширение несёт изменение только модулей типовых
источник

Е

Евгений in 1С, БСП, DevOps и Архитектура
с этой директивой при проверке у вас отобразиться ТОЛЬКО изменения затронувшие ваши расширения, при помощи программки сводите и применяете и всё готово..
источник

K

KovAlexey in 1С, БСП, DevOps и Архитектура
Вот этот момент и приносит мало удовольствия
источник

K

KovAlexey in 1С, БСП, DevOps и Архитектура
как и этот. Фактически свел на нет все плюсы
источник

K

KovAlexey in 1С, БСП, DevOps и Архитектура
я такую же схему предлагал и продвигал у нас. Сам же стал ее противником спустя пол года..Сейчас стараемся все изменения на формах делать исключительно програмно. А код мержить при обновлении - дело простое
источник

Е

Евгений in 1С, БСП, DevOps и Архитектура
какое неудобство - если у вас есть три окна где всё легко сводится и сравнивается?
источник

Е

Евгений in 1С, БСП, DevOps и Архитектура
формы - да - надо перепроверять, но и так вам это надо будет делать..
источник

K

KovAlexey in 1С, БСП, DevOps и Архитектура
фактически это делают тесты
Программное редактирование моментом приводит к ошибкам
источник

Е

Евгений in 1С, БСП, DevOps и Архитектура
ИМХО оптимальный подход к разработке без использования недоработанной EDT, и модных Git//
источник

K

KovAlexey in 1С, БСП, DevOps и Архитектура
То, что я не могу взять и указать конфигуратору сравника мне вот этот модуль\функцию в нем с типовой и покажи диффы
Мне нужно откопировать в стороннее приложение код, сравнить, потом копировать обратно. Это и неудобно
источник

Е

Евгений in 1С, БСП, DevOps и Архитектура
🤦🏼‍♂️😁 как бы это автоматизировано..) он сам всё заполняет в настройках указываете и после этого по одной кнопке он сам берет типовой код и сравнивает с вашим
Добавлю строку настроек для трехстороннего сравнения: /wait /3 /merge /a1 /title1:%oldVendorCfgTitle /title2:%baseCfgTitle /title3:%secondCfgTitle %oldVendorCfg %baseCfg %secondCfg %merged
источник

K

KovAlexey in 1С, БСП, DevOps и Архитектура
у расширения?
источник

K

KovAlexey in 1С, БСП, DevOps и Архитектура
с конфой?
источник