Введение
Из-за ряда внутренних и внешних факторов конфигурация нашего Заказчика 1С:ERP Управление холдингом не обновлялась релизами вендора более двух лет.
В июле 2024 года нами было принято совместное решение о необходимости обновления программы до актуальной версии.
Помимо большого количества законодательных изменений, ожидавшихся в 2025 году, важным фактором принятия такого решения стало снятие платформы 3.1 ERP УХ с поддержки вендора с первого квартала 2025 года.
Проект перевода конфигурации ERP УХ с редакции 3.1 на 3.2 стартовал в августе 2024 года. До конца 2024 года успешно завершили обновление на релиз 3.2.5.2. На данный момент выстроен регулярный процесс выполнения обновлений, по регламенту новые релизы вендора доставляются в Продуктивную базу в течение двух недель после выхода.
Подходы и этапы работ
В связи со сложностью работ к организации был применен проектный подход.
По итогам предпроектного обследования были определены ключевые вызовы, влияющие на процесс обновлений:
- Наличие активного расширения;
- Наличие измененных объектов основной конфигурации. В основном, это частичные обновления из новых релизов вендора для добавления/изменения функциональности.
- Следует отметить, что нашим внутренним регламентом разработки частичные обновления запрещены за редким исключением (например, для приведения отчетности или алгоритмов расчета в соответствие с ведомственными нормативными актами);
- Общее количество объектов, добавленных и измененных в основной конфигурации и расширении, составило 4600, измененных модулей – 1100;
- Большое количество ключевых промежуточных релизов – 34;
- Короткий технологический перерыв – заказчик был согласен остановить работу с продуктивной средой для пользователей только на выходные дни (суббота, воскресенье), что накладывало дополнительные ограничения на возможную длительность работ.
После анализа и оценки временных затрат работы по обновлению на целевой релиз работы были разделены на три ключевых этапа:
- Подготовка файлов конфигурации для промежуточных обновлений на версию 3.2.4.5.
- Минимизация количества промежуточных релизов.
- Подготовка файла конфигурации (релиз 3.2.5.2) для финального обновления, с адаптацией доработок из конфигурации текущей версии (3.1.8.15) к архитектуре и функционалу типовой обновленной конфигурации актуальной версии (3.2.5.2).
- Сплошное тестирование обновленной конфигурации нашими аналитиками, исправление логических ошибок; проверка корректности работы наших доработок.
- Сплошное тестирование ключевыми пользователями Заказчика путём воспроизведения рабочего дня.
- Финальные согласования, проверка следующих зон:
- Все выявленные ошибки устранены, база консистентна;
- Все выполненные доработки работают корректно;
- Внутренний план действий согласован (план обновления и тестирования продуктива);
- Внешний план действий согласован (пользователи предупреждены о сроках работ; инфраструктура доступна).
- Подготовка и проведение обновления рабочей базы на актуальную версию конфигурации 1C:ERP УХ (3.2.5.2).
Первую часть работ, с учетом ее значительной трудоемкости и рутинности, было решено передать партнеру - компании «1С-ИЖТИСИ», которая специализируется на подобных задачах и имеет большой опыт обновления сложных нетиповых конфигураций. В ходе проведенной партнером оптимизации количество промежуточных версий обновления 1C:ERP УХ с 3.1.8.15 до версии 3.2.4.5 было уменьшено с 34 до 7, по итогу выполненного демообновления мы получили комплект файлов конфигураций для промежуточных обновлений на версии: 3.1.8.24, 3.1.9.8, 3.1.10.8, 3.1.11.9, 3.1.12.25, 3.2.3.8 и 3.2.4.5:
Таблица 1:
|
Этапы оптимальные |
Версии промежуточные и обновления |
Обновление с версии |
|
1 |
3.1.8.24 |
3.1.8.15 (исходная) |
|
2 |
3.1.9.8 |
3.1.8.24 |
|
3 |
3.1.10.8 |
3.1.9.8 |
|
4 |
3.1.11.9 |
3.1.10.8 |
|
5 |
3.1.12.25 |
3.1.11.9 |
|
6 |
3.2.3.8 |
3.1.12.25 |
|
7 |
3.2.4.5 |
3.2.3.8 |
Здесь следует дать пояснения про услугу демообновления. При таком варианте обновления компания «1С-ИЖТИСИ» не предоставляет гарантий на результаты работы и не обеспечивает техническую поддержку обновленных таким образом продуктов. Все риски использования результатов демообновления берет на себя заказчик (в этой работе заказчиком выступали мы).
В рамках демообновления выполняется автоматическое обновление только части изменений без их адаптации к типовой конфигурации:
- типовые объекты остаются в типовом виде;
- добавленные нетиповые объекты остаются в исходном виде (без адаптации);
- обновляются все метаданные (остаются измененные и добавляются новые типовые изменения, риски потери данных в данном случае минимальны), дважды измененные модули и формы замещаются на типовые при конфликтах;
- дважды измененные макеты остаются в типовом варианте.
Рассмотрим подробнее наш практический опыт подготовки финального обновления. Эта часть работ выполнялась параллельно с демообновлением и представляла собой адаптацию доработок из исходной конфигурации версии 3.1.8.15 к актуальной конфигурации версии 3.2.5.2:
- Работа проводилась группой из трех разработчиков под руководством ТехЛида;
- Первым шагом в основную конфигурацию исходной версии были перенесены все доработки из расширения. Всего было перенесено из расширения 6800 процедур и функций.
Решение отказаться от расширения и перейти к одной сущности (к основной конфигурации) было принято для того, чтобы сделать проще все последующие обновления. На тот момент мы рассматривали два варианта обновлений после перехода на целевую версию 3.2.5.2 – обновления своими силами или передача на сопровождение (автоматизированные обновления) партнеру «1С-ИЖТИСИ». Второй вариант предполагал сопровождение конфигурации без расширений;
- Групповая разработка по подготовке конфигурации для финального обновления велась в среде 1С с использованием Git-репозитория и (частично) EDT;
- В Git была загружена целевая типовая конфигурация 1C:ERP УХ версии 3.2.5.2, в которую разработчики переносили адаптированные изменения из исходной версии конфигурации. Выбор нестандартного метода обновления с использованием ручного переноса (с адаптацией) всех доработок непосредственно в типовую конфигурацию новой версии был обусловлен тем, что сроки проекта были ограничены, и была необходимость максимально распараллелить работу на проекте;
- Пока в «1С-ИЖТИСИ» готовили промежуточные релизы, мы всей командой готовили конфигурацию целевого релиза. У разработчиков на проекте не было простоев, за каждым был закреплен свой набор объектов. Поскольку конфигурация не обновлялась более двух лет, каждый объект требовал перепроверки;
- Схема работы с Git позволяла выполнять работу независимо друг от друга. Техлид проекта распределял задачи между членами команды по списку объектов. В состав типовой задачи на данном этапе обычно входила адаптация для определенного количества однотипных объектов. Учет обработанных объектов команда вела в общей таблице на сетевом ресурсе, там же отмечались объекты, которые требовали дополнительного анализа или обсуждения. Все вопросы, требующие оперативного решения, обсуждались на ежедневных митингах команды с ТехЛидом проекта;
- Параллельно с этапом адаптации на проекте основная команда продолжала вести функциональную разработку в своем независимом Хранилище 1С. Изменения по таким задачам также с определенной периодичностью переносились в ветку с новой версией (3.2.5.2) адаптированной конфигурации:
Скрин 1:
На скрине 1 - пример переноса из хранилища 1С в обновляемую конфигурацию изменений, выполненных за определенный период в контуре разработки основной командой проекта сопровождения (с 408 по 430 версии хранилища 1С). Перенос выполнен в конфигураторе базы разработки методом сравнения-объединения основной конфигурации версии ERP УХ 3.2.5.2, соответствующей версии 408 хранилища 1С, с файлом конфигурации, соответствующей версии 430 хранилища 1С (исходной версии ERP УХ 3.1.8.15): Объединенная конфигурация ERP УХ 3.2.5.2 с изменениями за период была перенесена в ветку Update Git- репозитория скриптом полной выгрузки конфигурации базы в рабочий каталог (см. Скрин 2):
Скрин 2:
Применение скриптов для выполнения рутинных операций по выгрузке и загрузке конфигураций в базах разработки позволило упростить часть процессов и значительно ускорило действия с конфигурацией. В скриптах используется утилита командной строки "ibcmd". Код скрипта полной выгрузки конфигурации базы в рабочий каталог локального репозитория в виде XML-файлов приведен под спойлером:
- Файлы промежуточных релизов, полученные от «1С-ИЖТИСИ», также выгружались в отдельные ветки Git-репозитория. Например, в ветке TU_299_3_1_8_24 (на скрине 3) формировалась конфигурация для технического обновления на ERP УХ версии 3.1.8.25:
Скрин 3:
- Все ветки промежуточных обновлений (с префиксом TU_) перед подготовкой файлов технических обновлений были актуализированы из хранилища 1С. Были добавлены асе изменения в составе метаданных, выполненные в контуре разработки за весь период подготовки обновлений. Доработки, выполненные в модулях, не переносились в ветки промежуточных технических обновлений, они были внесены на этапе формирования конфигурации для финального обновления. Этап переноса изменений в составе метаданных был необходим для обеспечения целостности конфигураций промежуточных обновлений с целью исключить потерю данных в рабочей базе по причине возможного изменения реквизитного и/или объектного состава в промежуточных конфигурациях (см. Скрин 4):
Скрин 4:
Этап подготовки к проведению обновления рабочей базы на актуальную версию конфигурации 1C:ERP УХ (3.2.5.2) включал в себя:
- Тестирование всей цепочки промежуточных и финального обновлений конфигурации на копии рабочей базы. Фиксировались результаты при выполнении каждого этапа (включая выполнение обработчиков отложенного обновления ИБ). Выявленные ошибки исправлялись. По завершению этапов обновления в тестовой базе были проведены дополнительно дымовые и синтаксические тесты итоговой конфигурации. На тему тестов сегодня много доступной информации в открытых источниках, а здесь мы отметим только, что в качестве основного инструмента для выполнения автоматических тестов используем Jenkins с установленной библиотекой jenkins-lib.
Полученные результаты автотестов были проанализированы, а выявленные критичные ошибки исправлены.
На скринах 5 - 8 приведены примеры того, как выглядят результаты дымовых и синтаксических тестов в интерфейсе Jenkins c генерацией Allure-репортов:
Скрин 5: Дымовой тест (страница с результатами)
Скрин 6: Дымовой тест (Allure Report)
Скрин 7: Синтаксический тест (страница с результатами)
Скрин 8: Синтаксический тест (Allure Report)
- Результаты замеров длительности выполнения обновлений в процессе тестирования показали, что продолжительность обновления тестовой ИБ на релиз 3.2.3.8 (включая обработчики обновления в монопольном и отложенном режиме) составила 84 часа (3,5 дня). Это значительно дольше периода технологического окна (60 ч.), которым мы располагали для обновления рабочей ИБ на 7 промежуточных и 1 целевую версию конфигурации;
- Был проведен детальный анализ с использованием замеров производительности и контроля событий в журнале регистрации. При этом брались на заметку все обработчики, время выполнения которых превышало 4 часа. По результатам анализа был определен перечень ресурсоемких обработчиков, каждый из которых выполнялся от 10 до 105 часов:
Таблица 2:
| № | Обработчики обновлений ("тяжелые") | Продолжительность выполнения: |
|---|---|---|
|
1. |
Общий модуль ОбновлениеИнформационнойБазыЕХ, процедура РеестрПлатежейЗаполнитьРеквизитыВзаиморасчетов | 10 часов |
|
2. |
Общий модуль ОбработчикиОбновленияОПК, процедура ПеренестиДвиженияРегистраторПлановЛимитов | 105 часов |
|
3. |
Общий модуль ОбработчикиОбновленияОПК, процедура ОбновитьОперацииБюджетовЗаявкаНаРасходованиеДенежныхСредств | 17 часов |
|
4. |
Общий модуль ОбработчикиОбновленияОПК, процедура ОбновитьОперацииБюджетовПоФактПоБюджетам | 48 часов |
При этом не было зафиксировано повышенной нагрузки на серверах 1С и БД.
- В базе знаний на «Инфостарт» есть статья про многопоточное обновление. В ней подробно описана схожая проблема и предложен вариант решения. Эта статья помогла нам оптимизировать длительные процессы обновления;
- Для снижения продолжительности обновления до приемлемого значения было решено программно доработать алгоритмы, выполняющие "длительные" операции обновления ИБ в режиме Предприятия, и обработчики обновления. Алгоритмы были доработаны для использования механизма многопоточной обработки данных:
1. Добавлен общий модуль "icl_УскоренноеМногопоточноеОбновление";
2. В процедуре нового общего модуля "ПередНачаломРаботыСистемыНаСервере", которая вызывается перед началом работы пользователя из метода "ПередНачаломРаботыСистемы" (общий модуль "СтандартныеПодсистемыКлиент"), увеличили количество потоков для обработки данных (значение константы "КоличествоПотоковДлительныхОпераций") с 4 (в типовом варианте) до 10 (см. скрины 9 и 10):
Скрин 9:
Скрин 10:
3. Типовые обработчики ресурсоемких операций были заменены универсальным методом "ОбработатьДанныеТЗМногопоточно", в который параметром передаются ИмяПроцедуры для подготовки длительных операций (потоков) в фоне к выполнению (см. Скрин 11):
Скрин 11:
4. Сами фоновые задания формируются функцией "ПотокиНаСервере" (см. Скрин 12). Размер обрабатываемых объектов одним заданием рассчитывается здесь же, исходя из общего количества объектов и заданного количества потоков (также устанавливаем равным 10):
Скрин 12:
5. Чтобы появилась возможность запустить многопоточное обновление, в типовом коде была отключена проверка монопольного режима. Для этого в общем модуле "ОбновлениеИнформационнойБазыСлужебный" в функции " ЗаблокироватьИБ" закомментирована строка кода: УстановитьМонопольныйРежим(Истина):
Скрин 13:
В функции "ДобавитьПараметрыРаботыКлиентаПриЗапуске" (скрин 14) этого же общего модуля была закомментирована часть кода в области проверки продолжения работы:
Скрин 14:
- Пример использования многопоточной обработки:
Для оптимизации выполнения обработчика, время выполнения которого составило 10 часов, проведены следующие доработки конфигурации - в Общем модуле "ОбновлениеИнформационнойБазыЕХ" в самом начале типового обработчика обновления "РеестрПлатежейЗаполнитьРеквизитыВзаиморасчетов" (скрин 15) вызывается дополнительная процедура "icl_РеестрПлатежейЗаполнитьРеквизитыВзаиморасчетов" (скрин 16):
Скрин 15:
Скрин 16:
В дополнительной процедуре выполняется многопоточный вариант заполнения реквизитов взаиморасчетов (скрин 17):
Скрин 17:
Далее, после выполнения варианта многопоточного заполнения, продолжается выполнение в однопоточном режиме. Это сделано на случай, если после многопоточной обработки по какой-либо причине останутся необработанные записи.
Использование многопоточности в этом примере позволило уменьшить время выполнения обработчика с 10 часов до 3,5 часов. Общее время обновления рабочей базы на 8 релизов в результате использования многопоточности уменьшилось в 2,5 раза.
- При выборе способа обновления рабочей базы из вариантов ручного и полностью автоматического обновления вариант ручного обновления был сразу отклонен по следующим причинам:
- чтобы уложиться в предоставленное нам технологическое окно (60 часов, включая два выходных дня с захватом пятницы), проводить обновления нужно непрерывно, в том числе ночью;
- необходим постоянный контроль выполнения этапов обновления и успешного завершения обработчиков обновления ИБ.
- Вариант полностью автоматического процесса обновления рабочей базы на 8 релизов был обусловлен также имеющимся у нас опытом автоматизации CI/CD-операций с помощью инструмента автоматизации Jenkins. Процесс автообновления выполняется с помощью библиотеки OneScript – Vanessa runner. Итоговый алгоритм работы нашего конвейера составляет повторяющуюся 8 раз (общее количество обновлений) последовательность действий:
- Установка блокировки на вход в информационную базу;
- Установка блокировки регламентных заданий;
- Загрузка очередного файла конфигурации (cf) в информационную базу;
- Обновление информационной базы в режиме конфигуратора;
- Обновление информационной базы в режиме Предприятия;
- Ожидание выполнения завершения дополнительных обработчиков после обновления,
с отправкой автоматического уведомления в группу DevOps-инженеров Яндекс-мессенджера о результатах работы конвейера.
Благодаря полностью автономной работе "конвейер" позволил с запасом по времени выполнить все этапы обновлений рабочей базы в отведенный для этого период технологического окна.
Пример одного цикла "конвейера" (обновление на одну версию) в интерфейсе Jenkins (см. скрин 18):
Скрин 18:
Пример декларативного описания пайплайна (на Jenkins Pipeline DSL) для одного цикла "конвейера" (для обновления на одну версию):
- Чтобы уложиться с запасом в отведенное для обновления рабочей базы технологическое окно, необходимо было добиться выполнения всех этапов последовательных обновлений без ошибок и без длительных и неконтролируемых ожиданий (например, при выполнении обработчиков обновлений). Для контроля выполнения обработчиков отложенного обновления ИБ была подготовлена внешняя обработка 1С "Контроль завершения отложенных обработок". Логика работы обработки:
- На уровне скрипта в Jenkins подключен таймер, который каждые 5 минут запускает обработку 1С;
- Для ускорения процессов обновления ИБ обработка проверяет, а при необходимости – меняет параметр "Приоритет обработки данных" с режима "Работа пользователей" на "Обработка данных", и увеличивает значение параметра (константы) "Количество потоков обновления ИБ" с 8 до 16;
- В процессе обновления обработка проверяет успешность выполнения регламентного задания. В случае успешного завершения в определенном заранее каталоге создается файл success, в случае ошибки создается файл error;
- Скрипт в Jenkins мониторит наличие файлов в каталоге. Если появился файл success, Jenkins запускает следующий шаг конвейера, а если файл error - выполнение конвейера останавливается и отправляется уведомление в мессенджер. Если файл в каталоге отсутствует в течение 5 минут, выполняется повторная команда Jenkins на запуск скрипта с таймером.
В тексте представленного выше кода пайплайна наименование этой обработки - Update_controller_linux.epf . Вариант обработки можно скачать во вложении к статье. Возможно, она окажется вам полезной.
Скрин 19: Форма внешней обработки для контроля выполнения обработчиков отложенного обновления
Подходы и методы, используемые командой аналитиков в работе по переводу 1С:ERP. Управление холдингом с версии 3.1.8.15 на 3.2.5.2
Перед командой аналитиков была поставлена довольно сложная задача – оценить готовность к переносу на рабочую базу конфигурации, обновленной на 35 релизов (по числу стандартных этапов обновления). В таких условиях гарантию готовности конфигурации на Прод может дать только сплошное тестирование функциональных блоков.
Для проведения тестирования обновленной базы в максимально сжатые сроки с охватом функциональных блоков, наиболее критичных для Заказчика, были заранее подготовлены чек-листы проверок в разрезе блоков, объектов конфигурации. Чек-листы сведены в одну общую таблицу и опубликованы на сетевом ресурсе с возможностью совместного редактирования. Аналитики получили удобный инструмент для работы, а руководитель проекта – возможность оперативного контроля за текущим статусом работы группы, чтобы при необходимости перераспределять исполнителей по блокам и влиять на процесс тестирования в целом.
Для тестирования создания сложных и длинных цепочек документов использовался инструмент автоматического сценарного тестирования Vanessa Automation с заранее подготовленными сценариями. Выявленные по итогам тестов ошибки оперативно исправлялись.
Выбранный подход по раздельному тестированию в контуре разработки (выполняли аналитики от Исполнителя) и в контуре Заказчика (выполняли представители Заказчика) – позволил получить наиболее приближенную к действительности картину по результатам тестов.
В процессе адаптации разработчики нередко сталкивались с ситуацией, когда в целевом релизе по отношению к исходному была изменена не только часть кода, формирующего алгоритмы, но и сами алгоритмы - вследствие изменений в методологии получения или формирования данных. В этом случае доработанные объекты, требующие адаптации с учетом изменений в методологии, отмечались, а разработчики формировали в таск-трекере Jira отдельные задачи. В тех ситуациях, когда не была понятна причина методологических изменений, наши аналитики обращались за разъяснениями на линию консультации вендора "1С".
После получения разъяснений от вендора, Заказчику обосновывалась необходимость использовать обновленный типовой алгоритм. В большинстве подобных ситуаций адаптировать предыдущие доработки к новой версии не требовалось.
Разбор примера плана работ с использованием инструментов 1С:EDT + Git
Подробнее поэтапное выполнение работ по обновлению с использованием инструментов 1С:EDT + Git рассмотрим на примере другого проекта - переход 1С:ERP. Управление холдингом с версии 3.2.4.2 на 3.2.6.14 (7 промежуточных и 1 финальное обновление):
1. Подготовка файлов промежуточных обновлений. На этом этапе:
1.1. в проект EDT импортируются доработанная конфигурация исходной версии (3.2.4.2) и поочередно – все типовые конфигурации, соответствующие рекомендованному порядку обновления на целевой релиз от вендора 1С (c учетом исходной версии 3.2.4.2, всего было загружено 9 типовых версий конфигураций);
1.2. после загрузки в проект файлы конфигураций фиксируются в подключенном к проекту Git-репозитории. Типовые конфигурации – в одной ветке (в нашем случае – main), а нетиповая конфигурация исходного релиза (3.2.4.2) – в другой (icl_Release). Важно, что ветка icl_Release создана на базе ревизии с исходной типовой версией (3.2.4.2) ветки main;
1.3. далее в EDT при активной ветке icl_Release (на первом шаге там исходная доработанная версия конфигурации 3.2.4.2) выполняется команда "Слить" из ревизии ветки main с типовой конфигурацией версии 3.2.4.5;
1.4. при появлении окна сравнения, которое открывается с фильтром "Показывать потенциальные проблемы", проверяем (а при необходимости – меняем) настройки объединения по каждому объекту в этом списке. Если встречаем конфликты объединения для дважды измененных объектов, следуем правилу – при подготовке промежуточных обновлений в случае конфликтов приоритет имеют типовые изменения (внесенные вендором), а наши изменения адаптируем к типовой конфигурации на этапе подготовки финального обновления;
1.5. завершаем настройки в окне сравнения/объединения (см. Скрин 20) и выполняем команду "Объединить":
Скрин 20: Окно сравнения/объединения с фильтром "Показывать потенциальные проблемы"
1.6. после успешного завершения слияния веток обновляем конфигурацию подключенной к проекту базы полученной в результате слияния конфигурацией проекта, после чего выгружаем из EDT файл cf промежуточного обновления;
1.7. тестируем cf промежуточного обновления версии 3.2.4.5 - обновляем копию рабочей базы;
1.8. в случае успешного завершения тестового обновления копии рабочей базы фиксируем в репозитории изменения для ветки доработанных версий icl_Release (теперь там доработанная версия конфигурации 3.2.4.5), и переходим к следующему циклу слияния в эту ветку очередной ревизии (версии) ветки main;
1.9. повторяя шаги п.п. 1.3-1.8 для следующей версии, по очереди готовим и фиксируем в ветке icl_Release полный комплект файлов промежуточных обновлений на версии 3.2.5.2, 3.2.5.3, 3.2.6.3, 3.2.6.6, 3.2.6.7 и 3.2.6.10.
2. Подготовка файла финального обновления:
2.1. для файлов конфигурации финального обновления (версии 3.2.6.14) в репозитории была создана отдельная ветка icl_Release_3.2.6.14 из ревизии ветки icl_Release с исходной измененной версией конфигурации 3.2.4.2;
2.2. в EDT при активной ветке icl_Release_3.2.6.14 выполнена команда "Слить" из ревизии ветки main с типовой конфигурацией версии 3.2.6.14;
2.3. при появлении окна сравнения с фильтром "Показывать потенциальные проблемы", проверяем (а при необходимости – меняем) настройки объединения по каждому объекту в этом списке. В отличие от этапа подготовки промежуточных обновлений, на данном этапе подготовки финального обновления при конфликтах объединения для дважды измененных объектов все отмеченные в списке сравнения нетиповые изменения были адаптированы к финальной версии 3.2.6.14;
2.4. после выполнения команды "Объединить" полученная измененная конфигурация версии 3.2.6.14 также была выгружена в подключенную к проекту базу, из нее был выгружен cf финального обновления;
2.5. после успешного тестирования обновления копии рабочей базы с использованием полученного файла финального обновления конфигурации на версию 3.2.6.14 в ветке icl_Release_3.2.6.14 репозитория зафиксированы изменения – выполнен коммит состояния для измененной конфигурации целевой версии 3.2.6.14.
В результате выполненных действий по описанному выше алгоритму дерево репозитория, подключенного к EDT (см. Скрин 21), наглядно отражает историю происхождения промежуточных и финальной версии конфигураций.
Скрин 21:
3. В тестовой копии рабочей базы, обновленной на финальную версию, выполнены дымовые и синтаксические тесты, с последующим анализом их результатов и исправлением выявленных ошибок;
4. После функционального тестирования, выполненного аналитиками и представителями Заказчика проекта в обновленной копии Прода, рабочая база Заказчика успешно обновлена "конвейером" Jenkins;
5. В настоящее время обновления рабочей базы этого и других проектов выполняются в среднем в течение 1 месяца с момента выхода новых версий конфигурации. Сам процесс подготовки комплектов обновлений конфигурации поставлен "на поток".
Развитие используемых технологий. Планы
1. После завершения рассмотренного выше проекта комплексного обновления 1С:ERP. Управление холдингом с Заказчиком проекта был согласован регламент обновления рабочей базы в течение 1-2 месяцев после выхода очередного релиза конфигурации;
2. Учитывая накопленный опыт предыдущих обновлений (в том числе по рассмотренному выше проекту) и полученные командой знания и навыки использования новых рабочих инструментов, мы пересмотрели состав используемых технологий для подготовки обновлений. В настоящее время для этих целей используем связку 1С:EDT + Git;
3. Преимущества от использования инструментов 1C:EDT + Git при подготовке обновлений:
• Значительное уменьшение времени на подготовку файлов обновлений. Время подготовки обновления на одну версию конфигурации (без адаптации расширений) составляет 1-2 рабочих дня, в зависимости от объема нетиповых изменений в конфигурации;
• За счет возможностей EDT "на лету" выполнять углубленную проверку конфигурации при изменении ее структуры, повысилось качество подготовки файлов обновлений, а количество возможных ошибок в результате обновления рабочей базы стало значительно меньше;
• EDT отлично справляется с дважды измененными объектами, автоматически разрешая большинство конфликтных ситуаций.
4. В дальнейшем, для повышения качества подготовки комплектов обновлений и снижения рисков попадания ошибок в рабочую базу, мы планируем развивать существующие и расширять состав инструментов, используемых в работе. В настоящее время в работе и в наших ближайших планах:
• добавление в состав конвейера CI/CD сценарных тестов на Vanessa Automation для тестирования сложных функциональных блоков;
• ревизия текущих редакций библиотек Jenkins-lib, используемых для дымовых и синтаксических тестов (сейчас фиксируется много ложных ошибок).
Проверено на следующих конфигурациях и релизах:
- 1С:Управление холдингом 3.2 (русский и английский интерфейсы), релизы 3.2.4.2
Вступайте в нашу телеграмм-группу Инфостарт
