DevOPS Управление разработкой из 1С

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

 

 

Это Даня Кузнецов. Мы с ним вместе работали над тем решением, о котором сейчас пойдет речь. Он терпеть не может комментарии в коде и ведет с ними упорную борьбу.

 

 

А это – я, Паша Чегодаев. Я технический архитектор и работаю с 1С с тех времен, когда у меня еще не росла борода. Борюсь за чистый код и интересуюсь всеми новинками в 1С. Много работал с WMS – запустил на нем порядка 20 проектов.

А самое главное – я идеологически отвечаю за то решение, о котором сейчас пойдет речь

 

 

Расскажу, с чего все начиналось. Мы работали в компании, где у нас было:

• 20 разработчиков, живущих в постоянной борьбе с более чем 500 внешними обработками, в которых было реализовано все, что можно:

  • печатные формы;

  • подмена форм документов и справочников;

  • регламентные задания;

  • отчеты;

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

• Более 20 баз на разных серверах, обновлять которые нужно было вручную – это было долго и неудобно.

• Проводить нормальный code review было невозможно – чтобы увидеть изменения, приходилось вручную сравнивать множество обработок с версиями 1, 2, 3.

 

 

• Еще одна проблема – огромное количество комментариев в коде внешних обработок. Каждый программист при изменении оставлял комментарий, и в итоге на одну строку кода могла получиться такая простыня. Даже скроллить это было утомительно – рука уставала. Как говорится: «More comments… No comments».

 

 

Мы поставили себе цель – организовать групповую разработку по модели ветвления Git Flow, чтобы:

• Добиться удобной работы с внешними обработками.

• Сократить время ожидания их сборки-разборки.

• Так как наши коллеги по команде не работали с Git, мы хотели сделать инструмент, который позволит быстро подключить к проекту нового разработчика,

• Вести историю замечаний Code Review.

• Внедрить автотесты.

• И внедрить автоматизированную сборку релизов.

 

 

Нашей первой попыткой организовать управление обработками стало «хранилище обработок» – подсистема, интегрированная в форму «Дополнительные отчеты и обработки». Работать с ней было достаточно удобно: программист, как и в случае с хранилищем конфигурации, мог «захватить» нужную обработку, получить ее актуальную версию и быть уверенным, что он работает с последними данными. И интерфейс был удобным, все было под рукой.

Однако там было что улучшить:

• Возникала проблема с последовательностью разработки: если один программист захватывал обработку, другой уже не мог ничего с ней делать.

• Было сложно проводить code review.

• Не было истории изменений.

 

 

Мы решили это поменять. Нарисовали схему работы, распределили роли: программист, аналитик, тимлид, релизер. И пошли со всем этим к руководству нашей компании.

 

 

Руководство выдвинуло свои требования: «Да, мы согласны использовать Git, но это все должно быть одной кнопкой».

Мы начали думать, какой стек выбрать, и решили, что у нас будет бэк и фронт.

Бэк мы решили построить на скриптах OneScript для работы с конфигурацией, кластером серверов, Git и так далее – тут никаких проблем не было.

А с фронтовой частью возникли проблемы:

• В интернете мало информации о том, как организовать интерфейс для скриптов.

• Задавать вопросы в чатах 1С-ников, где тысячи участников, было страшно – мы не знали, как формулировать сообщения, чтобы не чувствовать себя глупо. Старались максимально тщательно все описывать, чтобы избежать лишних уточнений.

• И самое главное – мы не понимали, где хранить настройки баз, кластеров и всего вот этого.

Пришлось пройти длинный и тернистый путь.

 

 

Начали мы со скриптов, как и большинство тех, кто пытается запустить DevOps у себя в компании. Перечитали множество статей на Инфостарте, нашли нужные нам скрипты и стали запускать их вручную. Это было долго и неудобно, но полезно – так мы разобрались, как устроена вся эта система и из чего состоит.

Потом решили встроить скрипты в графический интерфейс – для OneScript есть библиотека, позволяющая отрисовывать формы и мы собрали что-то вроде панели с кнопками «Собрать обработку» и т.д. Саму форму, как это выглядело, я сейчас уже найти не могу, но это могло бы выглядеть примерно так, как на слайде. К сожалению, возможностей этой библиотеки нам оказалось мало – она не позволяла реализовать все, что мы хотим, и работать с такой формой было сложно.

 

 

Поэтому мы попробовали другой вариант – библиотеку https://github.com/autumn-library/winow winow, разработанную Никитой Иванченко. Протестировали разные подходы, но и тут столкнулись с ограничениями: чтобы сделать действительно удобный и красивый интерфейс, нужно было хотя бы немного знать JavaScript, HTML и CSS. У нас что-то получилось, но не очень красиво, поэтому мы стали искать другой путь.

 

 

Так мы пришли к идее использовать полноценную обработку в 1С. Сначала в ней была всего одна галочка – «Собрать обработки», а потом появились и другие: «Обновить базу из файлов», «Заблокировать базу», «Обновить обработки в конфигурации» и т.д.

 

 

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

 

PIVO: светлая и темная сторона

 

 

Мы назвали свой продукт аббревиатурой PIVO – Pivot Integration Version Operation, что можно перевести как «центральная точка интеграции, контроля версии и успешного выполнения операций». Поначалу у нас были амбиции построить интерфейс на Winow, но в итоге мы немного снизили градус наших амбиций и создали PIVO.

 

 

Архитектура репозиториев развивалась следующим образом:

• Первая версия – за каждым разработчиком был закреплен свой репозиторий. Но если разработчик работал параллельно с несколькими задачами в нескольких базах, это вызывало проблемы.

• Вторая версия – репозиторий закреплялся уже за конкретной базой разработчика. Это давало возможность вести параллельно несколько задач, не вызывая никаких расслоений. Плюс у нас в архитектуре репозиториев появилось CLI-приложение, которое управляет всеми исходниками в этих репозиториях.

 

 

Сам инструментарий PIVO можно условно поделить на две части:

• Светлая сторона – это наша любимая 1С, где мы даем разработчику возможность работать с Git и храним настройки баз и кластеров.

• И темная сторона – OneScript. Про эту сторону пользователь ничего не знает, однако именно она отправляет все команды от 1С в Git и управляет подключенными базами.

 

 

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

Все задачи у нас ведутся в таск-трекере, который реализован на Битриксе. Программист, когда берет задачу в работу, нажимает кнопку «Новая задача», вбивает ее номер в специальном рабочем месте, и, благодаря интеграции с Битриксом, система автоматически подтягивает всю необходимую информацию – название, описание и т.д.

 

 

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

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

 

 

После этого разработчик нажимает кнопку «Перейти на задачу» и происходит магия – система автоматически собирает окружение, и нужные внешние обработки автоматически перекидывается в специальную папку для разработки.

 

 

Когда разработчик ее доработал, он нажимает кнопку «Зафиксировать изменения в GIT по задаче» – в этот момент происходит коммит, и обновленные файлы 1С отправляются в GitLab.

 

 

После этого разработчик нажимает кнопку «Создать заявку на слияние (MR) и изменения переносятся в базу.

И еще в этом рабочем месте есть возможность запустить тесты – например, когда аналитик хочет протестировать задачу, он выбирает свою базу, находит нужную задачу, нажимает кнопку «Запустить тестирование», и у него разворачивается база именно с тем окружением, под которое сделали эту задачу.

 

PIVO: темная сторона

 

Наш бэкенд написан на OneScript с использованием фреймворка Autumn-CLI.

 

 

В этом приложении реализовано порядка 20 команд. Выделим несколько ключевых:

• Branch – переключение на ветку из 1С. При этом из исходников компилируются расширения, обработки и конфигурация.

• Commit – декомпиляция конфигурации, расширения, обработок в исходники, коммит и пуш в git.

• BuildRelease – сборка релизов: переходим на ветку main, компиляция нужных объектов и помещение конфигурации и расширений в хранилище продуктивной базы.

• UpdateDB – обновление рабочей базы из хранилища, обновление внешних обработок через HTTP.

 

Преодолевая проблемы

 

 

Одна из первых проблем, с которой мы столкнулись – это версионирование обработок.

У нас так заведено, что в модуле объекта каждой обработки хранится номер версии и описание изменений для этой версии. И когда над одной и той же обработкой параллельно работают разные программисты, при слиянии изменений в строке версии практически гарантированно возникал конфликт.

Решение: мы сделали скрипт, который автоматически меняет версию и собирает описание изменений на основе коммитов разработчиков именно в момент помещения в main – т.е. в момент сборки релиза.

 

 

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

Решение: создали скрипт, который при создании новой обработки копирует файлы из исходников шаблона, заменяет там имя в названии файлов и в XML, пушит это все в Git, компилирует новую обработку, и подкладывает в специальный каталог разработчика.

В результате программист нажимает «Создать новую обработку» и через некоторое время у него уже в папочке все лежит – он дальше с ней начинает работать, как с готовой.

И одновременно PIVO создает в нужной базе новый элемент справочника «Дополнительные отчеты и обработки», чтобы можно было с этим дальше работать.

 

 

И еще у нас была проблема с масштабированием.

Когда мы работали с нашим PIVO-м в рамках одного конкретного проекта, все было отлично. Но когда PIVO начало «разливаться» по другим серверам, появилась проблема: из-за высоких пингов в локальной сети сборка конфигурации могла занимать не 5, а 50 минут.

Решение: мы придумали PIVO-агенты. На каждом сервере мы разместили репозиторий со скриптами OneScript, наше CLI-приложение и базу 1С, принимающую HTTP-вызовы. Центральное PIVO отправляет агенту только команду запуска, а вся работа с исходниками происходит локально. Это ускорило процесс примерно в 10 раз.

Почему не Jenkins? Мы тогда о нем еще не знали, плюс были проблемы с бюрократией и требованиями к информационной безопасности.

 

Подходы к разработке PIVO глазами технического архитектора

 

 

В основе нашей базы лежит Библиотека стандартных подсистем (БСП).

Понятно, что при создании мы забрали себе оттуда только самое необходимое. Но никогда же не знаешь, что тебе может потребоваться. А тут – бац! И нужны графики работы. С БСП достаточно сделать два клика, и они уже в решении. Потребовалось отправлять сообщение на почту о релизе? Никаких проблем – быстро внедрили шаблоны сообщений.

Поэтому БСП – это классное решение, чтобы разрабатывать свою базу.

Мы проектировали PIVO как масштабируемое решение, чтобы потом его можно было использовать и в других компаниях. Например:

• Работу с таск-трекером можно легко подменить на Jira или что-то еще.

• Сделали, чтобы для разных операционных систем серверов можно было переключаться с CMD на Shell, где команды запуска будут немного другие.

• Для управления серверами по HTTP реализовали паттерн «Стратегия» – благодаря этому мы можем легко менять способы для локального и удаленного запуска процессов.

• А еще ради эксперимента мы реализовали работу с логами с помощью паттерна «Строитель».

 

Тесты и релизы

 

 

Чтобы тестировать код, мы используем автотесты и фреймворк Vanessa Automation.

• Структура тестов организована в виде папок в проводнике Windows – каждая папка соответствует определенному бизнес-процессу проекта. Например, структура тестовых сценариев для WMS разбита на процессы «Отборы», «Отгрузки», «Перемещения», «Приемки». И в одноименные папки мы складываем наши WMS-овские feature-файлы.

• Разработчик при выполнении задачи указывает, какие процессы он затронул при разработке, и запускаются именно эти тесты.

• Самое тестирование автоматизировано через Jenkins.

• При создании мерж-реквест из 1С запускается параметризированная сборка в Jenkins, и тесты стартуют автоматически.

Для сборки релиза:

• Мы собираем изменения по коммитам в ветке main.

• По уже влитым веткам получаем список задач и список объектов, которые были изменены.

• Производим авторассылку по почте ответственным лицам, нашим аналитикам.

• Они аппрувят задачи, и мы это все собираем уже в базу, подключенную к нашему продуктовому хранилищу.

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

Весь процесс максимально автоматизирован – для запуска достаточно нажать кнопку «Собрать релиз».

 

 

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

• Заблокировать базу – сбрасывает все сеансы и блокирует базу.

• Обновить базу – подтягивает актуальную версию из продуктового хранилища

• Открыть базу – позволяет открыть базу, пока она еще заблокирована.

• Обновить обработки – загружает по HTTP внешние обработки в базу 1С, в справочник «Дополнительные отчеты и обработки».

 

Аппетит приходит во время еды

 

А еще в PIVO много вспомогательных возможностей:

• Интеграция с таск-трекером – мы об этом уже немного рассказали.

 

 

• Планирование спринта – в Битриксе оно реализовано неудобно, из-за чего перепланирование занимает кучу времени. А тут, поскольку у нас уже была настроена интеграция с Битриксом, мы решили добавить еще и планирование спринтов.

 

 

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

 

 

• Обработка для проведения код-ревью прямо в самой базе. На INFOSTART TECH EVENT 2024 ребята рассказывали про инструмент Git Code Review. Классная обработка – всем советую ее посмотреть, мы оттуда некоторые моменты тоже взяли.

• Работа с базами – мы можем их запускать прямо из PIVO.

• Возможность подключиться к RDP.

 

 

• Обработка «Анализ разработки», с помощью которой мы можем:

  • видеть список задач за период;

  • по каждой задаче видеть связанные мерж-реквесты;

  • по каждому мерж-реквесту видеть объекты, которые менялись – общие модули, внешние обработки и так далее;

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

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

  • анализировать риски релизов через диаграмму критичности (например, 50/50 по вероятности ошибок – еще допустимо, 20/80 – повод готовиться к проблемам.

 

Наши планы

 

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

• Побороть админов и договориться использовать docker для тестов.

• Выложить наработки в open source.

• Покрыть тестами наше решение.

• Хотим быть модными и молодежными, внедрить ИИ, но пока не знаем как.

• И когда-нибудь хотим перейти на новый интерфейс 1С, так как это наше всеобщее будущее.

 

Итоги

 

Чего удалось добиться?

• Мы за неделю перевели всех разработчиков ERP на эту систему. И хотя ребята до этого не знали, что такое GIT, и не умели с ним работать, им было достаточно легко начать.

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

• Организовали цивилизованную работу множества разработчиков с множеством внешних обработок.

• И сумели побороть некоторые ошибки человеческого фактора при сборке релизов и обновлении баз.

Вы можете попробовать наше решение, мы выложили его на github https://github.com/Untru/gitmanager - 1С Часть

https://github.com/Untru/pivo-cli - CLI Часть на оскрипт

 

 

Хочется сказать спасибо.

• Никите Иванченко – без его поддержки у нас бы ничего не получилось.

• Егору Иванову – за помощь с DevOps.

• Андрею Овсянкину – за OneScript.

• И еще у нас внутри компании был Миша Новиков, который нас всегда поддерживал, тестировал, помогал, подсказывал.

 

Вопросы и ответы

 

Вы упоминали, что ваши коллеги-разработчики ERP до этого внедрения не знали, что такое Git. Мне кажется, что вы и сейчас от них все, связанное с Git, хорошо скрыли. Они хоть чуть-чуть теперь знают, что такое GIT?

Знают, потому что все равно есть конфликты, а конфликты надо решать в VS Code. Поэтому им пришлось это узнать. Но мы их подводили к этому постепенно.

А почему вы решили использовать внешние обработки, а не расширения?

База существует очень давно. Насколько я знаю, в те времена расширений вообще не было, либо их было очень мало.

Все эти обработки накапливались годами. Я думаю, что изначально они появились как способ быстро что-то исправить, потому что тестировщиков в компании не было, а баги были.

А что делать, если нужно обновить одну и ту же обработку в разных базах?

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

Бывает ли такое, что одна и та же обработка в разных базах должна отличаться?

Такие обработки есть, но они и с точки зрения Git разные и лежат в разных проектах – у нас на каждом кластере свой репозиторий проекта.

Если у вас есть Git, зачем вам еще и продуктовое хранилище конфигурации?

При сборке релиз загружается в хранилище – это быстрее, чем накатывать напрямую. Мы не нашли причин менять этот процесс.

Что нужно сделать, чтобы с нуля развернуть вашу систему на пустом сервере?

На пустом сервере должна быть установлена платформа 1С, OneScript, библиотеки OneScript, Jenkins (опционально) и опубликована база агента, чтобы туда передавать команды по HTTP. Плюс для базы агента должен быть расшарен каталог, где хранятся скрипты.

Правильно ли я понимаю, что для запуска PIVO-агента нужна лицензия 1С?

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

Почему не пошли по пути, когда все обработки лежат в Git, и изменения вносятся только через него?

Мы хотели, чтобы аналитики могли работать с задачами без глубокого погружения в Git. У нас есть сервис, который загружает в базу только нужные для конкретной задачи обработки. Это проще, чем втягивать аналитиков в Git-процессы.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD & CIO EVENT.