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

Марк Левин19.08.2018

0 24 Время чтения: 10 мин.

Предисловие

До окончания ВУЗА оставалась не много времени, и перспектива написания диплома уже маячила перед глазами. Все началось более 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-6 часов рабочего времени. Когда эта база весит 5-10 гбт – это не проблема, а когда она только в бэкапе весит почти терабайт то это уже серьезно. Когда мне это надоело я начал пользоваться очень хорошим инструментом 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С.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги