Всем привет! Продолжаю #марафон технологических проектов.
В проектном офисе мы занимаемся не только интеграциями и DATAREON. В работу попадают разные технологические задачи: ESB, MDM, BI, ETL, DevOps для 1С, заказные интеграционные решения и проекты, где важно отвечать не за отдельную доработку, а за результат целиком.
Сегодня поговорим про DevOps для 1С.
Сразу скажу: DevOps нужен не всем.
Если контур 1С небольшой, доработки редкие, пользователей немного, а ошибка после обновления не останавливает работу компании, ручного процесса может хватать. Разработчик подготовил обновление, аналитик проверил основные сценарии, администратор выкатил изменения в техническое окно — и этого достаточно.Но ситуация меняется, когда без 1С уже нельзя нормально продавать, отгружать, производить, закрывать смены или обмениваться данными с внешними системами.
Например, если в 1С завязаны кассы, складские операции, производство, маркировка, внешние API, тиражный продукт, SLA или высокая нагрузка. В такой системе релиз уже нельзя держать только на памяти команды и ручной проверке.Проблема не в том, что сотрудники плохо работают. Проблема в том, что ручной процесс плохо масштабируется.
Код может выглядеть нормальным на проверке, но сломаться в работе на реальных данных. Даже небольшое изменение может неожиданно повлиять на другие части системы. А если что-то пошло не так, команда тратит время на разбор: что изменили, что попало в релиз и почему это не заметили раньше.
Для меня DevOps для 1С начинается не с GitLab, Jenkins или SonarQube.
Он начинается с трех вопросов:
- что именно изменилось;
- что мы проверили до релиза;
- что мы проверили до релиза;
- кто и как будет поддерживать этот процесс дальше.
Первый уровень — контроль изменений. Если в хранилищах пустые комментарии, доступы живут как придется, а история изменений восстанавливается вручную после сбоя, зрелого релизного процесса еще нет.
Следующий уровень — автоматический контроль качества. Статический анализ забирает у архитектора рутину по формальным замечаниям. Дымовые тесты проверяют базовую работоспособность. Сценарные тесты закрывают критичные бизнес-процессы. Отчеты показывают проблему до релиза, а не после звонка от пользователей.
Третье — сопровождение. CI/CD-конвейер нельзя один раз настроить и забыть. Меняется версия платформы, конфигурация, тестовые сценарии, окружение — значит, кто-то должен поддерживать скрипты, проверки и инфраструктуру.
Поэтому DevOps для 1С почти всегда требует специалиста на стыке 1С-разработки и системной автоматизации. У нас такие инженеры есть: они помогают выстраивать конвейеры, настраивать проверки, сопровождать процесс и разбирать, почему он ломается.
Из практики.
- В PROSTO:СКУД (отдельный коробочный продукт нашей компании) мы автоматизировали регрессионное тестирование и проверку стандартов разработки. Проверки стали запускаться после изменений, техлид перестал вручную ловить типовые нарушения, количество ошибок сократилось на 50%.В PROSTO:СКУД (отдельный коробочный продукт нашей компании) мы автоматизировали регрессионное тестирование и проверку стандартов разработки. Проверки стали запускаться после изменений, техлид перестал вручную ловить типовые нарушения, количество ошибок сократилось на 50%.
- В проекте для нашего партнера «СИТЕК» с 1С:WMS полный прогон тестов со временем стал занимать до 14 часов. Проверки распараллелили по нескольким базам, чтобы команда получала актуальный отчет к началу рабочего дня.
- На проекте для крупного производителя гофротары 1С:ERP работала в производственном контуре 24/7, а техническое окно было минимальным. Планировщик Windows запускал цепочку скриптов, дымовые тесты проверяли базовую работоспособность, отчеты показывали проблемы до переноса в продуктив. За первый месяц после внедрения критических ошибок в продуктивной среде не было.
Поэтому я бы не ставил вопрос так: «Нужен ли всем DevOps для 1С?». Нет, не всем.
Правильный вопрос другой: сколько стоит ошибка в вашем релизе. Если ошибка почти ничего не стоит, ручного процесса может хватать.
Если ошибка может остановить продажи, склад, производство или внешний сервис, выпуск обновлений должен быть простым и понятным процессом, а не чем-то сложным.
DevOps для 1С — это контроль изменений до того, как ошибка попадет к пользователю.
А вы как сейчас выпускаете обновления 1С: вручную или уже через автоматизированный контур?