Пожарная тревога или вечерний коммит: что покажет история разработки 1С
Разработка - Инструментарий разработчика
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Команда проекта 1С сопровождает рабочую базу и выпускает обновления из хранилища конфигурации или git. Руководителю требуется знать, какая доля изменений вносится в срочном порядке после поставки и меняется ли эта доля от месяца к месяцу. Журналы развёртываний и инцидентов ведутся не всегда, и по впечатлениям участников периоды сравнить невозможно. Для этого я написала fire_meter.py: по отчёту хранилища конфигурации или по истории git он вычисляет приближённые показатели поставок (частоту, время до поставки, долю поставок с исправлением следом, время восстановления) и долю «пожарных» изменений. Определения поставки, исправления и рабочего времени задаются в файле fire.json, а каждая версия получает пометку в commits.csv для проверки вручную.
-ReportFormat txt; расширение файла на формат не влияет.Для первого приближённого замера достаточно отчёта по истории хранилища или журнала git и трёх договорённостей: что считать поставкой, что считать исправлением и какое время рабочее. После расчёта выборку версий необходимо прочитать вручную. В моём опыте 20 примеров выявили ошибки метода, однако представительность такого объёма для истории другого проекта не гарантируется.
- Поставку удобнее всего отмечать меткой версии хранилища (
/ConfigurationRepositorySetLabel -Version N -name) или тегом git. Параметр-VersionLabelплатформа не учитывает: код возврата 0, метка остаётся пустой. - В проверенном прогоне содержимое всех 55 файлов хранилища сохранилось, у одного файла изменилось только время. Отсутствие побочных эффектов на любом хранилище этим не доказано. Отчёт снимается на пустой файловой базе, не подключённой к хранилищу.
- Признак исправления по словам комментария подтвердился в 6 случаях из 8. Ещё два изменения я отнесла по комментарию и началу патча к замечаниям статического анализатора. Поведение этих изменений запуском не проверялось.
- Правило «изменение тех же объектов вскоре после поставки» на открытом проекте относило к исправлениям новые функции, добавленные сразу после выпуска. Включать его следует только после проверки на истории проекта.
- Доля «пожарных» изменений по времени суток отражает режим работы команды. В открытом проекте 821 из 834 «пожарных» коммитов приходится на время вне выбранных рабочих часов по местному времени автора.
История хранилища или git даёт быстрые приближённые показатели поставок. Для метрик DORA в их собственном смысле нужны ещё подтверждённые события развёртывания и восстановления в рабочей среде. Ценность замера определяется тем, насколько определения поставки, исправления и рабочего времени совпадают с практикой команды. Начинать следует с разбора выборки версий; её объём и состав зависят от истории проекта.
Для кого: руководители и ведущие разработчики команд 1С, которым нужно оценить долю срочных исправлений и изменение показателей после перестройки процесса, а также те, кто ведёт конфигурацию в хранилище и желает получить из его истории больше, чем список версий.
Оценки работы команды обычно даются по впечатлению: «после выпуска приходится вносить исправления», «стало спокойнее». Для сравнения периодов нужны числа из данных, которые у команды уже есть: из истории хранилища конфигурации или git. Я проверила, какие приближённые показатели поставок и какую долю срочных изменений можно получить из этой истории. Для этого на «Нано-УТ 2.0» создано хранилище с 23 версиями двух пользователей, затем тот же разбор выполнен по двум открытым проектам 1С на GitHub.
Стенд
| Условие | Значение |
|---|---|
| Компьютер | Windows 11 Pro, Intel Core i5-2400, 7,9 ГБ ОЗУ, SATA SSD |
| Платформа | 1С:Предприятие 8.3.27.2130 x86, пакетный Конфигуратор (DESIGNER), файловое хранилище конфигурации |
| Конфигурация | «Нано-УТ 2.0», учебная; в хранилище 24 версии, включая создание |
| Открытые проекты | cpr1c/tools_ui_1c (GPL-3.0, 1650 коммитов, 31 тег), vanessa-opensource/add (MPL-2.0, 2367 коммитов, 21 тег) |
| Инструмент | fire_meter.py, Python 3.12.10, только стандартная библиотека |
Что считаем
Инструмент вычисляет четыре приближённых показателя, построенных по образцу прежнего набора DORA, и долю «пожарных» изменений. В актуальном руководстве DORA метрик пять: частота развёртываний, время от коммита до развёртывания, время восстановления после неудачного развёртывания, доля неудачных развёртываний и доля незапланированных исправляющих развёртываний.
Главная оговорка. В истории версий нет сведений о том, когда изменение попало в рабочую базу и когда восстановилась работа. Здесь метка или тег условно обозначает поставку, слова комментария дают основание предположить исправление, а ближайшая следующая поставка принимается в расчёт времени. Тег выпуска может не совпадать с развёртыванием, соседнее исправление может относиться к другой задаче. Алгоритм упорядочивает записи по времени и не проверяет, достижим ли коммит из тега. Время git читается по автору (настройкой переключается на коммитера), смещение часового пояса отбрасывается без пересчёта в UTC. Для команды в разных часовых поясах интервалы между коммитами могут быть искажены; общей временной шкалы инструмент в этом виде не даёт. Выдавать эти числа за подтверждённые метрики DORA нельзя, и доля вечерних коммитов не заменяет долю незапланированных исправляющих развёртываний (deployment rework rate).
| Метрика | Как считается по истории |
|---|---|
| Частота поставок | число поставок в неделю; поставка: версия с меткой или тег по шаблону (v2.3, 1.4.2, «Выпуск», «Релиз») |
| Время до следующей метки, приближение времени поставки | для непоставочной версии время до следующей метки в хронологическом порядке; медиана и p90. Хвост без следующей метки исключён и считается отдельно |
| Доля меток с предполагаемым исправлением следом | метка получает признак, если в окне после неё (по умолчанию 24 часа) есть изменение по эвристике исправления; факт дефекта не устанавливается |
| Временное приближение восстановления | от помеченной поставки до ближайшей метки не раньше первого предполагаемого исправления. Включение исправления в релиз и восстановление сервиса не проверяются |
| Доля «пожарных» изменений | исправление в окне после поставки или любое изменение вне рабочего времени |
Исправление определяется по словам комментария («исправ», «ошибк», «hotfix», «срочно», «опечатк», «fix», «bug») и, если включено, по изменению объектов поставки в окне после неё. Все шаблоны, рабочие часы, выходные и окно лежат в fire.json с пояснением каждого ключа. Дополнительно инструмент выводит размер поставки в объектах и «горячие» объекты, которые чаще всего попадают в исправления.
Хранилище из командной строки: что есть в 8.3.27
Хранилище стенда создано и заполнено только пакетными командами. Документация отвечает на такие вопросы не всегда, поэтому часть сведений получена пробами:
| Действие | Что сработало | Что не сработало |
|---|---|---|
| Создание хранилища | /ConfigurationRepositoryCreate без дополнительных ключей, 4,5 с в отдельной пробе; 7,5 с в сценарии |
ключи -AllowConfigurationChanges и правил поддержки: код 1, журнал пуст |
| Пользователи | /ConfigurationRepositoryAddUser с правами ReadOnly, LockObjects, ManageConfigurationVersions, Administration |
проверенное неизвестное право Nonsense: код 1 |
| Метка поставки | /ConfigurationRepositorySetLabel -Version N -name <метка> -comment <текст> |
-VersionLabel: код 0, метка пустая |
| Загрузка правки | только захваченного объекта и с параметрами хранилища в строке | без захвата: «объект метаданных ... не захвачен в хранилище!» |
| Отбор отчёта по датам | -DateBegin 2026-10-28 или 20261028; дата конца в отбор не входит |
28.10.2026, 10/28/2026, дата со временем: «Неверный формат даты» |
Сценарий команды выполнен 105 вызовами платформы, все с кодом возврата 0: два пользователя, 23 помещения версий, 7 меток поставок, три срочных исправления сразу после поставки и одно обычное исправление.
Отчёт по истории хранилища
Команда /ConfigurationRepositoryReport сохраняет отчёт в файл. Проверены все найденные варианты формата:
| Как снят | Что получилось |
|---|---|
имя файла .mxl, .txt, .xls, .html без ключа формата |
формат MOXCEL, 44 376 байт; время построения внутри файлов различается |
-ReportFormat mxl, html, xls, xlsx |
тот же MOXCEL |
-ReportFormat txt |
текст, 17 892 байта на 24 версии |
-GroupByObject, -GroupByComment |
отчёты по объектам и по комментариям, без дат, авторов и меток |
-IncludeOnlyVersionsWithLabels |
7 версий из 24 |
Для метрик подходит текстовый отчёт по версиям: в нём номер версии, версия конфигурации, пользователь, дата и время создания, метка с комментарием, комментарий версии и списки добавленных, изменённых и удалённых объектов. Инструмент читает и MOXCEL: на стенде оба формата дали одинаковые 24 версии, совпадение закреплено тестом.
Отчёт снимается на пустой файловой базе, не подключённой к хранилищу, за 4,1–4,3 секунды. Чтобы убедиться, что снятие отчёта не изменяет хранилище, я в отдельном прогоне сравнила 55 его файлов до и после: по содержимому не изменился ни один, у файла ver изменилось только время.
Снятие отчёта хранилища из командной строки: код возврата 0 и начало текстового отчёта
Метрики хранилища против заложенного
Сценарий выполнялся 14 минут, поэтому окно исправления на стенде я задала равным 0,03 часа (108 секунд), а рабочее время распространила на весь день. Заложенные значения взяты из плана сценария и журнала платформы.
| Показатель | Заложено | Посчитано |
|---|---|---|
| Версий после создания | 23 | 23 |
| Поставок (версии) | 5, 9, 10, 14, 15, 19, 24 | 5, 9, 10, 14, 15, 19, 24 |
| Поставок с исправлением следом | 3 (версии 9, 14, 19) | 3 (9, 14, 19) |
| Исправлений (версии) | 10, 12, 15, 20 | 10, 12, 15, 20 |
| «Пожарных» (версии) | 10, 15, 20 | 10, 15, 20 |
| Время до поставки, медиана | 35,5 с | 36 с |
| Время до поставки, p90 | 60 с | 59 с |
Совпали все девять счётчиков и состав «горячих» объектов: Документ.ПродажаТовара дважды, ОбщийМодуль.ЦеныУчет и Документ.ЗаказПоставщику по разу. Время разошлось с журналом не более чем на секунду: заложенное значение взято по завершению команды помещения, посчитанное идёт по времени версии в отчёте.
fire_meter по отчёту хранилища: 7 поставок, 3 из них с исправлением, 3 «пожарных» из 23
Открытые проекты: метрики за годы
Стенд продолжительностью 14 минут пригоден для проверки счётчиков, но реальной истории разработки в нём нет. Поэтому для разбора взяты два открытых проекта 1С на GitHub с историей более 200 коммитов и тегами выпусков. Оба клонированы как данные, ничего из них не запускалось; инструмент читает только git log. tools_ui_1c ведётся в формате EDT, add содержит внешние обработки в XML-выгрузке. Рабочее время 09:00–19:00 по будням, окно исправления 24 часа.
| Показатель | tools_ui_1c | tools_ui_1c без правила «те же объекты» | add |
|---|---|---|---|
| Период | 12.2019 – 10.2026 | 12.2019 – 10.2026 | 10.2017 – 12.2024 |
| Коммитов в расчёте | 1453 | 1453 | 2046 |
| Поставок (теги) | 31 | 31 | 20 |
| Частота поставок, в неделю | 0,09 | 0,09 | 0,05 |
| Время до поставки, медиана / p90 | 33,1 / 216,7 сут | 33,1 / 216,7 сут | 42,4 / 488,8 сут |
| Поставок с исправлением следом | 11 (35,5%) | 7 (22,6%) | 7 (35,0%) |
| Время восстановления, медиана | 3,6 сут | 2,2 сут | 67,3 сут |
| «Пожарных» | 834 (57,4%) | 827 (56,9%) | 1176 (57,5%) |
| из них вне рабочего времени | 821 | 821 | 1170 |
Метрики tools_ui_1c по месяцам за последние два года
По этим числам более половины изменений относятся к «пожарным», а треть выпусков сопровождается исправлением. Прежде чем делать выводы о работе команд, я прочитала выборку коммитов вручную.
Двадцать коммитов, прочитанных вручную
Из истории tools_ui_1c взяты 20 коммитов равномерным шагом по трём группам: исправления по комментарию, исправления по правилу «те же объекты в окне после поставки», «пожарные» только по времени суток. В первичной приёмке комментарии, статистику файлов и начало патчей разметила модель; я выполнила свою разметку тех же данных и сохранила её. Вердикты совпали у 19 из 20 коммитов. Код для проверки поведения не запускался.
| Группа | Помечено | Настоящих исправлений ошибок |
|---|---|---|
| исправление по комментарию | 8 | 6 по текстовой разметке; ещё два отнесены к замечаниям SonarQube, без проверки поведения |
| исправление по тем же объектам после поставки | 6 | 0; новые функции и встроенные обработки сразу после релиза |
| «пожарные» по времени | 6 | 0; переработки, правка README, повышение номера версии |
Признак «вне рабочего времени» в сохранённой сверке совпал с временем автора у всех 20 коммитов для принятого графика. Проверка относится только к этим записям и этим настройкам. Правило «те же объекты» повышает долю поставок с предполагаемым исправлением с 22,6% до 35,5%, и на этом проекте оно относит к исправлениям развитие функций, выполненное сразу после выпуска. Доля «пожарных» изменений почти целиком образована временем суток: участники открытого проекта работают вечерами и в выходные. Это распределение времени коммитов при выбранном графике; реальные дежурства, занятость и инциденты команды мне неизвестны.
Выборка также выявила ошибку в самом инструменте. Файлы вне каталога исходников, например README, попадали в «объекты» пустым значением, и правка README после выпуска считалась исправлением. Ошибка исправлена и закрыта тестом, первая выборка сохранена в материалах опыта. По этой же выборке я дополнила шаблон исправлений словом «опечатк» и исключила служебные объекты. Отсюда оговорка: итоговые оценки выборки получены после настройки на ней же и независимой контрольной проверкой не являются. Отдельной новой выборки нет.
Время
| Прогон | Время |
|---|---|
| отчёт хранилища платформой | 4,1–4,3 с |
| fire_meter по сохранённому отчёту | 0,23 с |
| fire_meter прямо из хранилища (пустая база, отчёт, разбор) | 8,1 с |
| fire_meter по git, tools_ui_1c / add | 0,73 с / 0,97 с |
первый прогон на свежем облегчённом клоне (--filter=blob:none) |
40,3 с / 31,9 с |
Самые долгие 40 секунд приходятся на первый запуск по свежему клону, когда git дозагружает объекты для списка файлов. В трёх сохранённых тёплых прогонах каждой истории время было меньше секунды; для произвольного репозитория такое время не гарантируется.
Пределы
- Хранилище стенда существовало 14 минут: окно исправления сжато до 108 секунд, правило «вне рабочего времени» на нём не проверялось. Оно проверено тестами с заданными датами и на открытых проектах.
- Реальной команды в опыте нет. Инструмент показывает динамику по месяцам, но вывода «после изменений в процессе стало лучше» этот опыт не даёт.
- Выборка описывает текстовую разметку этих 20 примеров и участвовала в настройке метода. Поведение программ не проверялось. Сколько настоящих исправлений инструмент пропустил, она не измеряет.
- Клиент-серверное хранилище, другие версии платформы и истории больше 2046 коммитов не проверялись. Слияния git без тега в расчёт поставок не попадают.
Что проверить в истории проекта
- Договоритесь, что считать поставкой: метка версии хранилища или тег git. Проверьте, что последние три выпуска ими отмечены и имена соответствуют шаблону в
fire.json. - Снимите отчёт хранилища с
-ReportFormat txtпо всем версиям, без группировок, или укажите инструменту каталог git. - Запустите
python fire_meter.py --report report.txt --config fire.json --out fire-report --period monthи прочитайтеfire-report/report.md. Для git замените--report report.txtна--git <каталог>. - Откройте
commits.csv, возьмите 20 версий с пометкой «исправление» и прочитайте их комментарии и состав. Если правило «те же объекты» ошибается, как в моём опыте, выключите его ("same_objects_fix": false). - Если больше половины версий попадают вне рабочего времени, уточните рабочие часы или учитывайте только исправления в окне после поставки.
- Не меняйте определения между замерами и записывайте дату каждого изменения процесса: тогда месяц можно сравнить с месяцем.
Файлы к статье
Инструмент devops-28-4-tool.zip. fire_meter.py читает текстовый и табличный отчёт хранилища, снимает отчёт сам (--repository) или разбирает историю git. На выходе report.md, report.json, trend.csv по периодам и commits.csv с пометкой каждой версии. В архиве также fire.json с пояснением каждого определения, trend_svg.py для графика, README и 65 тестов на настоящем отчёте хранилища и git-репозитории, который создаёт тест. Тесты из чистой распаковки:
Тесты из чистой распаковки архива: 65 тестов, OK
Архив к статье devops-28-4-companion.zip. Скрипт сценария команды, который создаёт хранилище и помещает версии через пакетный Конфигуратор; отчёты и CSV по хранилищу стенда и двум открытым проектам с графиками; разбор 20 коммитов; команды хранилища, проверенные пробами, с ответами платформы; заполненный чек-лист «первый месяц замеров в команде»; расширенная PDF-версия статьи.
Расширенная PDF-копия статьи (43 страницы) входит в тот же архив. В ней полный текст статьи и семь приложений: заполненный чек-лист первого месяца замеров, команды повторения опыта по шагам, команды хранилища конфигурации в платформе 8.3.27 с ответами платформы на пробы, сравнение заложенного в сценарий с посчитанным, метрики открытого репозитория и разбор 20 коммитов, полные отчёты fire_meter.py и журналы прогонов. Она нужна, чтобы прочитать статью без сайта и проверить приведённые числа по первичным данным.
Итог
В отчёте по истории хранилища 1С есть всё для описанных приближённых показателей: версии, авторы, время, комментарии, метки и состав изменений. На стенде он снимался за 4,1–4,3 секунды, и отдельная проверка подтвердила, что содержимое 55 файлов хранилища при этом не изменилось. Текстовый формат в проверенных вариантах даёт только -ReportFormat txt. На хранилище стенда инструмент посчитал значения, заложенные в сценарий. В тёплых замерах история git с 2046 коммитами разбиралась за 0,97 с, первый обход облегчённого клона занял 31,9 с.
На открытом проекте одна эвристика при тех же данных заметно меняла результат. По текстовой разметке слова комментария выявили исправления в 6 случаях из 8, правило «те же объекты после поставки» ошиблось во всех шести, а признак «пожарного» изменения по времени суток отразил часы коммитов; подтверждённых инцидентов за ним нет. Поэтому перед сравнением периодов необходимо разобрать выборку версий и зафиксировать определения в fire.json. Нужна ли выборка большего объёма и какие ещё данные собирать, решает команда.
Вступайте в нашу телеграмм-группу Инфостарт
