Релизы 1С без ночных авралов: минимальный процесс для реальной команды

Релиз в 1С-команде может быть спокойным рабочим процессом.

А может быть маленькой спецоперацией.

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

• непонятно, какие задачи точно входят в релиз;
• часть изменений обсуждалась в личке и не попала в общий список;
• внешнюю обработку забыли обновить;
• расширение проверили только на открытие формы;
• пользователи не успели протестировать критичный сценарий;
• описание изменений собирается уже после установки;
• плана отката нет, но “если что, разберемся”;
• после релиза команда весь день ловит неожиданные ошибки.

Формально релиз состоялся. Фактически команда снова вывезла на героизме.

В 1С это особенно болезненно. Потому что релиз может затрагивать не только код, но и учетные процессы, права, регламентные задания, обмены, внешние обработки, расширения, маршруты согласования, печатные формы, отчеты и привычные действия пользователей.

В этой статье разберем, как сделать релизы 1С спокойнее без тяжелой бюрократии: какие роли нужны, что фиксировать в составе релиза, какие проверки делать, как работать с внешними артефактами и что обязательно разобрать после выпуска.

 

 

 

Почему релизы 1С часто горят

Обычно проблема не в том, что команда слабая.

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

“Да как-нибудь выпустим. Мы же всегда справлялись”.

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

Разберем типовые причины.

 

1. Состав релиза живет в головах и переписках

Одна задача в системе учета задач. Вторая в переписке с пользователем. Третья пришла от руководителя голосом. Четвертую разработчик “быстро поправил, потому что там на пять минут”. Пятая зависла после тестирования, но кто-то считает, что она уже готова.

В итоге перед релизом команда пытается собрать картину из разных источников.

Это не релизный процесс. Это археология.

 

2. Не разделены типы изменений

В один релиз могут попасть совершенно разные изменения:

• маленькая правка формы;
• изменение прав доступа;
• новая печатная форма;
• доработка бизнес-процесса;
• обновление внешней обработки;
• изменение обмена с ЭДО;
• оптимизация тяжелого запроса;
• обновление расширения;
• исправление ошибки после прошлого релиза.

Если все это проверять одинаково, часть рисков обязательно потеряется.

Печатную форму можно проверить одним сценарием. Изменение маршрута согласования в 1С:Документооборот — уже совсем другим. Интеграцию с API СБИС или Диадок — третьим. Права и RLS — четвертым.

 

3. Внешние обработки и расширения проверяются “по остаточному принципу”

В 1С часто есть отдельный слой артефактов:

• внешние обработки;
• внешние отчеты;
• расширения;
• дополнительные обработки БСП;
• служебные обработки сопровождения;
• интеграционные обработки;
• скрипты и временные инструменты.

Они могут не входить напрямую в основную конфигурацию, но сильно влияют на работу пользователей.

Проблема в том, что при релизе их легко забыть. Особенно если нет реестра, владельцев и сценариев проверки.

 

4. Тестирование держится на фразе “ну посмотрите”

Команда просит пользователей:

“Проверьте, пожалуйста, изменения”.

Пользователи открывают пару форм, нажимают пару кнопок и говорят:

“Вроде нормально”.

После релиза выясняется, что никто не проверил:

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

Пользователи не виноваты. Им часто просто не дали понятный сценарий проверки.

 

5. Нет разбора после релиза

Ошибки после релиза бывают почти у всех.

Вопрос не в том, чтобы никогда не ошибаться. Вопрос в том, что команда делает после ошибки.

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

В зрелом процессе команда хотя бы коротко отвечает:

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

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

 

 

 

Что такое минимальный релизный процесс

Когда говорят “релизный процесс”, многие представляют тяжелый регламент, согласования, комитеты, таблицы на 30 колонок и ощущение, что теперь любое изменение будет ехать три недели.

Для небольшой или средней 1С-команды это часто лишнее.

Нужен не идеальный enterprise-процесс, а минимальный рабочий контур.

Минимальный релизный процесс — это набор простых правил, который помогает команде понимать, что выпускается, кто проверяет, какие есть риски и что делать после установки.

В нем должны быть 7 базовых элементов:

1. состав релиза;
2. ответственные роли;
3. классификация изменений по риску;
4. чек-лист проверки;
5. отдельный контроль внешних обработок и расширений;
6. коммуникация с пользователями;
7. разбор ошибок после релиза.

Этого уже достаточно, чтобы снизить хаос.

 

Элемент 1. Состав релиза

Состав релиза — это не формальность.

Это главный документ, который отвечает на вопрос:

“Что именно мы сейчас выпускаем?”

Минимально в составе релиза стоит фиксировать:

 

Поле	Зачем нужно
Номер задачи	Чтобы связать изменение с постановкой и историей обсуждения
Краткое описание	Чтобы быстро понять суть изменения
Тип изменения	Форма, отчет, права, обмен, расширение, обработка, регламентное задание
Ответственный разработчик	К кому идти при техническом вопросе
Ответственный за проверку	Кто подтверждает, что изменение работает
Риск	Низкий, средний, высокий
Сценарий проверки	Что именно нужно проверить
Статус проверки	Проверено, не проверено, есть замечания
Комментарий к релизу	Что нужно сообщить пользователям

 

Даже если команда не готова вести много полей, начните с пяти:

• задача;
• описание;
• ответственный;
• риск;
• проверка.

Уже это убирает большую часть тумана.

 

Элемент 2. Роли в релизе

Одна из причин авралов — непонятно, кто за что отвечает.

Разработчик думает, что аналитик проверил. Аналитик думает, что пользователь посмотрел. Пользователь думает, что ИТ сами знают, как проверять. Руководитель узнает о проблеме уже после установки.

Для небольшого процесса достаточно таких ролей:

 

Роль	Ответственность
Владелец релиза	Следит за составом, статусом готовности и решением go/no-go
Разработчик	Готовит изменение, описывает технические риски и сценарий проверки
Аналитик / постановщик	Проверяет соответствие бизнес-сценарию и критериям приемки
Ключевой пользователь	Проверяет реальный рабочий сценарий на тестовом контуре
Администратор / сопровожденец	Контролирует установку, доступы, расписания, фоновые задания и технические моменты
Руководитель / заказчик	Принимает решение по спорным рискам и приоритетам

 

В маленькой команде один человек может совмещать несколько ролей. Это нормально.

Главное — не совмещать ответственность молча.

 

Элемент 3. Классификация изменений по риску

Не все изменения требуют одинакового внимания.

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

Поэтому удобно разделить изменения на три уровня.

 

Уровень риска	Примеры	Как проверять
Низкий	Печатная форма, простой отчет, изменение надписи, небольшая команда на форме	Проверка открытия, формирования, прав доступа и результата
Средний	Изменение формы документа, проверки заполнения, дополнительные реквизиты, обработчики команд	Проверка пользовательского сценария, разных ролей, ошибок и повторного открытия
Высокий	Проведение, обмены, права, RLS, бизнес-процессы, маршруты согласования, регламентные задания, расширения с перехватами	Отдельный тест-план, проверка на копии, участие ключевого пользователя, контроль после релиза

 

Такая классификация помогает команде не спорить каждый раз с нуля.

Если изменение высокого риска — значит, у него не может быть проверки “открылось и ладно”.

 

Элемент 4. Релизный чек-лист

Чек-лист нужен не для галочки.

Он нужен, чтобы команда не держала критичные действия в голове.

 

Минимальный чек-лист до релиза

• Состав релиза зафиксирован.
• У каждой задачи есть ответственный.
• Критичные изменения выделены.
• Сценарии проверки по задачам описаны.
• Внешние обработки и отчеты проверены, если затронуты.
• Расширения проверены, если затронуты.
• Права и роли проверены для ключевых сценариев.
• Регламентные задания и обмены проверены, если изменялись.
• Пользователи предупреждены о релизе.
• Есть понимание, что делать при критичной ошибке.

 

Минимальный чек-лист во время релиза

• Установка выполняется в согласованное окно.
• Фиксируется время начала и окончания работ.
• Проверяется успешность обновления конфигурации или установки артефактов.
• Проверяются ошибки запуска.
• Выполняется smoke-проверка критичных сценариев.
• Проверяются регламентные задания, если они важны для процесса.
• Проверяются обмены, если они затронуты релизом.

 

Минимальный чек-лист после релиза

• Пользователям отправлено короткое описание изменений.
• Ключевые пользователи подтвердили основные сценарии.
• Ошибки после релиза зафиксированы.
• Критичные инциденты разобраны.
• Чек-лист обновлен, если что-то пропустили.
• Состав релиза и результаты проверки сохранены.

 

 

 

Элемент 5. Smoke-проверка 1С после релиза

Smoke-проверка — это короткая проверка, что система “дышит” после изменений.

Это не полноценное тестирование. Она не заменяет проверку всех бизнес-сценариев.

Ее задача проще:

быстро понять, что после релиза не сломалось самое важное.

Для 1С-команды smoke-проверка может включать:

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

Список должен быть коротким. Если smoke-проверка занимает полдня, ее перестанут делать.

Хороший ориентир: 15–40 минут на базовый контур, дольше — только для крупных релизов.

 

Элемент 6. Внешние обработки, отчеты и расширения

Внешние артефакты — отдельный источник сюрпризов.

Они могут жить не в основной конфигурации, но ломаться после обновления платформы, типовой конфигурации, БСП, изменения прав или изменения формы.

Поэтому у команды должен быть хотя бы минимальный реестр:

• наименование артефакта;
• тип: EPF, ERF, расширение, дополнительная обработка БСП;
• где используется;
• кто владелец;
• какую конфигурацию поддерживает;
• какая версия актуальная;
• какой сценарий проверки;
• уровень риска;
• когда проверялось последний раз.

Перед релизом нужно ответить на вопросы:

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

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

 

 

Элемент 7. Коммуникация с пользователями

Иногда релиз технически проходит нормально, но пользователи всё равно недовольны.

Почему?

Потому что они не знали:

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

Для релиза не всегда нужна большая инструкция. Часто достаточно короткого сообщения:

“Сегодня после 19:00 будет установлен релиз по задачам: изменение маршрута согласования договоров, новая печатная форма акта, исправление ошибки в отчете по задолженности. После установки просьба проверить создание договора, запуск согласования и формирование печатной формы. Если возникнут ошибки — направляйте обращение в общий канал поддержки, тема: Релиз от 15.06”.

Хорошее сообщение о релизе отвечает на пять вопросов:

• когда;
• что изменится;
• кого затронет;
• что проверить;
• куда писать при проблеме.

Это снижает послерелизный шум и помогает пользователям участвовать в проверке не “на глаз”, а по понятному сценарию.

 

Go/no-go: когда релиз можно выпускать

Перед установкой полезно принимать короткое решение go/no-go.

Не обязательно проводить совещание на час. Иногда достаточно пройти несколько вопросов:

• состав релиза понятен;
• критичные задачи проверены;
• ошибки высокого риска отсутствуют;
• внешние обработки и расширения проверены;
• пользователи предупреждены;
• окно установки согласовано;
• есть ответственный на время установки;
• есть план действий при критичной ошибке.

Если на несколько вопросов ответ “нет”, лучше честно признать риск.

Иногда правильное решение — не выпускать релиз сегодня.

Это неприятно. Но менее неприятно, чем выпустить неподготовленное изменение и потом восстанавливать доверие пользователей.

 

План отката: нужен ли он всегда

В идеальном мире у каждого релиза есть подробный план отката.

В реальной 1С-команде так бывает не всегда.

Но хотя бы базовое понимание должно быть:

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

Особенно важно думать об откате для изменений высокого риска:

• права и RLS;
• проведение документов;
• обмены;
• регламентные задания;
• расширения с перехватами;
• изменения бизнес-процессов;
• массовая обработка данных.

Откат — это не признак слабости команды. Это признак взрослого отношения к рискам.

 

После релиза: что обязательно разобрать

Самая недооцененная часть релизного процесса — разбор после выпуска.

Даже если релиз прошел хорошо, полезно зафиксировать:

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

Если релиз был проблемным, не надо превращать разбор в поиск виноватого.

Лучшие вопросы:

• какой факт произошел;
• какой сценарий мы не проверили;
• почему не проверили;
• какое правило процесса не сработало;
• какое маленькое изменение снизит риск повторения;
• кто отвечает за это изменение.

Плохой итог разбора:

“Разработчику быть внимательнее”.

Хороший итог:

“Добавить в чек-лист проверку прав роли ‘Инициатор договора’ при изменении маршрута согласования. Ответственный — аналитик. Проверять на тестовом пользователе перед каждым релизом с изменениями в договорах”.

Первый вариант ничего не меняет. Второй улучшает систему.

 

 

Минимальный регламент релиза 1С

Ниже — пример короткого регламента, который можно адаптировать под свою команду.

1. Все изменения релиза фиксируются в едином списке.
2. У каждой задачи должен быть ответственный за разработку и проверку.
3. Изменения классифицируются по уровню риска.
4. Для изменений среднего и высокого риска указывается сценарий проверки.
5. Внешние обработки, отчеты и расширения проверяются отдельно, если релиз может их затронуть.
6. Перед установкой владелец релиза принимает решение go/no-go.
7. Пользователи заранее получают краткое описание изменений и список сценариев для проверки.
8. После установки выполняется smoke-проверка.
9. Ошибки после релиза фиксируются отдельно.
10. По критичным ошибкам проводится короткий разбор и обновляется чек-лист.

Такой регламент можно уместить на одну страницу. И этого часто достаточно, чтобы команда перестала собирать релизы из памяти и переписок.

 

Что можно внедрить за 30 дней

Если сейчас релизы проходят хаотично, не надо сразу строить идеальный процесс.

Можно сделать план на месяц.

 

Неделя 1. Зафиксировать текущую боль

• Собрать список проблем последних 2–3 релизов.
• Отметить, какие ошибки повторялись.
• Понять, какие проверки отсутствовали.
• Выделить внешние обработки и расширения, которые чаще всего забывают проверять.

 

Неделя 2. Ввести состав релиза

• Создать простую таблицу состава релиза.
• Добавить поля: задача, описание, ответственный, риск, проверка, статус.
• Использовать таблицу на ближайшем релизе.

 

Неделя 3. Добавить чек-лист

• Сделать короткий чек-лист до/во время/после релиза.
• Добавить пункт про внешние обработки и расширения.
• Добавить пункт про пользователей и коммуникацию.

 

Неделя 4. Провести первый разбор

• После релиза собрать 3–5 выводов.
• Не искать виноватых.
• Обновить чек-лист по фактическим ошибкам.
• Выбрать одно улучшение к следующему релизу.

Главная цель первого месяца — не идеальность. Главная цель — чтобы релиз перестал быть непрозрачным.

 

 

 

Типовые ошибки при внедрении релизного процесса

 

Ошибка 1. Сразу делать слишком сложно

Если команда вчера жила в режиме “выпускаем как получится”, не надо завтра вводить многостраничный регламент.

Скорее всего, его будут обходить.

Начинайте с минимального состава релиза и короткого чек-листа.

 

Ошибка 2. Требовать идеального тестирования от пользователей

Пользователи не тестировщики.

Они могут хорошо проверить свой рабочий сценарий, если им понятно, что делать.

Поэтому вместо “проверьте релиз” лучше давать конкретный сценарий:

• создайте договор;
• заполните такие-то поля;
• запустите согласование;
• проверьте маршрут;
• сформируйте печатную форму;
• напишите результат проверки.

 

Ошибка 3. Не учитывать внешние артефакты

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

Именно поэтому их нужно включать в общий контур.

 

Ошибка 4. Делать разбор только после катастрофы

Разбор нужен не только после больших проблем.

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

Например:

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

 

Главный вывод

Релизы 1С не обязаны быть ночными авралами.

Да, в 1С всегда будут срочные задачи, неожиданные ошибки, странные данные, пользователи с нестандартными сценариями, внешние обработки, расширения, обмены, права и регламентные задания.

Но хаос вокруг релизов часто возникает не из-за самой 1С, а из-за отсутствия минимального процесса.

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

Чтобы это изменить, не нужен тяжелый регламент.

Нужны простые вещи:

• понятный состав релиза;
• ответственные роли;
• классификация рисков;
• короткий чек-лист;
• smoke-проверка;
• контроль внешних обработок и расширений;
• нормальная коммуникация с пользователями;
• разбор ошибок без поиска виноватых.

Зрелый релизный процесс — это не когда ошибок нет. Это когда команда знает, что выпускает, что проверяет, чем рискует и как становится лучше после каждого релиза.

С этого и начинается переход от ночных авралов к спокойному сопровождению 1С.