Нет «дыма» – нет релиза? Или «дымим» ради релиза?

Меня зовут Максим Нифонтов. Я работаю с 1С с 2007 года. Руковожу отделом DevOps в компании Programming Store. У меня пятеро детей, две собаки и команда из 15 человек.

Проблема, с которой все началось

Есть завод, и у него есть проблема. Завод работает круглосуточно, значит, и база должна быть стабильной и доступной в любое время. Поддержка обеспечивается 24/7.

Но есть хранилище разработки и продуктивное хранилище. А между ними – ручной слив.

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

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

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

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

Идеи и первые шаги к решению

Что делать? Переход на Git в условиях «зоопарка» систем, разного уровня подготовки разработчиков и масштабного контура – задача непростая. Решили пока оставить хранилища, но автоматизировать процессы.

Автотестирование стало ключевым решением. У нас очень маленькое техническое окно, значит, все обновление должно быть скриптовым. Тут на помощь пришли OneScript и Vanessa-runner.

Тестировать будем дымовыми тестами – стандартный подход в автотестировании.

Используем Vanessa Automation, которая «пробегается» по базе: открывает все формы, нажимает все кнопки, то есть делает то, что ни один аналитик не сделает вручную за разумное время или сделает, но только к следующему тех. окну. А роботы справляются за 2–3 часа.

Хранить результаты тестов – обязательно. Нужно понимать, что пошло не так. Для этого используем Allure – отличный инструмент для визуализации результатов. Если у вас G-Unit – можно это делать и с ним, но в нашем случае это Allure.

Еще один важный элемент – качество кода. Чтобы минимизировать ошибки еще до тестирования, внедряем статический анализ через SonarQube. Многие проблемы можно выявить и исправить до того, как они «всплывут» в дымах.

План реализации процесса

План у нас получился такой:

• Релиз-инженер проверяет результаты дымовых тестов: все ли зеленое или есть что-то красное;

• Если все зеленое – релиз идет на прод;

• Если есть красное – запрашиваем откат или исправление.

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

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

Такой был план.

Техническая реализация системы

Как это все это было реализовано?

В качестве оркестратора был выбран Планировщик Windows. Никаких Jenkins, GitLab или сложных систем, только задачи по расписанию: два «батничка», которые по расписанию запускают планировщик.

Есть контур разработки, где определенное количество хранилищ и баз. Скрипты через планировщик:

• подтягивают изменения из хранилищ,

• применяют их к тестовым базам,

• вызывают Git-Sync, который переносит метаданные в Git,

• затем – SonarScanner отправляет данные в SonarQube.

SonarQube установлен на небольшой виртуальной Linux-машине. База данных – PostgreSQL, запущенная в Docker-контейнере. Кстати, настоятельно рекомендую: ставьте все в контейнерах – это удобнее, чем через пакетные менеджеры. Написал одну команду – и приложение развернуто.

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

Также есть PreProd Контур, куда попадают готовые доработки из разработки. Там – тот же «зоопарк» хранилищ, но уже в стабильной версии. Роботы накатывают обновления на связанные базы.

Vanessa смотрит, какие есть изменения относительно конфигурации поставщика, определяет, какие объекты изменились, и по измененным объектам генерирует дымовые тесты, тут же прогоняет по этим базам, забирает результаты и отдает их в Allure.

Allure – это не просто отчет. Это полноценная веб-панель с историей: видно, какие тесты были красными, какие стали зелеными, как менялась стабильность от релиза к релизу. Очень наглядно и удобно.

Кстати, Allure подключен к тому же PostgreSQL, который крутится в контейнере.

Сложности и подводные камни

Vanessa Automation требует пользовательского сеанса

Поскольку Vanessa Automation работает в режиме «честного клиента» – то есть эмулирует реального пользователя, открывает формы и нажимает кнопки – ей нужен настоящий пользовательский сеанс с открытым окном 1С.

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

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

Конфигурация на замке (нет конфы поставщика)

Если конфигурация находится на замке, а у нас нет доступа к конфигурации поставщика, и мы хотим прогонять не всю конфу, а только измененные объекты, то Vanessa в этом месте падает, потому что не понимает, что с чем мы сравниваем. Получается парадокс: «конфигурация на замке», но при этом включена опция «тестировать только измененные объекты».

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

Программно модифицированные формы были проигнорированы

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

В нашем случае мы такие ситуации проигнорировали. Потому что считаем: если дорабатываем какой-то объект, то соответствующая форма уже есть в расширении. Если ее там нет, риск крайне мал, и мы просто его не учитываем.

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

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

Конфигурации «одного разработчика» пропущены

Например, условный 1С:ЗУП, где работает один-единственный разработчик. Он говорит: «Я сам отвечаю за качество своего кода, мне это неинтересно. Гарантирую, что ничего не упадет. Сам сливаю, сам заливаю». Фактически он работает без хранилища, поэтому описанная процедура ему не нужна. Руководство доверяет и оставляет это на его ответственности.

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

Настройка исключений требует внимания

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

Процесс выглядит так: после первого прогона вы видите много «красноты». Реальный человек, который понимает логику работы системы, должен пройтись по этим ошибкам и определить: это баг или так задумано? Должна ли форма открываться? Если нет – ее нужно добавить в файл исключений, чтобы убрать лишние срабатывания.

Требуется донастройка базы дымов (даты запрета и т.д.)

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

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

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

Результаты внедрения

Что в итоге получилось?

Дымовые тесты теперь стоят на страже каждого релиза – как и задумывалось.

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

SonarQube, к сожалению, пока «буксует».

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

Здесь нужно твердое административное решение. Нужно четко сказать: «Если тех. долг растет – будет ата-та. Если падает – будет хорошо всем». На этом этапе подрядчик бессилен – это административное решение.

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

Allure все помнит. Он хранит всю историю и динамику тестов, какие были ошибки, где что «покраснело», что снова «зазеленело».

Что можно улучшить и добавить

Проект был ограничен по срокам, бюджету и рамкам. Но в перспективе можно туда добавить:

1. Оркестрацию (GitLab CI / Jenkins и т.п.)

Вместо Планировщика Windows можно внедрить Jenkins, GitLab CI или даже Cron – кому-то он нравится больше, чем Планировщик Windows.

2. Сценарные тесты

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

3. Мониторинги

Было бы полезно добавить:

• счетчик инцидентов,

• метрики производительности, например, по SonarQube.

Например: выросла ли производительность после рефакторинга? Уменьшились ли пики? В 1С-среде такие метрики ведутся редко – а зря. Инженерам они нужны. Бизнесу – тоже.

4. Автоматизацию на рабочих местах

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

Оценка затрат и выводы

Трудозатраты составили около 100 часов одного DevOps-инженера. Эти часы ушли на настройку всего контура:

• интеграцию «зоопарка» хранилищ,

• подключение к SonarQube,

• настройку дымовых тестов,

• отладку процессов «зайти-выйти»,

• документирование,

• доводку до рабочего состояния.

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

И да, я понимаю, о чем вы сейчас подумали: «Если у нас 16 часов в неделю на разработку, и мы начнем в понедельник – будет ли готово к среде?» Нет, не будет. Здесь та же история: 100 часов работы ? 100 часов календарного времени.

Так много это или мало – 100 часов? Представьте небольшую команду из 6 разработчиков, которая работает над полугодовым проектом. 100 часов – это всего 2% от их трудозатрат. На первый взгляд – копейки. Но именно эти 2% могут сэкономить сотни часов ручного тестирования, аналитики, поддержки, исправления ошибок на проде.

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

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