Ускоряем доставку изменений в классический 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, но так как используется ПО с закрытым исходным кодом, то в СКВ хранится только обвес (скрипты и конфиги) для нормальной работы конвейера. Хранение скриптов конвейера организовано в рамках одного репозитория, разделение контуров\типа конвейера идёт по бранчам. Структура папок для всех бранчей унифицирована.
CI/CD
Реализация всех процессов CI/CD сведена в выполнение билд-плана bamboo по причинам, выявленным в процессе разработки концепта, и наличия некоторых недостатков инструментария от Atlassian.
Все шаги унифицированы и представляют собой задание, разделенное на несколько простых задач. Разберем на примере шага «Build».
Так как система использует ПО с закрытым исходным кодом, то как такового классического билда нет. В рамках конвейера в этот термин вложен смысл получения сборки, загрузки сборки на целевой хост, обработка и кастомизация.
Да, отмечу, что при реализации всех шагов конвейера используется инструментарий powershell. В частности dsc и jea. А раз была проблема с использованием gMSA, то мы разработали концепцию с задействованием временных шар, срок жизни которых ограничен временем выполнения задания конвейера. Отсюда появляются задачи с характерным признаком «TFP» и «DelShare»:
- создание временной области на текущем агенте:
- удаление временной области на текущем агенте.
В итоге вроде бы простейшее задание разбивается на семь задач:
- получение кода скриптов на агент bamboo;
- создание временной области, для хранения dsc;
- парсер результата задачи создания временной области;
- выполнение основной смысловой задачи шага;
- парсер результата выполнение основной задачи;
- удаление временной области;
- парсер результата задачи удаление временной области.
В рамках билд-плана создали зависимость выполнения другого билд-плана для реализации оповещений в telegram.
Этот конвейер является базовым и разделен на бранч-планы поконтурно для минимизации количества отдельных идентичных планов. В дальнейших конвейерах мы доработали паттерны ошибок, именование тестов, доработали/переработали скрипты 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 были записаны скелеты автотестов по сценариям от бизнеса.
Сценарии были импортированы в js и доработаны для выполнения в рамках выбранного инструментария.
Полученные конечные скрипты для UI-автотестирования были загружены в СКВ и разбиты по контурам.
После успешного завершения конвейер релиза, в зависимости от контура, запускает конвейер UI-тестирования.
По завершении формируется артефакт с детальным логом выполнения.
Все тесты завершены успешно
Все или часть тестов завершены неудачно
Плюс в telegram-канал приходит информация о результате, с детальным логом результатов.
Все тесты завершены успешно
Все или часть тестов завершены неудачно
Затем проведена передача знаний команде аналитиков, которая на основе сформированных скелетов и завершенных скриптов автотестирования самостоятельно выполняет доработку\разработку.
Это дает возможность:
- исключить лишние шаги по постановке/проверке выполнения заданий между командами администрирования и аналитики;
- увеличить вовлечённость команд в общий процесс внедрения devops-практик;
- де-факто организовать прообраз продуктовой команды;
- ускорить реализацию заданий от бизнеса.
Если вы сталкивались с подобным и используете windows-монолит, поделитесь, пожалуйста, своим опытом доставки изменений.
