Как выжить, если у тебя в базе 1С 50+ расширений

Меня зовут Юрий Былинкин, я работаю архитектором 1С в компании Аскона.

Компания Аскона – это не только магазины, которые есть в каждом торговом центре, но и огромное производство. Я работаю в подразделении, которое обслуживает производство.

Не так давно мы перешли с УПП на ERP и нам пришлось значительно дорабатывать функциональность конфигурации. Было много задач, которые, помимо наших программистов, выполняли различные подрядчики, их было очень много.

В какой-то момент, когда я заглянул в список расширений в нашей рабочей базе, мне пришлось его долго прокручивать, чтобы дойти до конца. На тот момент у нас было 54 расширения.

Расширения – преимущества и недостатки

Расширения – это вообще хорошо, это все знают. Я до сих пор остаюсь фанатом расширений.

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

• Когда мы дорабатываем расширение, мы просто кидаем файл аналитику или пользователю (в зависимости от того, кто тестирует). Он устанавливает расширение в режиме 1С:Предприятие, перезаходит и все, можно тестировать.

• На продуктиве разворачивать расширение тоже очень просто – никаких сравнений, объединений не требуется. Все очень быстро.

• Расширения просто администрировать – в пользовательском режиме ERP есть интерфейс для работы с расширениями, в котором их можно устанавливать, удалять, обновлять.

Но в то же время, когда расширений стало так много, я лично на себе почувствовал, что это не очень хорошо.

Я тут перечисляю некоторые недостатки:

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

• Альтернатива инструкции &Вместо – инструкция &ИзменениеИКонтроль. Ее использовать тоже не очень хорошо, потому что &ИзменениеИКонтроль нужно контролировать.

• Еще один недостаток – отсутствие инструкций препроцессора при захвате процедур и функций.

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

Давайте рассмотрим подробно.

&Вместо – зло

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

Мы пытались с этим бороться следующим образом: на этапе подготовки к релизу просматривали все заимствования «Вместо» и анализировали, правильно ли это, нужно ли это заимствование вообще. Но это увеличивало время подготовки обновления, и в конце концов мы от этого отказались. Мы просто решили, что инструкцию &Вместо мы не будем использовать.

Мы используем плагин для SonarQube от компании «Серебряная пуля» и просто добавили в него свое правило, которое выдает предупреждение, если кто-то в расширении использует инструкцию &Вместо.

Чуть позже мы это правило доработали: поняли, что наиболее частый вариант использования &Вместо – это когда мы проверяем параметры, переданные в процедуру или функцию, и в случае наличия там нужных нам параметров делаем свой вызов. А если это не случается, мы просто делаем «ПродолжитьВызов()».

На экране показано, как мы модифицировали правило. В плагине для SonarQube от «Серебряной пули» есть возможность использовать свои правила проверки, написанные на языке XPath. Пришлось его немного изучить, но результат того стоил. Сейчас если кто-то использует &Вместо и не добавляет в код ПродолжитьВызов() – ему приходит замечание.

&ИзменениеИКонтроль – как контролировать, если текст модуля изменился

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

Мы сделали парсер журнала регистрации на предмет поиска таких событий. И сейчас с этим справляемся. В перспективе хочется не искать проблему, которая возникла уже на рабочей базе, а просто добавить проверку в АПК, которая передаст результат в Sonar.

Мы АПК используем только для выполнения проверок и передачи результата.

Отсутствие инструкций препроцессора при захвате процедур

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

#Если Сервер ИЛИ ТолстыйКлиентОбычноеПриложение ИЛИ ВнешнееСоединение Тогда

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

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

Как мы это решили?

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

Сложное администрирование большого количества расширений – бардак

Почему вообще возникла проблема большого количества расширений?

Это произошло, потому что часто над исходными задачами у нас работали и наши программисты, и подрядчики. Иногда даже одновременно. Поэтому, например, у нас были расширения, которые назывались Аскона_Продажи и Подрядчик_Продажи.

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

Из-за этого у нас возникали необъяснимые проблемы, когда внезапно переставал работать код, который раньше работал. На самом деле, все вполне объяснимо, понятно, куда нужно смотреть, но это было очень неприятно, и не было инструментов, чтобы это отслеживать.

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

Что мы сделали?

• Мы запустили проект объединения расширений с одинаковой функциональностью – для удобства отказались от возможности давать подрядчикам работать в своих расширениях. Если возникает задача, которую должен кто-то решить, мы передаем подрядчику последний вариант этого расширения, и он над ним работает. У нас все расширения хранятся в справочнике «Файлы» программы СППР – «Система проектирования прикладных решений» от фирмы «1С». Там включено версионирование. В справочнике «Файлы» от СППР есть очень удобная фишка – когда человек редактирует файл, он его захватывает. У нас реализовано таким образом, что файлы расширений, над которыми в данный момент ведется работа, захвачены.

• Дальше – мы опять же написали отчет, показывающий, файлы каких расширений сейчас захвачены.

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

Следующая проблема – разворачивание расширений на продуктиве

Каждый день мы выпускаем наши внутренние релизы, которые состоят из 2-3-4-6 измененных расширений – у нас очень активно ведется разработка.

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

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

• В итоге мы немного доработали СППР. Теперь у нас расширения хранятся в справочнике СППР «Файлы» с историей версий. Кроме этого, мы добавили в СППР несколько регистров и возможность запрашивать установку расширения – на слайде видно, что можно запрашивать установку конкретной версии или просто последней версии.

На верхней картинке карточка файла с расширением.

На нижней картинке – рабочее место архитектора, из которого он видит те расширения, которые нужно установить.

Еще мы автоматизировали саму установку расширений. Зачем это делать вручную?

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

На верхней картинке видно, что у нас есть HTTP-сервис, который позволяет получать данные об установленных расширениях. Прямо в карточке расширения видно, какие версии сейчас установлены в каких базах.

И с помощью рабочего места архитектора мы так же нажимаем на одну кнопку, и с помощью HTTP-сервиса расширение устанавливается.

Актуальность расширений на продуктиве и в базах разработчиков

Установка – это одно, но мы как архитекторы не полностью контролируем свою базу. Любой человек с админскими правами (а такие кроме нас должны быть по ряду причин) может в рабочей базе изменить расширение. У нас не принято отлаживать код на рабочих базах, но раньше довольно часто встречалось такое, что программист подключается к рабочей базе в отладке и что-то меняет. И по факту мы видим, что внезапно в середине рабочего дня у нас в базе изменилось расширение.

Мы, опять же, это решили тем же самым HTTP-сервисом.

С его помощью мы получаем отчет, который показывает:

• какие расширения у нас в данный момент в СППР в разработке;

• какие расширения установлены;

• может быть, в какой-то базе вообще нет расширения – такое тоже допустимо.

Дальше – актуальность расширений в базах разработчиков. Это тоже была очень большая проблема.

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

Но нет, оказывается, ночью с этим расширением работал еще кто-то, и в СППР уже лежит новая версия.

Мы сделали для разработчиков сервисную обработку, которая в режиме 1С:Предприятие показывает актуальные расширения в рабочих базах и в СППР. С помощью этой же обработки можно скачать из СППР актуальное расширение и установить его к себе.

Итоги

Когда я понял, с какими проблемами мы столкнулись, я не верил, что их можно решить.

Я только верил, что нас спасет объединение расширений, что надо тупо волевым усилием сделать, чтобы их было меньше, и, наверное, все будет хорошо.

В итоге мы не только уменьшили количество, но и реализовали полезные фишки. На них мы затратили совсем немного времени – HTTP-сервис и обработки, с помощью которых СППР работает с расширениями ERP, мы разрабатывали меньше недели.

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

• Аналитикам и программистам мы тоже помогли, потому что у них всегда есть понятная картина – достаточно запросить установку расширения, и его установят. А если не установят, сразу видно, что оно еще не установлено.

• В целом, уменьшился бардак.

• И эти все мероприятия в итоге привели к тому, что количество программных и технических ошибок, связанных с расширениями, у нас уменьшилось.

И неудач – наверное, только одно.

• Проект объединения расширений нарушил принцип «Работает – не трогай!» и разработчики, которые занимались объединением расширений, столкнулись с тем, что причиной любой ошибки в программе все автоматически считали некорректный перенос кода из расширения в расширение. Хотя там ошибиться очень сложно, и всегда причинами ошибок были другие вещи.

Если эта тема окажется интересной, я планирую опубликовать на Инфостарте

• отчет для поиска ошибок отсутствия инструкций препроцессора;

• отчет по составу метаданных в расширениях, который нам помог понять, что где разрабатывать;

• HTTP-сервис для работы с расширениями и клиент для этого сервиса

Вопросы

Используете ли хранилище для разработки расширений? Из контекста доклада это было не очень понятно.

Так исторически сложилось, что мы начинали с релиза, который не поддерживал хранилище расширений. И до сих пор мы не используем хранилище, хотя думали об этом. В любом случае, количество расширений у нас в рабочих базах будет 20-25, потому что они разделены по функциональности. Это означает, что разработчик, если они у него все подключены, должен будет 25 раз подключаться к хранилищу при запуске конфигуратора. Я лично пробовал работать с хранилищем расширений, мне не понравилось – именно из-за того, что нужно подключаться. А одно расширение – это опасно. Если кто-то накосячит, а мы это пропустим, расширение не будет работать – это плохо.

А почему не Git?

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

У нас Git используется только для выгрузки изменений в исходный код и для анализа его в SonarQube. Классического использования Git у нас нет. У меня только в одной команде разработчики пробовали использовать ветки Git и собирать релиз из исходного кода в Git, а не напрямую в 1С. Почему-то люди пока еще не видят преимуществ этого подхода, а заставлять их я не хочу. И так хорошо.

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

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

Вы добавляете метаданные в основную конфигурацию или в расширение?

Мы добавляем метаданные исключительно в основную конфигурацию. Наша система репликации не позволяет работать с метаданными, добавленными в расширение. У нас используется система репликации от компании SoftPoint. Наверное, как и другие, она работает на таблицах SQL, и если мы добавим метаданные в расширение, и в одной из реплицированных баз оно применится, а в других по какой-то причине – нет (забыли установить или что-то сломалось), то новые таблицы, связанные с этими метаданными, появятся только в одной базе, и репликация встанет.

А как тестируете? Только ручное тестирование или есть автоматизация?

Автоматизация тестирования у нас в планах – собираемся использовать Vanessa Automation, но пока еще не начали.

Вы говорили про &ИзменениеИКонтроль, что проверяете наличие ошибок по журналу регистрации. А почему не запускаете автоматическую проверку применимости расширений в конфигураторе?

Действительно, вы правы, это можно автоматизировать.

В какое количество баз у вас вносятся расширения? Что вы можете предложить, чтобы транслировать расширения в РИБ – как это организовано у вас?

У нас 4 базы, которые находятся в общем контуре. Все эти базы доступны в одной и той же сети. Эти базы одинаковые, но они независимые. И у нас есть HTTP-сервис, которому мы даем команду поместить расширение в базу №1, в базу №2, в базу №3 и в базу №4.

У нас с помощью репликации подразумевается, что эти базы должны быть одинаковыми.

Зачем 50+ расширений? Я так и не понял.

Я тоже не понял, но так получилось. Так сложилось исторически, потому что расширения – это простой способ делать доработки на лету. Сейчас мы некоторые расширения объединили и у нас стало около 20 расширений. А раньше было расширение «Продажи» от нас и от подрядчиков, расширение «Закупки» от нас и от подрядчиков, два расширения «Зарплата» и т.д. За счет этого получалось так много лишних расширений.

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

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Путь к идеальному коду".