Предисловие Все началось более 2 лет назад, и я перешел на 4 курс специальности "Бизнес-информатика" в Томский государственный университет систем управления и радиоэлектроники (ТУСУР).
До окончания университета оставалось не так много времени, а перед глазами уже маячила перспектива написания диплома.
Мысль о покупке готовой работы не рассматривалась.
Мне очень хотелось сделать что-нибудь самому.
Было рассмотрено множество вариантов тем дипломных проектов: проекты настройки автоматизации производственных нужд компании и проект внедрения Документооборота собственными силами для 3-х территориальных единиц и более 500 активных пользователей и внедрение ДО.
Короче говоря, в голове было много всего, но ничего из этого меня не вдохновляло.
И это было главное.
В то время я работал в уважаемой компании и по служебным делам познакомился с прекрасным программистом и вообще хорошим человеком Андреем Щегловым (Привет Андрей!) и как в ходе разговора он спросил меня, слышал ли я что-нибудь об OneScript и Язык сценариев Gherkin. На что получил ответ, что нет, не слышал.
Естественно, вечернее гугление/яндексирование и бессонная ночь привели к мысли, что это мир неизведанного.
Но мысли о том, что это могло бы стать темой диссертации, пока не возникло.
Рутинный круг обязанностей состоял из обычной работы в 1С Конфигураторе позадачно, как вы понимаете при ручном тестировании и не позволял нам полностью погрузиться в новый подход в мире 1С.
Незнакомые понятия
Первой трудностью, с которой я столкнулся, было невероятное количество различной терминологии и инструментов, о которых я никогда не слышал - так как на тот момент я был "типичным специалистом-одноязычником" (в этот момент начинается холивар.) Не особо свободно владею ни на каких других языках программирования, и более того, методологии больших ИТ были мне совершенно незнакомы; Мне приходилось перескакивать с темы на тему, чтобы хоть как-то пополнить свой глоссарий.
Практически в этот же момент я (мы – и мои коллеги) столкнулись с довольно конкретной проблемой.
Мы приняли программный модуль от подрядчика и проверили его на наличие копии.
Кажется, все работает. Но так как работы было много, то подписали акт выполненных работ и закинули его в производственную комнату.
Все было хорошо полгода, пока данные в этой подсистеме не превысили допустимый предел.
И начали происходить очень странные вещи.
Перенос документа из модуля стал занимать 5-10 минут, появлялось много ошибок и т. д. Просмотр программного кода приводил в ужас (не спрашивайте, почему при приемке этого не сделали раньше.
).
Количество вложенных циклов было просто запредельным.
Единственный запрос в четвёртом цикле и доступ через 4 точки были мелочами, поиск по всем предыдущим документам для заполнения текущего документа, копирование и вставка одного и того же блока по 10 раз и многое другое.
Пример вложения: 
Дублирование полей в макете: 
Более того, чтобы заполнить эти поля, 14 раз копировать вставить.
Начало цикла: 
И пока переменная FF не достигнет 15: 
Ну и еще куча других не менее уникальных произведений искусства.
Внезапно я вспомнил, что для OneScript есть простая библиотека для расчета «цикломатичности» модуля (1) (сложности модуля или метода).
Нашел, посчитал.
Я получил значение 163 единицы при допустимом значении не более 10. И пришел к выводу, что приемочное тестирование программного кода должно быть обязательным и оно должно быть автоматическим и непрерывным.
Потом я узнал о Continuous Inspection — и как оказалось, еще в 2006 году IBM выпустила (2) публикации на эту тему.
Более подробная информация:
- Правило Microsoft избегать излишней сложности даже имеет специальный код CA1502. https://msdn.microsoft.com/ru-ru/library/ms182212.aspx
- Презентация концепции и инструмента анализа Java-проектов на базе ant- https://www.ibm.com/developerworks/library/j-ap08016/j-ap08016-pdf.pdf
Наверное, многие работающие в крупных компаниях сталкивались с проблемой развертывания копии рабочей базы данных на локальной машине разработчика.
Когда эта база данных весит 5-10 Гб - это не проблема, а когда она весит почти терабайт только в бэкапе, то это уже серьезно.
В итоге, чтобы развернуть свежую копию, требовалось 5-6 часов рабочего времени.
Когда мне это надоело, я начал использовать очень хороший инструмент. 1С-Развертывание и копированиеБД (Спасибо Антон!) Тогда я понял, что автоматизация — это круто.
Потом были другие задачи, например, регулярное обновление основной и распределенной базы из хранилища в ночное время, тестирование форм, тесты скриптов и т. д. Что-то из этого было реализовано, а что-то нет. Но все это было нужно только мне.
При поиске единомышленников в своем городе я чуть не потерпел неудачу.
Нет ни одного из них.
Хотя это ужасно странно, поскольку проблемы типичные.
На тот момент я уже знал, что хочу написать диссертацию на эту тему.
Но я не знал, что написать.
Поэтому мне пришлось подключиться к сообществу не просто как читатель, но как минимум писатель и задающий вопросы.
Основными местами, где можно было задать вопросы, были Проекты на Гитхабе: • 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. Алексей-Ластин (Привет Алексей!) и расскажите мне о моей идее диплома.
На что я с удивлением услышал одобрительный отзыв и даже приглашение пройти преддипломную стажировку в компании Silver Bullet. Это уже была победа.
За несколько часов мы придумали тему и содержание диплома.
Ставят задачи для практической работы.
Я получил от компании руководителя дипломного проекта - Артура Аюханова (Привет, Артур!) Будучи юным падаваном, я получил доступ к видеокурсу релиз-инженера и возможность бесконечно приставать к Никите Грызлову (Привет, Никита!) со своими вопросами, за что Я ему очень благодарен.
В конце концов:
Тезис — «Автоматизированное управление жизненным циклом информационных систем – системная и программная разработка решений на платформе 1С:Предприятие в условиях постоянного улучшения качества производственного процесса».
Цель выпускной квалификационной работы (ВКР) — выявление взаимосвязи между программными средствами и описание бизнес-процесса цепи DevOps в сфере 1С.
Теоретической основой проекта стал стандарт непрерывного улучшения качества обслуживания от ITIL 3.0, а в качестве практического объекта мы выбрали построение цикла непрерывной интеграции нового разработанного нами прикладного решения – личного кабинета покупателя.
Для этой цели был развернут сервер исходного кода GitLab и схема сборки Jenkins. Тесты проводились на выделенном сервере (Windows Slave).
Конфигурация скачана из хранилища 1С с помощью библиотеки.
Gitsync , редакция 3.0 (сейчас выложено в ветке разработки) уже с разработками Алексея Хорева (привет Леха!) с периодичностью 30 минут в ветке разработки.
Причиной выбора именно этой версии стала возможность подключения к репозиторию по протоколу tcp, который, к сожалению, не поддерживался типичным на тот момент GitSync 2.x. Если изменения были зафиксированы в GitLab, автоматически запускался цикл непрерывной интеграции.
Поскольку бюджет на все мероприятие был нулевой, а построить полноценную проверку качества программного кода без покупки модуля для SonarQube было невозможно, в качестве упрощенного решения была использована стандартная проверка синтаксиса 1С.
Хотя разовые загрузки все равно производились, а результаты были получены и проанализированы.
Также использовались дополнительные проверки на цикломатичность и наличие многоразового кода.
На этапе функционального тестирования использовались 2 фреймворка Vanessa-Behavior и XUnitFor1C в их объединенной версии под названием Vanessa Automation Driven Development (Vanessa ADD).
Первый использовался для запуска тестирования ожидаемого поведения, второй — для проверки открытия форм (дымовое тестирование).
Результатом прохождения цикла непрерывной интеграции стали автоматически формируемые отчеты.
По результатам тестирования релиз-инженер решил объединить ветки development и master и запустил (вручную) третью задачу — публикацию изменений в рабочей базе данных.
Производственная база данных не связана с хранилищем и полностью закрыта от ручных изменений.
Обновление осуществляется только через доставку и в автоматическом режиме.
Для описания бизнес-процесса схемы была создана диаграмма IDEF0, состоящая из 4 последовательных блоков, образующих прохождение схемы.
Ошибка, возникающая при прохождении любого из этапов, прерывает процесс сборки с уведомлением релиз-инженера и передает управление блоку 5 процесса сборки, где формируются отчеты в ALLURE, JUNIT и, конечно же, огурце.
json-форматы.
Описание модели IDEF0
Процесс «Загрузка исходников в GIT»
Входные данные: – Хранилище конфигурации Выход: - Источник Контроль: Инструкция по работе с программой, скрипт сборки.Механизм: 1С:Предприятие, Gitsync .
Обязательным условием существования контура является наличие исходных текстовых файлов.
Начиная с версии платформы 8.3.6 в 1С предусмотрена возможность выгрузки исходных кодов конфигурации в файлы.
Следует отметить, что данный процесс может иметь несколько вариантов исполнения, в зависимости от специфики разработки в ИТ-подразделении.
В текущей версии для упрощения процесса перехода сотрудников на новую методологию проведена интеграция с текущим процессом разработки через хранилище конфигураций и с помощью конфигуратора 1С.
На этапе процесса «Загрузка исходников в GIT» будет создана файловая, служебная информационная база 1С; он был подключен к хранилищу конфигурации под сервисной учетной записью; все изменения до текущего момента (или последнего коммита в репозитории) получены; исходный код загружен в каталог сборки; сделан коммит в систему хранения версий GIT; изменения передаются на сервер исходного кода GitLab
Процесс тестирования качества исходного кода
Входные данные: - Источник Выход: - Источник Контроль: Инструкция по работе с программой, скрипт сборки.Механизм: 1С:Предприятие, Деплойка , СонарКуб , Cyclo.os - (к сожалению нет ссылки) В начале этого процесса исходный код сохраняется в репозитории GitLab. С помощью скрипта управления (сборки) он поступает в каталог сборки.
С помощью платформы «1С:Предприятие» на основе этих исходных кодов разрабатывается сервисная информационная база.
Ошибки анализируются с помощью платформы.
Если в ходе анализа будут обнаружены ошибки программного кода, не позволяющие собрать конфигурацию, процесс будет прерван.
Цель данного шага – исключить затраты времени на анализ программного кода неработоспособной конфигурации.
После проверки на ошибки начинается расчет цикломатической сложности программного кода.
Увеличение этого коэффициента оказывает существенное влияние на отладку и анализ программного кода.
Максимально допустимое значение — 10. При его превышении возбуждается исключение и код возвращается на доработку.
Завершающим этапом анализа качества программного кода является проверка на соответствие стандартам разработки.
Для этих целей в предлагаемой схеме используется сервис SonarQube и разработанный для него модуль поддержки синтаксиса 1С от компании Silver Bullet. По результатам анализа система рассчитывает стоимость технического долга для каждого сотрудника, разместившего программный код.
Процесс функционального тестирования
Входные данные: - Источник Выход: - Источник Контроль: Инструкция по работе с программой, скрипт сборки.Механизм: 1С:Предприятие, Ванесса-Поведение, XunitFor1C .
В процессе разработки могут возникнуть ситуации, что новый функционал может нарушить работу существующих подсистем.
Это может проявляться как в формировании исключений, так и в выдаче неожиданных результатов.
Для этих целей тестируется ожидаемое поведение системы.
Для этой схемы применимы несколько методов разработки и тестирования: TDD (разработка через тестирование) и BDD (разработка через поведение).
На момент написания WRC платформа использовалась для проведения тестов с использованием методологии BDD. Ванесса-бахавиор , для TDD – XunitFor1C .
В настоящее время они объединены под одним продуктом Vanessa-ADD. Поддержка разработчиков старых продуктов прекращена.
Результаты тестирования выводятся в файлы отчетов Yandex Allure и Xunit.
Процесс сборки доставки
Входные данные: - Источник Выход: – Доставка конфигурации Контроль: Инструкция по работе с программой, скрипт сборки.Механизм: 1С:Предприятие, упаковщик .
Этот процесс завершает сборку доставки конфигурации для развертывания в целевой системе.
Подтвержденный исходный код находится в ветке разработки репозитория исходного кода GitLab. Для создания поставки необходимо, чтобы изменения из ветки развивать появился в теме владелец .
Данное действие может происходить как вручную, так и автоматически и регламентируется требованиями ИТ-подразделения, использующего схему CI/CD. После объединения ветвей запускается процесс сборки готовой поставки.
Для этого опять же в каталоге сборки на основе существующих источников создается служебная информационная база, а затем с помощью платформы 1С:Предприятие формируется и архивируется конфигурационное обеспечение.
Поставка конфигурации является конечным продуктом процесса сборки и доставляется заказчику по установленным каналам связи или устанавливается непосредственно в производственную информационную систему.
Процесс «Публикация результатов»
Входные данные: – Результат загрузки, файлы отчетов Выход: - Отчет Контроль: Инструкция по работе с программой, скрипт сборки.Механизм: Яндекс Аллюр , Кюнит .
При выполнении этапов процесса инструменты тестирования создают файлы отчетов в определенных форматах в качестве побочного продукта.
Целью этого процесса является группировка, преобразование и публикация для облегчения анализа данных.
Если на каком-либо этапе сборки генерируется исключение и при наличии нужной конфигурации система должна автоматически уведомить администратора схемы о наличии проблем.
Этот шаг происходит при постобработке процесса сборки и должен быть выполнен независимо от результатов предыдущих процессов.
Для обратной связи, помимо рассылки, мы использовали интеграцию с корпоративным Slack-менеджером, где все информационные сообщения о статусах сборки, появлении новых коммитов, формировании резервных копий, а также мониторинг функционирования сервисов, как связанных с DevOps. схема и 1С в целом.
Итогом моего проекта стала защита диссертации в конце мая этого года с результатом «отлично».
Кроме того, обновлена методическая информация по формированию контуров.
Общие выводы:
- Экономический эффект возможен только в долгосрочной перспективе.
На основе опыта замечено, что при запуске проекта по внедрению инженерных практик фиксируется снижение производительности разработки на 20-30% от текущего уровня.
Этот период носит временный характер, и, как правило, работоспособность возвращается к исходным значениям через три-четыре месяца эксплуатации.
Снижение производительности связано в первую очередь с тем, что разработчику приходится привыкать к новым требованиям разработки: написанию скриптов, тестов и генерации технической документации.
- Стабильность продуктивной информационной системы существенно повышена за счет тестирования программного кода.
Гарантированная работа критических подсистем обеспечивается сценарными тестами.
За счет этого снизились риски компании в критически важной области — оперативном взаимодействии с клиентами.
- Устранение динамических исправлений продуктивной информационной базы позволило более конструктивно планировать разработку и не допустить обхода программного кода цикла тестирования.
- Снижение трудозатрат на обслуживание информационной базы за счет автоматизации схемы сборки.
- Использование обратной связи через Slack позволило быстро отслеживать и исправлять проблемы жизненного цикла системы.
По отзывам команды, пользоваться мессенджером удобнее, чем почтой (хотя он тоже присутствует).
- Использование автоматизированной проверки программного кода (Continious Inspection) на соответствие стандартам разработки (SonarQube) вынуждает разработчиков самостоятельно повышать свою компетентность, а исправление выявленного технического долга непосредственно в ходе разработки программного модуля происходит гораздо быстрее, поскольку не нужно тратить время на восстановление контекста задачи.
- Включение функции автодокументирования и формирования видеоинструкций позволяет сократить количество обращений пользователей.
- В ходе проекта был сформирован бизнес-процесс, описывающий жизненный цикл разработки и тестирования прикладных решений 1С, что в свою очередь повлияло на формирование проекта.
внедрение инженерных практик .
Создан набор инструментов и документации, позволяющий быстро развернуть среду на любых проектах 1С.
Автоматизированные испытания сопротивлений .
В 90% случаев они связаны либо с внутренним сопротивлением компании изменению существующей модели развития, либо с отсутствием на тот момент достаточных знаний.
Что касается личных результатов, то они следующие:
- Насколько мне известно, на данный момент это первый диплом по теме «Внедрение инженерных практик в 1С».
Де-юре можно сказать, что инженерные практики, пусть и в их первоначальном виде, были приняты научным сообществом (даже если их было 5).
- Такой академический подход позволил нам ускорить выпуск «Методического пособия по выпуску инженера 1С».
Часть содержания диссертации плавно перекочевала в содержание книги.
(К сожалению, ссылка запрещена модератором за пределами раздела «Я пиарюсь».
Кому она нужна, тот легко найдет ее в поиске).
- Проработка модели процесса и проверка инструментов CICD в 1С позволили исправить мелкие недочеты при первом запуске и подключении к процессу, кстати уже мои улучшения приняты в основной ствол и будут включены в релиз 5.5.0 .
Буду очень признателен, если вы выскажете свое мнение о концепции DevOps в 1С.
Чего, по вашему мнению, не хватает отрасли? Теги: #DevOps #1c:enterprise #tdd #bdd #allure #ci/cd #idef0 #инженерные практики #внедрение #tusur #тестирование ИТ-систем #программирование #Идеальный код #Управление проектами #DevOps
-
3 Лучших Способа Поиска В Интернете
19 Oct, 24 -
Подведены Итоги Конкурса Webhitech
19 Oct, 24 -
Обзор Azure-Iaas № 2 (Февраль)
19 Oct, 24 -
Яндекс Снова Напугал Оптимизаторов
19 Oct, 24
