Мастер-класс "Ведение проектов в типовых конфигурациях 1С"

Добрый день, меня зовут Князьков Алексей. Я программист 1С в компании BIA-Technologies, работаю в отделе системной архитектуры.

Несколько лет назад заказчик поставил перед нами задачу перевести учет с ЗУП 2.5 на ЗУП 3.1. И сейчас я расскажу про те подходы, которые мы выработали для разработки этого проекта, чтобы сохранить возможность легкого обновления поставки типового решения.

Начальные условия

Что было вначале:

• старая, сильно переписанная ЗУП 2.5;
• команда разработчиков, которая до этого работала только в 8.2 с хранилищем (никакого GIT у нас не было);
• и задача перейти на ЗУП 3.1.

Задача была:

• разработать решение на основе ЗУП 3.1 и встроить его в существующий ИТ-ландшафт;
• перевести процесс разработки из хранилища в Git и научить программистов работать с этим.

Архитектура решения: ЗУП 3.1 + Расширение + БСП-МИНИ

Перед тем, как приступить к этому процессу, была тщательно продумана архитектура – мы договорились сделать коробочное решение, потому что юридических лиц, в которых требовалось внедрять ЗУП 3.1, было несколько. И была придумана следующая конструкция:

• оставить поставку 1С;
• сделать еще вторую поставку БСП-МИНИ;
• и основную разработку вывести в расширение.

Про поставку БСП-МИНИ сейчас расскажу поподробнее, что это такое.

БСП – это библиотека стандартных подсистем.

• У 1С есть своя собственная БСП, на основе которой строится большинство типовых решений фирмы «1С».
• И в нашей компании есть своя собственная БСП, на основании которой строится большинство решений на 1С. Это связано с тем, что есть какая-то общая функциональность, которая должна присутствовать во всех этих системах. В том числе и для интеграции, и для многого чего другого. Наша БСП в чистом виде не может быть встроена в типовую конфигурацию по причине банального конфликта в именах объектов, в названиях методов и в пересечении модулей (там есть свои собственные модули параметров сеанса, модуль приложения и пр.).
• А БСП МИНИ таких модулей не содержит, и параметров сеанса вообще не содержит. Она содержит только необходимый минимум от большой БСП и собирается автоматически скриптами по определенным правилам. То есть при выпуске релиза нашей БСП автоматически собирается БСП МИНИ. Это конфигурация, которая создана специально для того, чтобы вставать на вторую поставку в типовые конфигурации фирмы «1С».

Конфигурация «Дополнительные объекты»

Проект, о котором я рассказываю, мы начали несколько лет назад, и тогда расширения были не такими мощными, как сейчас.

Поэтому, когда в процессе внедрения выяснилось, что в расширение нельзя добавлять все объекты, которые хочешь, мы придумали следующую конструкцию – в БСП МИНИ требовались еще дополнительные объекты, из которых мы сделали полностью автоматическую сборку БСП МИНИ HRM.

Дополнительные объекты – это еще одна конфигурация, которая не содержит никакого кода, никакой логики. Разработчики добавляют туда объекты, которые должны присутствовать в основной конфигурации – например, регистры накопления, документы, справочники. Это базовые объекты, поведение которых уже переопределяется в расширении – они должны просто присутствовать в основной конфигурации.

Сборка БСП МИНИ HRM отличается от классического Git Flow. Процесс построен как GitHub Flow или rolling release (непрерывные релизы).

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

• из репозитория закачивается исходный код актуальной версии БСП МИНИ;
• берется исходный код дополнительных объектов;
• и собирается третья конфигурация – БСП МИНИ HRM.

При сборке собираются соответствующие артефакты, и этот же ответственный человек обновляет поставку в основной конфигурации.

Изменения в процессе командной разработки

Что же произошло с командой за это время?

• Был написан специальный курс по обучению Git (step-by-step).
• Также было заведено специальное пространство в Confluence, где была собрана вся необходимая документация с описанием процесса разработки, а также наиболее частые вопросы и ответы.
• Организован общий канал в корпоративном чате для этой команды разработчиков – для решения всяких оперативных задач.
• Изменен flow у задач Jira в проекте. Добавлены новые статусы – например, Code Review.
• Разработка полностью переведена в Git. Изначально было так задумано, что сами разработчики не закрывают фича-ветки, они отправляют мерж-реквест, который проходит ревью, тестируется и после этого принимается, а ветка закрывается (уже другими ответственными людьми, которые имеют право закрывать мерж-реквесты).

Сборка и тестирование расширений в рамках CI/CD

Изменен конвейер сборки CI/CD. До этого у нас не было проектов, которые бы использовали в процессе разработки расширения. Соответственно, конвейер CI/CD научили собирать и тестировать расширения (их для конфигурации может быть больше одного). Это тоже интересный опыт.

Протестированные расширения автоматически собираются, артефакты складываются в ту же папку (у нас под это придумана специальная иерархия).

Проблемы использования расширений

Но с расширениями не все гладко – есть определенные проблемы, которые не описаны на ИТС и в других источниках:

• Например, при изменении состава общих реквизитов. При первом добавлении общего реквизита мы прошли целый квест – ушло буквально несколько дней. Как же корректно ввести в расширение общий реквизит? Для этого нужно поставить у этого общего реквизита флаг «Автоиспользование», выбрать значение и поставить для него флаг «Использовать». А потом снять флаг «Автоиспользование». После этого общий реквизит добавляется в расширение
• Поскольку конфигурации вендора были в режиме совместимости, а нам от режима совместимости в наших проектах пришлось отказаться, пришлось вносить вынужденные патчи в конфигурацию поставщика. Это было связано с тем, что в конфигурации ряд процедур назывался точно так же, как в платформе. И еще было много других несовместимых вещей, которые приходилось патчить, чтобы конфигурация работала корректно. Все эти патчи были соответствующим образом оформлены, чтобы при следующем обновлении релиза поставщика их не потерять.

Проблемы работы в Git

В Git тоже не все шло гладко изначально.

• Например, очень плохо мержатся файлы XML. Особенно это критично для главного файла Configuration.xml, который содержит информацию обо всей конфигурации. При слиянии нескольких веток бывает, что некоторые строчки задваиваются (или наоборот, какие-то удаляются), или сдвигаются. Проблема решается использованием прекоммита – скрипта, который устанавливается локально на каждый компьютер разработчиков, чтобы соответствующим образом обрабатывать файлы при коммите в Git.
• Также мы столкнулись с еще одной интересной проблемой – перевода строк. Это болезнь типовых конфигураций. Проблема решается корректной настройкой .gitattributes. В чем заключается проблема? В типовых конфигурациях, в частности, в «1С:Бухгалтерии», запросы выковыриваются из схемы компоновки данных, определенным образом парсятся, собираются третьи запросы и потом строятся отчеты, в которых используется такая дикая схема. При парсинге этих запросов используется разделитель строк Символы.ПС. Если собрать конфигурацию, где .gitattributes настроен как CRLF (Символы.ПС+Символы.ВК), такие запросы корректно не собираются. Соответственно, нам нужно для xml-файлов настроить, что там не CRLF, а CR.
• Еще одна проблема связана с изменением регистра букв при переименовании файла – тоже встретилась в типовой конфигурации. И первый раз, чтобы разобраться, у нас это тоже заняло буквально пару дней. Переименовали макет в регламентированных отчетах (было «квартал1», стало «Квартал1» – буква «к» сначала была маленькой, потом сделали ее большой). Такие изменения невозможно закоммитить в Git, но проблема в том, что Windows считает, что это один и тот же файл, а Git пришел из мира Linux – он считает, что это разные файлы. Соответственно, закоммитить не дает. Решается так – сначала файлы удаляются, делается коммит, потом файлы восстанавливаются, делается коммит. Потому что средствами Git такие файлы переименовать не получится.

Проблемы интеграции

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

Тема очень много обсуждалась на форумах, но так и осталось. У нас Enterprise-решение, и используется как ЗУП КОРП, так и ЗУП ПРОФ. Конечные юрлица работают в ЗУП ПРОФ, и документы должны корректно ходить между разными системами, корректно заполняться, обрабатываться и рассчитываться.

Варианты решения:

• дублирование функциональности в обработках;
• либо отложенная обработка документов на клиенте – остаются непроведенные документы, и написан АРМ для специально выделенного человека, куда выводятся эти документы, он должен нажать кнопку, чтобы эти документы обработались в режиме клиента.

Дублирование функциональности в обработках – схема довольно успешная, она у нас работает. Но она накладывает определенные издержки на содержание этих обработок, потому что из релиза в релиз эти функции могут меняться.

Дальше расскажу, как мы с этой проблемой разобрались.

Проблемы обновления поставок 1С

Обычно расширение не содержит новую функциональность, оно переопределяет уже существующую функциональность основной конфигурации. В том числе, процедуры, функции и другие объекты.

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

В том числе отслеживание изменений в этих обработках, которые содержатся в модулях форм документов, которые мы вынесли в обработки.

Diff3cf

Было разработано специальное консольное приложение, которое мы называли Diff3cf. Это приложение сконструировано на базе OneScript, оно позволяет делать трехстороннее сравнение модулей основной конфигурации, конфигурации поставки (развернутой в исходники) и исходников расширения.

Делает анализ и выдает соответствующий отчет.

В том числе, на этом примере видно, как выглядит сравнение, если в обработке ПечатьКадровыхПриказов переопределена функция ПолучитьДанныеДляПечатиКадровогоПриказаТ1.

Такие обработки должны быть соответствующим образом промаркированы (у них в комментариях написано, какую форму и какой модуль они переопределяют). Если это, допустим, модуль из формы документа расчета зарплаты, то у него в комментариях будет написано – ДокументРасчетаЗарплаты, форма такая-то для того, чтобы это приложение могло найти эту обработку и сравнить ее с тем кодом, который поменялся в новой поставке (либо вообще в новом релизе удалили эту процедуру).

Цветом выделяются те строчки, которые добавились или удалились (как в KDiff).

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

В блоке с расширением всегда показывается тег «&Вместо», «&После» или «&Перед». Даже если тегов явно не стоит, приложение все равно находит, что это за переопределение, чтобы при анализе этого отчета было легче принять решение по этому участку кода. К сожалению, мы пока не придумали такое приложение, которое бы делало какой-то анализ логики и самостоятельно подсказывало те решения, которые нужно предпринять.

По проторенной дорожке

Появление приложения Diff3cf позволило сократить время поднятия релизов от нескольких дней до нескольких часов – вместе с анализом тех изменений, которые сделаны в расширении по отношению к конфигурации поставщика.

Здесь я еще не рассказал про поставку БСП МИНИ. Блок, который касается БСП МИНИ, не переопределяется, потому что такой надобности нет. Там в основном вся функциональность имеет общее назначение – там есть интеграционные блоки, блоки уведомления и прочие, которые нет надобности переопределять в расширении.

Таким образом, был разработан не просто какой-то новый способ разрабатывать в типовой конфигурации (это один из способов разработки в типовых конфигурациях 1С), а была разработана целая методика вместе с документацией, с подходами, с вопросами/ответами и их решениями.

Методика комплексная, делалась не один день. И эта же методика была перенесена на другие проекты компании со своими особенностями – такие, как Бухгалтерия, ERP и другие, которые базируются на базе типовых решений 1С.

Почему я большей частью рассказывал про ЗУП 3.1? Просто там проект самый крупный, в нем больше всего изменений, и мы больше всего этих моментов выловили.

Опять же, я рассказал не про все проблемы – только про те, которые наиболее запомнились, с которыми больше всего «бились».

Итоги

Что в итоге?

• Вырос профессиональный уровень команды, преобразования пошли на пользу. Эта практика с code review повысила общий уровень команды – все в курсе всего, что происходит. Люди, которые проводят Code review, постоянно меняются. Сегодня ты проверяешь код одного человека, завтра – другого человека. Назначение происходит рандомно внутри команды.
• Развитие инструкций и документации. Изначально это была инициатива одного человека, сейчас документацию составляют и поддерживают в актуальном состоянии наиболее компетентные люди. Она постоянно востребована в Confluence.
• Итерации по обновлению релизов стали вполне будничными и не занимают столько времени, сколько раньше. За два дня можно обновить конфигурацию на 10 релизов. И при этом мы не потеряли ни одного вынужденного патча. С помощью отчета были описаны все критичные места обновления и своевременно сформированы задачи на доработку – назначены ответственные разработчики.

Приложение diff3cf выложено на GitHub https://github.com/bia-technologies/diff3cf, можете скачать и ознакомиться, если кому-то интересно.

Вопросы

• Про инструментарий можете подробнее рассказать? Как вы с Git работаете?
• С Git мы работаем с помощью Git Extensions. Также у нас работают скриптовые приложения – прекоммит, конвейер CI/CD.
• С EDT работаете?
• Когда мы переходили на ЗУП 3.1, EDT была совсем сырая. EDT имеет смысл большей частью для таких проектов, когда нужно загружать исходники основной конфигурации. У нас на проекте основная конфигурация меняется очень редко – только тогда, когда выходит релиз БСП МИНИ, либо когда обновляются релизы вендора. И разработчикам загружать всю эту основную конфигурацию к себе нужно довольно редко (1-2 раза в месяц). Основная разработка ведется в расширении, а оно загружается в конфигурацию за пару минут. Есть планы перейти на EDT, мы его тестируем, пишем для него плагин. Сейчас описываем всю эту методику, чтобы портировать его на команду разработчиков. Но на этом проекте нам пока не до EDT – у нас идет завершение очередного этапа и там пока большой необходимости в EDT нет.
• У вас на слайде есть лейбл SonarQube, но вы ничего не сказали по поводу статического анализа кода, как вы его проводите, проводите ли еще автотесты и разворачивали ли pipeline сборки.
• Да, у нас все проекты проходят проверку сонаром. В том числе и типовые. В том числе и расширение тоже. И в расширении можно увидеть техдолг, который образовался и т.д. У меня доклад не про конвейер сборки, не про CI/CD, об этом расскажет Валерий Максимов. У меня тема о том, как мы придумали разрабатывать в типовых решениях так, чтобы ничего не сломалось, и потом быстро обновляться. Про конвейер сборки я упомянул только один раз, когда сказал, что мы его перенастроили для сборки и тестирования расширений.
• А автотесты используете?
• У нас здесь пока только синтаксический контроль. А автотесты пока в стадии становления – не на всех проектах есть, до проектов на базе типовых мы пока не добрались. Кстати, там пришлось поотключать очень много тестов, потому что типовые конфигурации не все тесты проходят.
• Как себя проявляет приложение Diff3cf при обновлении ERP?
• Хорошо проявляет – у нас этому проекту уже больше года.
• Сколько времени занимает обновление ERP?
• Обычно за день обновляется. Больше всего времени занимает процесс загрузки и выгрузки из исходников – до нескольких часов доходит. Само обновление за полчаса, не больше. Долго загружается, потом обновляешься, проверяешь, потом долго выгружаешь.

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.