Наладили контроль качества кода 1С с Metrika42: Мониторинг кода 1С

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

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

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

Алгоритм внедрения

1. Зафиксировали контур и точки контроля. Описали, какие объекты поставляются в релиз, кто их готовит (внутренняя команда/подрядчик), и в какой момент нужен контроль: до объединения изменений, перед тестированием и перед выпуском.
2. Разделили проверяемый код по проектам. В сервисе завели проекты/направления, чтобы видеть качество отдельно по каждому потоку изменений и не смешивать результаты двух команд.
3. Согласовали критерии качества. Включили управление правилами/критериями проверки и утвердили единый набор требований для обеих команд; при необходимости предусмотрели добавление собственных правил под специфику проекта.
4. Запустили регулярные автоматизированные проверки. Настроили проверку поставок в распространенных форматах 1С (.cf/.epf/.cfe) и закрепили периодичность запусков, чтобы контроль качества стал регулярной практикой, а не разовой проверкой «по запросу».
5. Организовали отчетность и разбор. Включили автоматические отчеты с приоритизацией проблем и рекомендациями по исправлению; замечания сортируются по категориям и критичности, что ускоряет триаж и постановку задач на устранение.
6. Подключили историю проверок. Начали вести историю результатов, чтобы отслеживать динамику качества и управлять техдолгом на основе объективных данных: какие типы проблем повторяются, где «растет» долг, что реально исправляется.
7. Закрепили правила взаимодействия двух команд. Единые требования и единый формат отчетов стали общей точкой опоры для внутренней команды и подрядчика — меньше спорных трактовок «качества», выше прозрачность разработки.