DevOps для 1С — это способ выпускать изменения в учётную систему предсказуемо: все доработки хранятся в системе контроля версий, сборка и проверки запускаются автоматически, а обновление продуктивной базы идёт по отработанному сценарию с резервной копией и возможностью отката. Результат для бизнеса — меньше аварий после обновлений, релизы по расписанию, а не «когда получится», и меньшая зависимость от одного-двух специалистов, которые «знают, как обновлять».
Ниже — объяснение для руководителя и ИТ-директора: почему ручные релизы со временем становятся риском, из чего состоит конвейер, с чего начинать и как понять, что внедрение окупилось.
Почему ручные релизы перестают работать
Пока доработок мало, обновление 1С выглядит просто: программист вечером собирает изменения, ночью обновляет базу, утром все работают. С ростом компании картина меняется:
- обновления делают ночью и в выходные, чтобы не останавливать склад, кассы и производство;
- сборка и выкладка ручные — файлы, базы, скрипты, порядок действий в голове у конкретного человека;
- нет истории: непонятно, какая версия где развёрнута и кто что менял;
- каждый релиз требует часов или дней ручного тестирования, и всё равно что-то проскакивает;
- откат — это восстановление из бэкапа с потерей данных за время после обновления.
Цена ошибки при этом растёт: для торговли это простой касс и потеря выручки, для производства — сорванный цикл, для бухгалтерии — сорванные сроки отчётности. Главная проблема ручного подхода — он не масштабируется: чем больше доработок и людей, тем выше риск каждого релиза.
Почему в 1С это особенно актуально
У 1С-проектов есть особенности, которые усиливают потребность в автоматизации:
- монолитная конфигурация с сотнями доработок, которые со временем начинают конфликтовать;
- несколько контуров — разработка, тест, пилот, продуктив — и необходимость держать их в согласованном состоянии;
- регулярные обновления от вендора, которые нужно объединять со своими изменениями;
- высокая критичность — через 1С идут деньги, товары и зарплата.
Из чего состоит конвейер DevOps для 1С
| Этап | Что происходит | Типовые инструменты |
|---|---|---|
| Хранение кода | Конфигурация и расширения выгружаются в файлы и хранятся в Git с историей и ревью | Git, GitLab или аналог, EDT |
| Сборка | По каждому изменению автоматически собирается поставка: конфигурация, расширения | Jenkins, GitLab CI, утилиты командной строки платформы |
| Статический анализ | Проверка кода на ошибки и соответствие стандартам | SonarQube с плагином для 1С, BSL Language Server, АПК |
| Автотесты | Дымовые проверки (открываются ли формы, работает ли навигация), сценарные тесты ключевых процессов | Vanessa Automation, YAxUnit |
| Отчётность | Результаты проверок видны команде и руководителю | Allure, дашборды CI |
| Развёртывание | Обновление тестовой, пилотной и продуктивной базы по одному сценарию, с бэкапом и проверкой после | Скрипты обновления, ibcmd, планировщик |
| Мониторинг | Контроль ошибок и производительности после релиза | Журнал регистрации, технологический журнал, системы мониторинга |
Ключевая идея — одни и те же шаги выполняются одинаково каждый раз. Если проверка не пройдена, изменение не уходит дальше, и проблему видит разработчик, а не пользователь утром в понедельник. Про автотесты подробнее я писал в статье автотесты 1С и регрессионное тестирование.
Какие риски закрывает DevOps
| Риск без DevOps | Как закрывается |
|---|---|
| Один неверный шаг при обновлении останавливает работу | Сценарий обновления отработан на тестовом и пилотном контуре |
| Изменения разработчиков конфликтуют | Ветки, ревью, автоматическая сборка ловят конфликт до продуктива |
| Знания в голове одного человека | Процесс описан кодом конвейера и документацией |
| Невозможно быстро откатиться | Бэкап перед обновлением и проверенная процедура отката |
| Ошибки находят пользователи | Статический анализ и автотесты находят их раньше |
С чего начать: поэтапный план
Внедрять всё сразу не нужно и вредно. Порядок, который я использую на проектах:
- Аудит текущего процесса. Как сейчас собираются и выкладываются релизы, сколько контуров, где происходят аварии, кто за что отвечает.
- Код в Git. Перенос конфигурации и расширений в систему контроля версий. Уже это даёт историю изменений и ответ на вопрос «что поменяли перед аварией».
- Автоматическая сборка и статический анализ. Каждое изменение собирается и проверяется без участия человека. Быстрый эффект при небольших затратах.
- Дымовые тесты. Минимальный набор: база запускается, открываются ключевые формы и разделы. Ловит грубые ошибки до продуктива.
- Сценарные автотесты по самым критичным процессам — продажа, отгрузка, закрытие месяца. Покрытие наращивается постепенно.
- Автоматическое развёртывание на тест и пилот, затем — на продуктив по регламенту.
- Обучение команды и документация, чтобы процесс не зависел от одного инженера.
Порядок работ и оценку трудозатрат даю после аудита: объём сильно зависит от размера конфигурации и того, что уже есть в компании. Для ориентира — почасовая ставка 2 500 ₽/ч.
Как понять, что внедрение работает
Измеряйте не «внедрили Jenkins», а изменения в процессе:
- сколько инцидентов в продуктиве после релизов — до и после;
- как часто выходят релизы и сколько времени занимает подготовка;
- сколько часов уходит на ручное тестирование;
- сколько времени проходит от готовой доработки до её появления у пользователей;
- может ли релиз выпустить другой сотрудник, если основной инженер в отпуске.
Если эти показатели не меняются, конвейер настроен «для галочки»: проверки есть, но их результаты никто не смотрит или их легко обойти.
Чек-лист: нужен ли вам DevOps для 1С
- Релизы вызывают стресс и проходят ночью или в выходные.
- После обновлений бывают простои или срочные исправления.
- Обновлять умеет один-два человека.
- Нет ответа на вопрос, кто, что и когда развернул.
- Ручное тестирование занимает дни.
- Над конфигурацией работают несколько разработчиков или подрядчиков.
Если совпало три пункта и больше — пора начинать хотя бы с первых шагов плана. Помогаю выстроить процесс от аудита до работающего конвейера: DevOps для 1С, тестирование 1С, а начать можно с аудита 1С.
Итог
- DevOps для 1С превращает релиз из ручной ночной операции в повторяемый конвейер.
- Основа — Git, автоматическая сборка, статический анализ, автотесты и сценарий развёртывания с откатом.
- Внедряется поэтапно: быстрый эффект дают Git, сборка и анализ кода, автотесты наращиваются постепенно.
- Эффект измеряется инцидентами, частотой релизов и затратами на ручное тестирование.
- Главный результат для бизнеса — релизы перестают быть риском и зависеть от одного человека.
