Приветствую, читатель Хабра.
Возможно, тема непрерывной доставки и интеграции микросервисов покажется немного избитой, ведь сегодня любой идальго путем несложных манипуляций с помощью обучающих видеороликов может установить Jenkins/TeamCity/GitLab (нужное подчеркнуть) на свой репозиторий и начать звонить самому испанский дон.
Все дело, на наш взгляд, заключается в этапах сборки, которые он определит для себя сам и какой смысл в них вложит. Не менее важным, чем сама сборка, является процесс автоматизации контроля качества.
В этой статье мы расскажем вам о том, что мы, команда разработчиков всех розничных направлений банка «Открытие», сделали для себя в этом вопросе.
В предыдущем статья мы говорили о том, как мы построили конвейер, который непрерывно доставляет релизы в производственную среду, не опасаясь его поломки.
Одним из факторов, позволяющих нам это сделать, является контроль обратной совместимости посредством управления версиями контракта, который мы описали в разделе статья .
Но этого далеко не достаточно.
Важнейшими этапами сборки мы считаем прохождение автоматизированных и ручных этапов контроля качества, которые позволяют нам быстро и без опасений вносить изменения.
Давайте рассмотрим конкретный пример.
В момент запуска сборки, например, когда разработчик сделал коммит в свою ветку, запускается процесс, который выполняется специально написанными скриптами и утилитами.
Этот процесс состоит из нескольких обязательных шагов.
Ошибка в любом из них приводит к полному краху всей сборки.
Ну и само собой разумеется, что шаги расположены в таком порядке, чтобы сузить воронку потенциальных проблем.
Если Ворота Качества предыдущего этапа не пройдены, то не придется тратить ресурсы на проверку следующего.
Основные ворота качества, встроенные в наш конвейер:
- Сборка сервиса: а.
Проверка правильности формата конфигурации; б.
Проверка стандартов проектирования кода; в.
Проверка необходимого покрытия Unit-тестами; д. Генерация и публикация контрактов (контроль обратной совместимости).
- Запуск бета-тестов.
- Обязательный код-ревью.
- Сканирование уязвимостей.
Существует универсальный формат конфигурации для всех сервисов.
Чтобы унифицировать этот процесс, мы даже написали свой инструмент. Из универсального стандартизированного YAML-файла нашего конфига он генерирует другие конфиги в различных форматах, понятных утилитам и скриптам, участвующим в дальнейших процессах.
Если у вас нет правильного конфига, дальше ничего смотреть не придется.
Проверка стандартов кодирования Наши разработчики — грамматические нацисты в своих языках.
Мы не будем вам рассказывать, что такое codestyle. Скажем так, с ростом числа участников проекта, имеющих доступ к кодовой базе, требования по унификации кода набирают все больший вес.
Проверка необходимого покрытия с помощью Unit-тестов Проверка исполнения тестами осуществляется в два этапа:
- Проверяется наличие Unit-тестов и их успешное выполнение.
- Использование утилиты покрывало проверяется, что услуга имеет необходимый процент покрытия.
Сейчас мы работаем над тем, чтобы охват был не менее 80%.
- Формирование и публикация договоров на наш сервис, при необходимости.
Механизм описан здесь , в разделе «Публикация договоров»;
- Создание докер-образов;
- Генерация с помощью специальной утилиты параметров в виде диаграммы Хелма.
Полный запуск всех бета-тестов любого коммита потребует всех наших ресурсов и будет слишком дорогим.
Поэтому мы явно определяем, какие бета-тесты необходимо запустить для конкретного сервиса, через Зависимости И Триггеры В TeamCity .
Такие зависимости задаются вручную во время разработки самих бета-тестов.
Для этой цели можно использовать вспомогательные инструменты автоматического картографирования.
и выглядят они примерно так: 
На этом этапе в дело вступает специальная внутренняя утилита.
SRV-Развертывание , заслуживающий отдельной статьи.
С помощью этой утилиты мы разворачиваем стенды для Бета-тестирования различной конфигурации в зависимости от разрабатываемой задачи.
На данный момент одна из его возможностей — пересылать статусы сборок о завершении бета-тестов в Битбакет к конкретному коммиту (pull-request).
Использование стандартного функционала Битбакет Мы можем создать правило для любого проекта для запросов на включение, которое не будет разрешать объединение до тех пор, пока не будут пройдены все бета-тесты.
Как вы можете видеть на изображении выше, кнопка «Объединить» неактивна до тех пор, пока не будут выполнены все требования PR, включая зеленые бета-тесты.
Обязательная проверка кода Очевидно, у нас есть запросы на проверку кода.
Использование стандартного функционала Битбакет За каждым сервисом закреплена группа владельцев.
Обязательно, чтобы PR просмотрело хотя бы определенное количество разработчиков, среди которых должен быть кто-то из группы владельцев кода.
Разработчикам помогают результаты различных популярных статических анализаторов, которые вы наверняка знаете (мы не будем их здесь афишировать).
Текущий этап протекает параллельно с предыдущим.
Строго говоря, это не автоматический, а ручной процесс.
Но конвейер настроен таким образом, что код не выйдет без успешного прохождения этого этапа.
Сканирование уязвимостей Последний обязательный этап — окончательное сканирование артефактов, которые доставляются в производственную среду специальными сканерами безопасности.
Если угроз и уязвимостей не выявлено, артефакт сборки считается готовым к доставке, которую выполняет специальная роль Release-manager. Это наш конвейер.
Этот процесс постоянно совершенствовался и менялся на протяжении нескольких лет и все еще находится в активной фазе разработки.
Многие скрипты и некоторые вспомогательные утилиты пришлось писать самостоятельно.
Мы надеемся, что наша история окажется кому-то полезной и поможет им создать и улучшить процессы доставки.
Чтобы тема была доступна максимально широкой аудитории, основные шаги намеренно описаны без глубокого погружения в технику.
Запросы технических подробностей оставляйте в комментариях.
Теги: #DevOps #Микросервисы #Тестирование ИТ-систем #ci/cd #Quality Gates
-
Обзор Зарплат Ит-Директоров
19 Oct, 24 -
«Ростелеком»: Укрепление Региональной Сети
19 Oct, 24 -
Таинственные Канцелярские Товары. Тест-2
19 Oct, 24 -
Медиаплееры Ющенко – Новый Китайский Бренд
19 Oct, 24
