Технологии и преимущества разработки решений на общем коде. Как разрабатывается 1С:РМК, 1C:Розница и 1С:УНФ

Меня зовут Карина Самигуллина, я ведущий разработчик линейки решений для малого бизнеса, куда входят продукты 1С:УНФ. 1С:Розница и 1С:РМК.

Наша линейка появилась на рынке относительно недавно, в 2022 году – я расскажу, какие факторы стали предпосылками к ее созданию.

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

И в конце порассуждаем, какие вообще преимущества может принести линейка решений на общем коде.

 

Предпосылки к созданию общей линейки решений для малого бизнеса

 

 

В 2022 году у нас на рынке было два разных решения:

• 1С:Розница 2.3, которая содержала в себе РМК;

• и 1С:УНФ 1.6.

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

Такой подход долгое время удовлетворял наших предпринимателей, но времена меняются, потребности меняются. И такой подход нес в себе несколько проблем.

• Первая проблема заключалась в том, что предприниматели, которые работали в 1С:Рознице 2.3, со временем могли захотеть выйти в онлайн-торговлю, поскольку это направление сейчас активно развивается. А для этого им приходилось переходить на новое решение 1С:УНФ 1.6. Подходы в этом решении были другие, архитектура другая, им нужно было заново учиться и переносить свои данные. Из-за этого рост наших предпринимателей немного притормаживался.

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

 

 

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

В линейку вошло три приложения:

• 1С:РМК

• 1С:Розница

• 1С:УНФ

У вас может возникнуть вопрос: «Если у этих приложений общая архитектура, код и интерфейсы, чем они вообще различаются?»

Сейчас коротко рассмотрим их отличия.

 

 

Первое приложение нашей линейки – это 1С:РМК.

• Внешнее рабочее место кассира для наших товароучетных решений 1С. Это не самостоятельное решение, а дополнительное рабочее место кассира.

• Судя по названию, здесь все, что нужно для работы кассира.

 

 

Второе решение нашей линейки – 1С:Розница 3.0.

• Предназначено для автоматизации либо одиночного магазина, либо розничной сети.

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

 

 

И третье решение нашей линейки – это 1С:Управление нашей фирмой.

• Подходит для тех, кто хочет автоматизировать торговлю, услуги, производство.

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

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

 

Возможности решений

 

 

Первое наше решение – это 1С:РМК.

 

 

1С:РМК уже встроено в 1С:Розницу 3.0, но при этом 1С:Розница 3.0 дополнена возможностями для розничной торговли.

 

 

А все возможности, которые содержатся в 1С Рознице 3.0, включая 1С РМК, встроены в 1С:Управление нашей фирмой 3.0, но при этом дополнены возможностями CRM, услуг, работ и производства.

Получилась такая матрешка из трех решений.

Как же сейчас эта матрешка у нас разрабатывается – как и по какой технологии работает команда разработки?

 

Технология приготовления

 

 

На первом этапе нам необходимо было реализовать сходимость наших решений.

Как я говорила, ранее продукты Розница и УНФ разрабатывались разными командами и имели разные возможности. Поэтому нам необходимо было поддержать в 1С:УНФ все лучшие решения, которые были реализованы в 1С:Рознице 2.3 – добавить возможности, популярные у пользователей и нужные им для работы. В течение двух лет продолжалась эта невидимая работа – мы объединили наши команды, и уже объединенные команды разрабатывали возможности в 1С:УНФ 1.6.

После того как мы перенесли все нужные возможности в 1С:УНФ 3.0, нам необходимо было понять, как из этого большого решения вырезать решения поменьше.

Здесь мы действовали по принципам работы «1С» – сначала начали изучать чужой опыт.

 

 

Первый вариант, который мы рассматривали для вырезания – это разработка подсистемы розничной торговли в виде библиотеки с последующим ее встраиванием в 1С:УНФ 3.0.

В этом варианте мы видели как плюсы, так и минусы:

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

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

Мы это учли и решили рассмотреть другие подходы.

 

 

Следующий подход наверняка известен многим из вас – это подход линейки 1С:УТ, 1С:КА, 1С:ERP. В этом случае код размечается специальными тегами, а затем при сборке уже физически вырезается из конфигурации – могут вырезаться документы, справочники, модули или даже какие-то конкретные строчки кода.

Здесь, конечно, тоже есть как плюсы, так и минусы.

• Плюсы в том, что и разработчик, и пользователь работают уже только с теми возможностями, которые для него предназначены. В УТ он физически никак не может работать с возможностями 1С:ERP, потому что они вырезаны.

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

Здесь мы тоже учли плюсы и минусы, но, как гласит принцип «Нужно изучать чужой опыт, но думать своей головой», и поэтому мы решили сделать свой подход.

 

 

Наш подход основан на функциональных опциях.

Мы поделили всю функциональность 1С:УНФ на большие блоки – они в основном совпадают с разделами. Определили возможности, которые для Розницы должны быть недоступны, и скрыли эти разделы благодаря функциональным опциям.

Для Розницы функциональные опции остаются выключенными, а для УНФ мы их включаем при первом запуске или при обновлении.

Отличие такого подхода от других в том, что код поставки 1С:Розницы 3.0 и 1С:УНФ 3.0 у нас полностью одинаковый – физически из конфигурации не вырезается ни единой строчки кода.

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

 

 

Результат того, как сейчас выглядят панели разделов конфигураций 1С:УНФ и 1С:Розница, показан на слайде. Если мы посмотрим на эти интерфейсы, то сразу увидим, что это два клона одного решения:

• в 1С:УНФ присутствуют разделы CRM, «Работы», «Производство», «Налоги» и «Компания»;

• а в Рознице мы скрыли опциями часть из раздела «Компании», а также полностью скрыли разделы CRM, «Работы», «Производство» и «Налоги».

 

 

Всю работу с включением и выключением опций мы реализовали в общем модуле «ВозможностиПриложения» – в нем обрабатывается включение опций и проверка на включение, если в 1С:Рознице, к примеру, опция недоступна.

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

 

Про сборки

 

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

 

 

У нас одно хранилище, где разработчики физически видят конфигурацию 1С:УНФ, при том, что она уже содержит в себе все возможности, нужные для 1С:Розницы 3.0.

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

Код из этого хранилища у нас выгружается в локальный репозиторий Git:

• оттуда изменения отправляются на GitHub;

• запускается 1С:Автоматизированная проверка конфигурации,

• и проверка кода с помощью SonarQube,

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

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

Но есть и обратная сторона, потому что ответственность у разработчика тоже сразу за три решения.

 

 

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

Из одного хранилища собираются целых четыре поставки:

• первая поставка – это 1С:УНФ 3.0;

• вторая – 1С: Розница 3.0;

• и их базовые версии.

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

 

 

Здесь важно отметить, что если мы говорим про коробки, то да, одно хранилище — четыре поставки.

Но если мы говорим про облако 1С:Фреш, где представлены оба наших решения – и 1С:Розница 3.0, и 1С:УНФ 3.0 – то сюда, в отличие от коробок, передается всего одна конфигурация. Не две 1С:Розницы и 1С:УНФ, а одна конфигурация – 1С:Управление нашей фирмой.

Как же потом пользователь понимает, где он работает – в Рознице или УНФ?

Мы совместно с командой 1С:Фреш реализовали механизм, который благодаря тарифам может разделить решения одной конфигурации. Сейчас, управляя тарифами, мы в 1С:Фреш видим либо 1С:Розницу 3.0, либо 1С:УНФ 3.0.

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

 

Про качество

 

Мы поговорили про разработку, теперь о том, как тестируется наша линейка приложений.

 

 

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

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

При этом автотесты у нас запускаются только на 1С:Управление нашей фирмой, потому что:

• если функциональность общая, то она абсолютно одинакова и в Рознице, и в УНФ;

• если функциональности в Рознице нет, то смысла автоматизировано ее тестировать тоже нет.

 

 

Помимо автоматизированного тестирования мы задействуем и ручное тестирование механизмов.

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

 

Про переходы

 

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

 

 

Если мы говорим про Управление нашей фирмой, то здесь переход был выполнен простым обновлением. Мы даже немного расстроились, потому что у нас в команде до перехода всегда были такие мысли: «Вот выпустим вторую редакцию, будет 2.0, мы там всю архитектуру переделаем». Мне кажется, у любого разработчика есть такое желание – выкинуть все и написать с нуля. Но нам сказали, что переход с 1.6 на 3.0 должен выглядеть как простое обновление, поэтому мы даже немного расстроились.

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

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

 

 

Поскольку у нас линейка решений, нам было важно выводить пользователю 1С:Розницы подсказки о том, что по мере роста потребностей он может перейти на более функциональное решение 1С:УНФ.

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

 

 

Если пользователь принимает решение перейти на 1С:УНФ, то благодаря общему коду и общей архитектуре переход очень простой.

• В случае коробочного варианта поставки пользователю необходимо просто приобрести файл обновления, скачать его и установить у себя в программе. При этом он остается в своей базе, со своими же данными, но при этом получает еще больше возможностей. Ему не нужно никуда ничего переносить, просто обновление, и он уже получает новые возможности 1С:УНФ.

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

 

Не про технологию, но важно учесть

 

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

 

 

Но поскольку конфигурация у наших решений одинаковая, то и справочная информация у них тоже одинаковая. Причем функциональными опциями мы там, к сожалению, ничего не скроем, и пользователи 1С:Розницы могут видеть всю справочную информацию про возможности 1С:УНФ.

Здесь мы тоже не хотели на пользователя давить, предупреждая, что у него чего-то нет. Мы просто подсказали ему сверху понятной подсказкой, что есть еще одно решение линейки, и если ты видишь такой значок, значит эта возможность в Рознице отсутствует, но есть в 1С:УНФ.

 

 

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

Это позволяет нам существенно сократить затраты на методическую поддержку – если возможность общая, достаточно выпустить по ней всего одну статью. И если раньше над статьями работали два человека, сейчас достаточно всего одного. А когда мы выпускаем статью по возможностям, доступным только в 1С:УНФ, мы просто помечаем ее специальным тегом «только для 1С:УНФ».

Кроме этого, удалось значительно ускорить процесс подготовки руководства пользователя. Сейчас мы реализовали такую схему: методист сначала пишет руководство пользователя для 1С:УНФ, затем просто вырезает из него разделы, недоступные в Рознице, и получает руководство пользователя для 1С:Розницы 3.0. Это тоже стало возможно благодаря тому, что и интерфейсы, и пересекающиеся возможности у нас общие.

 

 

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

 

 

Такая линейка была принята достаточно хорошо. Партнеры говорят, что необходимо выпускать и другие бандловые решения – БП-ЗУП или БП-УТ.

Почему у людей такая реакция? Почему они хотят того, чтобы фирма «1С» унифицировала решения и делала их на общем коде?

Потому что у такого решения очень много преимуществ.

 

Преимущества линейки решений

 

 

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

На конференции был доклад «Как заработать миллион на расширениях». Я расскажу, как заработать два: делайте расширение для 1С:Розницы 3.0, а продавайте его для всей линейки решений нашего бизнеса.

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

 

 

Второй плюс – это сокращение сроков разработки.

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

Раньше законодательство в разных решениях внедряли два человека, а сейчас один человек внедряет законодательство сразу в три решения.

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

 

 

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

Если раньше предприниматель, который работал в 1С:Рознице, мог сказать: «А почему у меня нет кабинета клиента?», то сейчас мобильные приложения 1С:УНФ можно использовать для всей нашей линейки. Благодаря тому, что у нас общие интерфейсы, общие подходы, пользователю не нужно разбираться, как работать с этим приложением в 1С:Рознице или в 1С:УНФ – оно работает абсолютно одинаково.

 

 

Сокращаются сроки обучения как технических специалистов, так и наших пользователей – можно обучиться работе в 1С:УНФ и сразу уверенно работать в трех решениях.

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

 

 

Есть преимущества и для ландшафта.

• Если мы рассматриваем одиночные магазины или розничную сеть, то здесь все понятно – работаем на 1С:Рознице и 1С:РМК.

• Если мы берем вариант посложнее, когда есть торговые, сервисные или производственные предприятия, здесь у нас на бэке может работать 1С:УНФ, а на фронте – 1С:Розница.

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

Это преимущество тоже удалось реализовать благодаря общему коду и общей архитектуре наших решений.

 

 

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

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

Если говорить про обучение в приложении, то здесь предприниматель тоже остается в своей базе. И новым возможностям он может обучиться достаточно быстро, потому что подходы, интерфейсы в 1С:УНФ схожи с теми, которые есть в 1С:Рознице.

 

Заключение

 

Мы поговорили про линейку решений для малого бизнеса, посмотрели, какие приложения в нее вошли – это 1С:РМК, 1С:Розница и 1С:УНФ.

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

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

Такой подход позволяет достаточно быстро реализовывать новые решения в линейке. Если нам потребуется реализовать в нашей линейке CRM, мы выпустим новый продукт за неделю или даже за пару дней, используя формат хакатона.

 

Вопросы и ответы

 

Как у вас организован процесс по исправлению ошибок, выявленных АПК и SonarQube? Исправление выполняется в рамках текущей задачи разработчика или оформляется как отдельная задача?

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

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

Но у нас все разработчики обязательно работают с кодом в соответствии со стандартами.

Почему 1С:УНФ 1.6 так кардинально отличается от всех остальных конфигураций?

Такой был подход при ее создании, так работала команда.

Конечно, при разработке проектов мы всегда опираемся на то, что уже сделано, смотрим и конкурентные решения, и решения фирмы «1С», но вырабатываем свой подход.

Сейчас какую-то часть мы уже свели к общепринятым в 1С подходам – например, мы ушли от своей формы отчетов и перешли на стандартную общую форму.

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

Дополнительные проводки делаются в Рознице сразу, при переходе ему не нужно как-то дополнительно обновлять данные, это скрыто для пользователя, пользователь этого не видит, но невидимая работа происходит для того, чтобы как раз после обновления он корректно смог работать уже в 1С:УНФ 3.0.

То есть просто накатил обновление и сразу все данные появились?

Да. К примеру, если мы говорим про счета учета, то в Рознице они скрыты, их по умолчанию нет, но при этом все движения делаются в рамках счетов.

РМК поставляется в виде библиотеки? Ее можно использовать в своих решениях?

РМК – это библиотека, она поставляется отдельно, и ее можно использовать в своих решениях. А в Рознице и УНФ она уже встроена по умолчанию.

Вы говорите, что используете хранилище. А почему не EDT, например?

Действительно, сейчас у нас в команде нет централизованной разработки под EDT, но уже есть несколько разработчиков, которые работают полностью в EDT.

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

В будущем, конечно, мы очень хотим всей командой перейти на разработку на EDT, потому что действительно это проще, удобнее.

Очень интересна внутренняя кухня разработки. Вы используете технологию, которая называется «разветвленная разработка в хранилище» – когда под разные задачи используются разные хранилища?

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

Но в общем случае разработчики могут и просто отдельно разворачивать себе конфигурацию и потом переливать ее в общее хранилище.

Насколько я знаю, в фирме «1С» активно используется СППР, и специально для этого в СППР встроили возможность клонирования этих хранилищ.

Да, и мы как раз используем СППР в наших автотестах – у нас настроено, что когда падает тест, в СППР автоматически регистрируется ошибка.

А тесты пишут отдельные люди или все разработчики в этом участвуют?

Тесты пишут либо разработчики, либо тестировщики. Могут и оба: и разработчик, и тестировщик.

Например, после выполнения проекта разработчик садится и пишет тест.

И тестировщик, после того как проверил проект, пишет автоматизированный тест, который потом гоняет базовый сценарий из этого проекта.

Но отдельных людей, которые только автоматизированные тесты пишут, у нас нет.

У вас нет явного ведущего разработчика, техлида по тестированию?

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

Каким образом замечания от средств статического анализа от АПК и SonarQube приходят к разработчику, и как он с ними работает?

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

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

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

Получается, что критичные замечания приходят в СППР, а остальное вы смотрите в SonarQube?

Да.

АПК у вас запускается в фоновом режиме, а его результаты вы анализируете тоже в SonarQube?

Да, SonarQube является входной точкой.

 

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

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