Обновление конфигурации 1С редко заканчивается самой установкой новой версии. Если в базе используются расширения, внешние обработки и интеграционные модули, после обновления остаётся главный вопрос: продолжат ли они работать с изменившейся конфигурацией?

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

Для предварительной проверки таких ситуаций мы разработали 1C Extension Checker 2.0 — самостоятельную внешнюю обработку, которая помогает проверить подключённые расширения и зафиксировать обнаруженные проблемы в едином протоколе.

Модели и харнессы стали более совершенными, что позволяет организациям трансформировать не только то, как они производят код, но и весь жизненный цикл разработки ПО. В данной статье — перевод рекоммендаций Anthropic по организации SDLC, если вы используете сервисы Claude.

В двухнедельном спринте регрессия часто превращается в лотерею: фичи доделывают до последнего дня, полный прогон не помещается в окно, а красному CI уже никто не верит. В итоге команда выпускается, ориентируясь на ощущение, а не на понятную картину рисков.

Эта статья о том, как встроить регрессию в Scrum так, чтобы она работала весь спринт. Разберём анализ влияния до разработки, наборы проверок P0-P3, тестовую пирамиду, flaky tests, тестовые данные, проверки после релиза и решение о выпуске с понятным остаточным риском.