Ускоряем доставку изменений в классический windows-монолит

Добрый день, коллеги! Позвольте представиться — меня зовут Павел Бацев, я администратор сервисов в ГК Спортмастер. В системном администрирование — 8 лет, второй год занимаюсь изучением и внедрением devops-практик.

Сегодня я предлагаю рассмотреть вам кейс, который, прежде всего, будет интересен администраторам и инженерам с парком windows-хостов и монолитными системами.

Под катом: некоторые особенности работы конвейера доставки, работающего с использованием windows-агентов bamboo; проблемы, возникающие при использовании dsc и jea-сессий powershell в домене с устаревшим уровнем леса, и варианты их решения; способ внедрения автоматического ui-тестирования без задействования профессиональных тестировщиков.

Итак, рассмотрим, исходные данные:

Имеем бизнес-критичную информационную систему, которая интегрирована с системой внутреннего документооборота, системой заявок в «Службу горячей линии», 1С.

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

  • Базы данных — MS SQL;
  • Веб-сервера — IIS;
  • Веб-сервиса — IIS;
  • Шедуллера регламентных заданий — Служба Windows;
  • Кеша — Redis, как служба Windows.

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

Исходя из рутинных задач были определены операции, которые требуют автоматизации и выполнение в рамках единого конвейера, а также учтён задел на последующие развитие:

  • Доставка сборок (сформированных артефактов) на целевые хосты веб-серверов;
  • Кастомизация сборок правкой файлов контента, параметров верстки, адресов сторонних плагинов и прочее.
  • Выполнение скриптов миграций утилитой (набором bat/ps-скриптов) от разработчика, находящейся в теле сборки;
  • Организация верной последовательности запуска системы;
  • Лёгкий откат при возникновении неполадок конвейера и ошибках кода.
  • Масштабируемость выполнения (при росте агентов bamboo, росте количества целевых контуров/хостов и т.п.) и унификация для различных контуров (dev, test, stage, prod);
  • Использование вычислительных мощностей агентов bamboo;
  • Вывод полного и читабельного лога выполнения всех шагов в ui bamboo;
  • Организация возможности выполнения конвейера и первичной диагностики возникающих проблем командой аналитики, а не техническим экспертом или т.п.
  • Реализация системы оповещения о результатах выполнения конвейера в удобный бизнесу инструмент: выбор пал на канал telegram (простейшая реализация chatops).

В нашей компании реализованы различные инструменты, позволяющие внедрять практики devops. На момент моего вступления в должность администратора сервисов наиболее развитым и способным покрыть поставленные задачи был стек от Atlassian, поэтому реализацию конвейера было решено выполнять, используя связку jira+bitbucket+bamboo.

Так как обслуживаемая система использует ОС Windows Server, а имеющийся на тот момент пул bamboo-агентов был на *nix, возникла идея проверки работы кроссплатформенного взаимодействия. Всё было хорошо, powershell core, установленный на *nix-агенты, работал исправно, но при тестировании сетевого взаимодействия выяснилась проблема — не отрабатывали второй тап аутентификации между windows-хостами.

Какие варианты решения были рассмотрены


Попробовали мы вот что.

  • установка библиотеки Kerberos и работа по аналогии с Ansible for Windows;
  • использование Python PowerShell Remoting Protocol Client library и зависимых с ним пакетов;
  • использование windows агентов bamboo.


После обсуждения с коллегами предложенных вариантов мы решились на внедрение некоторого количества агентов bamboo на windows, что позволило унифицировать платформу агента и целевой системы, отказаться от длительной исследовательской деятельности, а также обезопасило от возможных проявлений неявных проблем при кроссплатформенной работе инструментов ci/cd.

Не обошлось без сложностей и при реализации конвейера доставки изменений на базе windows агентов bamboo, куда же без проблем. Собственно, вот они:

  • текущий лес ad не поддерживает групповые управляемые учетные записи служб (gMSA);
  • при использовании встроенного плагина bamboo по обработке скриптов «Script» и хранении скриптов в СКВ, при получении ошибок powershell встроенные интерпретатор bamboo не воспринимал их и завершал задачи\задания\шаги\планы, как удачные;
  • сторонний плагин «Parse Log Task» для простейшего парсинга ошибок по заданным паттернам было невозможно добавить в задачи Deployment Projects.


Реализованный конвейер


Остановимся на общей концепции, инструментах и некоторых особенностях.

Система контроля версий


В качестве СКВ используется bitbucket, но так как используется ПО с закрытым исходным кодом, то в СКВ хранится только обвес (скрипты и конфиги) для нормальной работы конвейера. Хранение скриптов конвейера организовано в рамках одного репозитория, разделение контуров\типа конвейера идёт по бранчам. Структура папок для всех бранчей унифицирована.

5ki5mbt_8fyb36jmcc6nhsvqt50.png

CI/CD


Реализация всех процессов CI/CD сведена в выполнение билд-плана bamboo по причинам, выявленным в процессе разработки концепта, и наличия некоторых недостатков инструментария от Atlassian.

ci3f4gnf9mdudevfczr1vdzfg-4.png

Все шаги унифицированы и представляют собой задание, разделенное на несколько простых задач. Разберем на примере шага «Build».

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

Да, отмечу, что при реализации всех шагов конвейера используется инструментарий powershell. В частности dsc и jea. А раз была проблема с использованием gMSA, то мы разработали концепцию с задействованием временных шар, срок жизни которых ограничен временем выполнения задания конвейера. Отсюда появляются задачи с характерным признаком «TFP» и «DelShare»:

  • создание временной области на текущем агенте:
  • удаление временной области на текущем агенте.

В итоге вроде бы простейшее задание разбивается на семь задач:

  1. получение кода скриптов на агент bamboo;
  2. создание временной области, для хранения dsc;
  3. парсер результата задачи создания временной области;
  4. выполнение основной смысловой задачи шага;
  5. парсер результата выполнение основной задачи;
  6. удаление временной области;
  7. парсер результата задачи удаление временной области.

В рамках билд-плана создали зависимость выполнения другого билд-плана для реализации оповещений в telegram.

z8w4k5cmlybersfb1fgi0ubcq78.png

pzsmjdjr5kvlyrmyf539vwhkkes.png

Этот конвейер является базовым и разделен на бранч-планы поконтурно для минимизации количества отдельных идентичных планов. В дальнейших конвейерах мы доработали паттерны ошибок, именование тестов, доработали/переработали скрипты ps и сделали прочие полезные изменения.

Одним из результатов стал конвейер обновления версии платформы для продуктивного контура.

Также реализовали конвейеры, покрывающие другие типовые задачи: обновление сущностей БД, используя утилиту собственной разработки подрядчика или утилиту от redgate; автоматическое ui тестирование системы; обновление\добавление кастомного контента js\css; перезапуск системы непродуктивного контура; оповещения в telegram.

Написали инструкции для группы аналитиков и провели обучающие встречи по использованию инструментов CI/CD.

А ещё разработали концепт и протестировали выполнение конвейеров по переходам бизнес-процесса в jira\отложенному заданию (не востребовано, т.к. заказчик пожелал использовать ui bamboo).

Ближайшие планы


  • перенос хранения сборок с сетевой шары в Artifactory;
  • после обновления леса ad внедрение gMSA;
  • написание своего плагина bamboo для оповещений в telegram;
  • написание своего плагина bamboo для парсинга результатов выполнения ps-скриптов из файла.

Автотестирование без профессиональных тестировщиков


Теперь же про успешно реализованный кейс по разработке и внедрению UI-автотестов с минимальными трудозатратами и квалификацией по инструментарию.

От бизнеса были получены сценарии с описанием бизнес-процессов, критичных к отслеживанию.

В качестве инструментария мы взяли:

  • selenium ide — как доступная и удобная платформа для формирования скелета автотеста с возможностью импорта в различные языки программирования;
  • selenium webdriver+node js+mocha — как связка кроссплатформенная инструментов, подходящая к текущей конфигурации и набору установленных плагинов в bamboo;
  • windows-агенты bamboo — как раннеры тестов;
  • allure — как визуализатор результатов для бизнеса, удобный и простой в понимании;
  • канал telegram — как простейшая реализация chatops.

В selenium ide были записаны скелеты автотестов по сценариям от бизнеса.

elgx11581oj9ut0-ouybyt3pfyy.png

Сценарии были импортированы в js и доработаны для выполнения в рамках выбранного инструментария.

Полученные конечные скрипты для UI-автотестирования были загружены в СКВ и разбиты по контурам.

p0ccaoukap7ag_8mu1_ujjyohwq.png

После успешного завершения конвейер релиза, в зависимости от контура, запускает конвейер UI-тестирования.

По завершении формируется артефакт с детальным логом выполнения.

ayobjnpzk-k8z4dm6xf1xtvisgy.png
Все тесты завершены успешно

dkodbihcjeiklroqehy-feiofvs.png
Все или часть тестов завершены неудачно

Плюс в telegram-канал приходит информация о результате, с детальным логом результатов.

fmbw9n6unzge_smemiyp7mge9m4.png
Все тесты завершены успешно

yf7bgg1ohc6wlsgsr4rgogr3oi0.png
Все или часть тестов завершены неудачно

Затем проведена передача знаний команде аналитиков, которая на основе сформированных скелетов и завершенных скриптов автотестирования самостоятельно выполняет доработку\разработку.

Это дает возможность:

  • исключить лишние шаги по постановке/проверке выполнения заданий между командами администрирования и аналитики;
  • увеличить вовлечённость команд в общий процесс внедрения devops-практик;
  • де-факто организовать прообраз продуктовой команды;
  • ускорить реализацию заданий от бизнеса.

Если вы сталкивались с подобным и используете windows-монолит, поделитесь, пожалуйста, своим опытом доставки изменений.

© Habrahabr.ru