Как я написал и защитил диплом по DEVOPS и инженерным практикам в 1С с нуля

Предисловие

​Все началось более 2-х лет тому назад, и я перешел на 4-й курс специальности "Бизнес-информатика" Томского Государственного Университета Систем Управления и Радиоэлектроники (ТУСУР). До окончания ВУЗА оставалась не много времени, и перспектива написания диплома уже маячила перед глазами. Мысль о покупке готовой работы не рассматривалась. Хотелось реально что-то сделать самому. Вариантов тем дипломных проектов рассматривалось много: и проекты конфигураций для автоматизации производственных нужд компании и проект внедрения Документооборота своими силами на 3 территориальные единицы и более 500 активных пользователей и внедрение ЭДО. Короче много всего что было в голове, но ничего из этого не вдохновляло. А это было главное.

В это время я работал в одной уважаемой компании и по делам службы познакомился с одним классным программистом и вообще хорошим человеком Андреем Щегловым (Привет Андрей!) и как =-то за разговором он у меня спросил, слышал ли я что-нибудь об OneScript и языке сценариев Gherkin. На что и получил ответ что нет, не слышал. Естественно, вечернее гугление/яндексение и бессонная ночь привела на мысль что вот он — мир неизведанного. Но идея о том, что это может стать темой дипломной работы пока не зарождалась. Рутинный круг обязанностей составлял обычную работу в Конфигураторе 1С по-задачно, как вы понимаете с ручным тестированием и не позволял полностью погрузиться в новый подход в мире 1С.

Незнакомые понятия

​ Первая трудность с чем я столкнулся, это неимоверное количество различных терминологий и инструментов, о которых вообще не слышал — так как я в тот момент был «типичным одинэсником» (в этот момент начинается холивар…) Особо не владея никакими другими языками программирования, и к тому же методологии большого IT для меня были абсолютно не знакомыми, мне приходилось прыгать с темы на тему, чтобы хоть как-то наполнить свой глоссарий.

​ Практически в этот же момент я (мы – и мои коллеги) столкнулись с довольно специфичной проблемой. Приняли программный модуль от подрядчика, проверили на копии. Вроде все работает. Но так как работы было очень много, то подписали акт выполненных работ и закинули в продуктив. Все было хорошо в течении полугода, пока данных в этой подсистеме не превысило допустимого. И начали происходить очень странные вещи. Проведение документа из модуля стало происходить по 5-10 минут, появились куча ошибок ну и.т.п. Просмотр программного кода привел в ужас (не спрашивайте почему это не сделали раньше при приемке…). Количество вложенных циклов было просто за гранью разумного. Единственный запрос в четвертом цикле и обращение через 4 точки были мелочами, перебор всех предыдущих документов для заполнения текущего документа, 10-ти кратный копипаст одного и того же блока и много еще чего.

Пример вложенности:

Дублирование полей в макете:

Причем для заполнения этих полей, 14-ти кратный кописпаст.

Начало цикла:

И пока переменная ФФ не достигнет 15:

Ну и еще куча других не менее уникальных произведений искусства.

​ Вдруг я вспомнил, что для OneScript есть простенькая библиотека для расчета "цикломатичности" модуля(1) (сложности модуля или метода). Нашел, рассчитал. Получил значение 163 единицы, при допустимом значении не более 10. И пришел к выводу, что приемочное тестирование программного кода должно быть обязательно и оно должно быть автоматическим и непрерывным. Тогда я узнал о Continuous Inspection — причем как оказалось еще в 2006 году компания IBM сделала(2) публикацию на эту тему.

​ Дальше больше. Наверное, многие работающие в крупных компаниях встречались с проблемой разворачивания копии рабочей базы на локальной машине разработчика. Когда эта база весит 5-10 гбт – это не проблема, а когда она только в бэкапе весит почти терабайт то это уже серьезно. В итоге для того, чтобы развернуть у себя свежую копию тратилось по 5-6 часов рабочего времени. Когда мне это надоело я начал пользоваться очень хорошим инструментом 1C-Deploy-and-CopyDB (Степа спасибо!) Тогда я понял, что автоматизация – это классно.

​ Дальше были другие задачи, например, регулярное обновление основной и распределенной базы из хранилища ночью, тестирование форм, сценарные тесты и.т.д. Что-то было из этого реализовано, а что-то нет.

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

Github проекты:

• https://github.com/silverbulleters/add

• https://github.com/oscript-library/opm

• https://github.com/EvilBeaver/OneScript

• https://github.com/silverbulleters/vanessa-runner/

Форум XDD:

• раздел по 1Script

• раздел по тестированию

• раздел по автоматизации процесса

Ну и как средство быстрой связи — профильные группы в Gitter

​ Начался сбор материала. Волею судеб мне удалось мне связаться на форуме XDD с Алексеем Лустиным alexey-lustin (Привет Алексей!) и рассказать про мою идею диплома. На что, с удивлением услышал, одобрительный отзыв и даже приглашение пройти в компании «Серебряная Пуля» преддипломную практику. Это была уже победа. В течении нескольких часов мы придумывали тему и содержание диплома. Ставили задачи на практические работы. Получил руководителя дипломного проекта от компании — Артур Аюханов (Артур привет!) Как юный падаван получил доступ к видеокурсу релиз-инженера и возможности неограниченно доставать Никиту Грызлова (Привет Никита!) своими вопросами, за что ему очень признателен.

В итоге:

Тема диплома — «Автоматизированное управление жизненным циклом информационных систем — системная и программная инженерия решений на платформе 1С: Предприятие в условиях непрерывного улучшения качества процесса производства».

Цель выпускной квалификационной работы (ВКР) — выявление взаимосвязи программных инструментов и описание бизнес-процесса работы контура DevOps в области 1С.

Теоретическим обоснованием проекта был стандарт непрерывного улучшения качества сервиса из ITIL 3.0, а в качестве практического объекта было выбрано построение контура непрерывной интеграции для нового прикладного решения, которое мы разработали – личный кабинет покупателя. Для этого был развернут сервер исходных кодов GitLab и сборочный контур Jenkins. Прогон тестов осуществлялся на выделенном сервере (Windows Slave). Выгрузка конфигурации из хранилища 1С осуществлялась посредством библиотеки Gitsync, редакция 3.0

(в настоящий момент размещен в ветке develop) уже с наработками Алексея Хорева (Леха привет!) с периодичностью 30 минут в ветку develop. Причиной выбора именно этой версии была возможность подключения к хранилищу через протокол tcp, который, к сожалению, не поддерживал на тот момент типовой GitSync 2.x. Если в GitLab фиксировались изменения, то автоматически запускался прогон контура непрерывной интеграции.

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

​ На этапе тестирования функционала были задействованы 2 фреймворка Vanessa-Behavior и XUnitFor1C в их объединенном варианте под названием Vanessa Automation Driven Development (Vanessa ADD). Первый использовался для запуска тестировании ожидаемого поведения, вторым осуществлялась проверка открытия форм (дымовое тестирование). Результатом прохождения контура непрерывной интеграции были автоматически сгенерированные отчеты.

По результатам тестирования, релиз – инженер принимал решение о слиянии ветки develop и master, и запускал (уже вручную) третью задачу – публикацию изменений в продуктивную базу. Продуктивная база не подключена к хранилищу и полностью закрыта от ручных изменений. Обновление осуществляется только через поставку, причем в автоматическом режиме.

​ Для описания бизнес-процесса работы контура была сформирована диаграмма IDEF0 состоящая из 4 последовательных блоков, формирующих прохождение контура. Ошибка возникающая при прохождении любого из этапов прерывает сборочный процесс с оповещением релиз-инженера и передает управление на 5 блок сборочного процесса, где и формируются отчеты в в формате ALLURE, JUNIT и конечно cucumber.json.

Описание модели IDEF0

Процесс «Выгрузка исходников в GIT»

Входные данные(Input): – Хранилище конфигурации
Выходные данные (Output): – Исходный код
Управление (Control): Инструкции по работе с ПО, сборочный скрипт
Механизм (Mechanism): 1С: Предприятие, Gitsync.

Обязательным условием существования контура является наличие файлов исходного текста. С версии платформы 8.3.6 компания 1С предоставила возможность выгрузки исходных кодов конфигурации в файлы. Следует учесть, что данный процесс может иметь несколько вариантов исполнения, зависящих от специфики разработки в IT отделе. В текущем варианте для упрощения процесса перехода сотрудников к новой методике была выполнена интеграция с текущим процессом разработки через хранилище конфигурации и используя конфигуратор 1С.

На этапе выполнения процесса «Выгрузка исходников в GIT» будет произведено создание файловой, служебной информационной базы 1С; осуществлено ее подключение к хранилищу конфигурации под служебной учетной записью; получены все изменения на текущий момент времени (или последнему коммиту в хранилище); произведена выгрузка исходников в сборочную директорию; сделан коммит в систему хранения версий GIT; изменения отправляются на сервер исходных кодов GitLab

Процесс «Тестирование качества исходного кода»

Входные данные(Input): – Исходный код
Выходные данные (Output): – Исходный код
Управление (Control): Инструкции по работе с ПО, сборочный скрипт
Механизм (Mechanism): 1С: Предприятие, Deployka, SonarQube, Cyclo.os — (к сожалению ссылки нет)

На момент старта данного процесса, исходный код хранится в репозитарии GitLab. С помощью управляющего (сборочного) скрипта производится получение его в сборочную директорию. Средствами платформы 1С: Предприятие, на основании этих исходных кодов разворачивается служебная информационная база. Производится анализ ошибок средствами платформы. В случае, если при выполнении анализа будут обнаружены ошибки программного кода, не позволяющие собрать конфигурацию, то процесс прервется. Цель данного шага – исключение потерь времени на анализ программного кода неработоспособной конфигурации.

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

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

Процесс «Тестирование функционала»

Входные данные(Input): – Исходный код
Выходные данные (Output): – Исходный код
Управление (Control): Инструкции по работе с ПО, сборочный скрипт
Механизм (Mechanism): 1С: Предприятие, Vanessa-Behavior, XunitFor1C.

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

Для данного контура применимо несколько методов разработки и тестирования: TDD (Test Driven Development) и BDD (Behaviour Driven Development)

На момент написания ВКР, для выполнения тестов по Методике BDD использовался фреймворк Vanessa-bahavior, для TDD – XunitFor1C. В настоящий момент они объединены под одним продуктом Vanessa-ADD. Поддержка старых продуктов разработчиком прекращена. Результаты тестирования выводятся в файлы отчетов Yandex Allure и Xunit.

Процесс «Сборка поставки»

Входные данные(Input): – Исходный код
Выходные данные (Output): – Поставка конфигурации
Управление (Control): Инструкции по работе с ПО, сборочный скрипт
Механизм (Mechanism): 1С: Предприятие, packman.

В данном процессе происходит окончательная сборка поставки конфигурации для развертывания в целевой системе. Проверенный исходный код находится в ветке develop репозитария исходных кодов GitLab. Для формирования поставки необходимо, что бы изменения из ветки develop появились в ветке master. Это действие может происходить как вручную, так и автоматически и регламентируются требованиями IT подразделения использующего контур CI/CD. После слияния веток запускается процесс сборки готовой поставки. Для этого опять в сборочной директории, на основании существующих исходников, создается служебная информационная база, и затем, средствами платформы 1С: Предприятие формируется поставка конфигурации и архивируется. Поставка конфигурации является финальным продуктом сборочного процесса и поставляется заказчику по установленным каналам связи или же устанавливается непосредственно в продуктивную информационную систему.

Процесс «Публикация результатов»

Входные данные(Input): – Результат выгрузки, файлы отчетов
Выходные данные (Output): – Отчет
Управление (Control): Инструкции по работе с ПО, сборочный скрипт
Механизм (Mechanism): Yandex Allure, Xunit.

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

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

Результатами моего проекта стала защита ВКР в конце мая этого года с результатом «отлично». Дополнительно, была актуализирована методическая информация по формированию контура.

Общие выводы:

1. Экономический эффект возможен только в долгосрочной перспективе. По опыту замечено, что при запуске проекта имплементации инженерных практик фиксируется снижение производительности разработки на 20-30% от текущего уровня. Этот период временный, и как правило производительность возвращается к первоначальным значениям через три – четыре месяца эксплуатации. Снижение производительности связанно прежде всего, с тем, что разработчику приходится привыкать к новым требованиям разработки: написанию сценариев, тестов, формированию технической документации.
2. Существенно повысилось стабильность продуктивной информационной системы, за счет тестирования программного кода. Гарантированная работа критически важных подсистем обеспечена покрытием сценарными тестами. За счет этого снизились риски компании на критически важном направлении — оперативное взаимодействие с клиентами.
3. Исключение динамических исправлений на продуктивной информационной базе позволило более конструктивно планировать разработку и исключить попадание программного кода в обход контура тестирования.
4. Снижение трудозатрат на сервисное обслуживание информационной базы, за счет автоматизации сборочного контура.
5. Использование обратной связи через Slack позволило в оперативном режиме контролировать и исправлять проблемы жизненного цикла системы. По отзывам команды, использование месенджера, удобнее почтовой рассылки (хотя она тоже присутствует).
6. Использование автоматизированной проверки программного кода (Continuous Inspection) на соответствие стандартам разработки (SonarQube) вынуждает разработчиков самостоятельно повышать компетенцию, а исправление выявленного технического долга непосредственно при разработке программного модуля происходит гораздо быстрее, так как не надо тратить время на восстановление контекста задачи.
7. Включение функционала авто-документации и генерации видео-инструкций позволяют снизить количество обращений пользователей.
8. В ходе выполнения проекта был сформирован бизнес-процесс, описывающий жизненный цикл разработки и тестирования прикладных решений 1С, который в свою очередь повлиял на формирование проекта имплементации инженерных практик. Сформирован набор инструментов и документации, позволяющий быстро развернуть окружение на любых проектах 1С.

Если говорить о сложностях с которыми я столкнулся во время реализации проекта, то они абсолютно такие же как в статье Сопротивления автоматизации тестирования. В 90% случаев связанны либо со внутренним сопротивлением компании на изменение существующей модели разработки либо отсутствием на тот момент достаточных знаний.

Что же касается личных результатов, то они такие:

1. На сколько я знаю, на текущий момент это первый диплом по теме "Имплементации инженерных практик в 1С. Де-юре можно сказать, что инженерные практики пусть и в начальном варианте, но приняты научным сообществом (пусть их и было 5 человек).
2. Подобный академический подход позволил ускорить выход “Методического пособия релиз инженера 1С”. Часть контента из дипломной работы плавно перекочевала в контент книги. (Ссылка к сожалению, запрещена модератором вне рубрики "Я пиарюсь". Кому потребуется смогут легко найти в поиске).
3. Проработка модели процесса и проверка инструментария для CICD в 1С позволило исправить мелкие недочеты при первом старте и подключении к процессу, кстати уже и мои доработки приняты в основной ствол и войдут в релиз 5.5.0.

В заключении, хочу сказать, что 1С хоть и медленно, но двигается к полноценному DevOps. В настоящее время достаточно инструментов для построения контуров, но несколько тормозит процесс развития — это недостаточное количество специалистов DevOps в среде 1С и незнание руководителей о существовании таких возможностей.

Буду очень признателен, если Вы приведете свое мнение о концепции DevOps в 1С. Чего по вашему мнению не хватает отрасли?

Автор: Руслан Жданов

Источник