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

05.06.20

Управление проектом

При адаптации типовой конфигурации под особенности учета в компании важно обеспечить возможность легкого обновления поставки. Как организовать архитектуру решения и продумать процесс быстрой и эффективной разработки без ущерба типовой функциональности, на конференции Infostart Event 2019 Inception рассказал ведущий программист компании BIA-Teсhnologies Алексей Князьков.

Добрый день, меня зовут Князьков Алексей. Я программист 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.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2779    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14310    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5856    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4706    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2750    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4188    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10682    0    biimmap    79    

75

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13096    0    Evil Beaver    17    

117
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Yashazz 4709 05.06.20 15:30 Сейчас в теме
Столько букаф и картинок, когда хватило бы одной фразы: впаяли самописную подсистему и расширение в типовую конфу, постаравшись сделать минимум головняка при обновлениях. Без умствований, понтов и разлития воды это так. Хотя кем надо быть, чтоб нарваться в самописке на конфликт с именами типовой, я хз. Ну, мастера профи, чо. Архитекторы) Дальше что? Натолкнулись на грустную реальность, наваяли свою сравнивалку, молодцы, таких уже зоопарк, докучи ещё одна. Всё вместе - помесь ежа с ужом и трепотня вокруг неё, но как презентация выглядит понтово и круто.
roman72; Irwin; klaus38; AKnyazkov; kuzyara; t278; it_tungus; papche; +8 1 Ответить
2. roman72 379 12.06.20 21:54 Сейчас в теме
Интересно, с точки зрения автора в чём причина проблем с именованием объектов в самописной части и в типовой. Понимаю, что это может быть наследство доисторических разработок и таких же людей, но на ваш взгляд в чем причина совпадения имён. И в чём сложности провести отдельным проектом корректировку имён?
3. AKnyazkov 54 15.06.20 14:55 Сейчас в теме
(2) Тут все дело в том, что добавляется еще одна поставка. Поставка собственной БСП, на которой построено множество информационных систем компании. И просто взять и переименовать "свои" объекты не такая простая задача как кажется.
4. RustIG 1382 12.03.21 06:27 Сейчас в теме
(0) рабочих примеров мало...
после прочтения остается ощущение недопонимания - вроде коллеги (>15 человек) сумели организовать процесс разработки внутри своей компании, где все наработки годами накапливались и отлаживались....наверное есть несколько коллег, которые знают систему от А до Я...
но передать этот опыт другим коллегам как-то не получилось....другая группа разработчиков если захочет внедрить что-то подобное, начнет с азов и пройдет все этапы граблей...
Оставьте свое сообщение