Проектирование служб сервиса автоматизации
Варианты использования сервиса автоматизации
Исходя из построенной модели процесса проверки кода, выделяются три действующих лица, действия которых создают соответствующие события, обрабатываемые сервисом: Разработчик, Проверяющий и Менеджер проекта.
Разработчик отправляет задачу в проверку кода, создавая Pull request в BitBucket. Также, он может обновить её (изменить исходный код), то есть обновить Pull request. Проверяющий, в свою очередь, может одобрить или отклонить Pull request. После того, как Pull request был одобрен всеми проверяющими, менеджер проекта принимает Pull request. Диаграмма вариантов использования представлена в Приложении D.
Последовательности взаимодействия.
Рисунок 2.3. Диаграмма последовательности “Создать Pull request”
Разработчик создаёт Pull request в BitBucket, о чём Сервис получает уведомление посредством механизма Webhooks. После этого, Сервис запрашивает у BitBucket данные об изменении файлов (git diff), определяет измененные файлы, сверяет их с картой ответственности и передаёт BitBucket данные об проверяющих. После того, как проверяющие в BitBucket назначены, Сервис создаёт в Jira соответствующие задачи на проверку кода. После того, как задачи созданы, проверяющие получают уведомления (рис. 2.3).
Рисунок 2.4. Диаграмма последовательности “Обновить Pull request”
Разработчик обновляет Pull request в BitBucket, посредством дополнительных изменений (коммитов), о чём Сервис получает уведомление посредством механизма Webhooks. После этого, сервис запрашивает у BitBucket данные об изменении файлов (git diff) в сравнении с последней ревизией [10], определяет измененные файлы, сверяет их с картой ответственности. Если это необходимо, назначаются дополнительные проверяющие и им отправляются уведомления. После того, как проверяющие в BitBucket назначены, Сервис проверяет, необходима ли повторная проверка изменений каким-либо проверяющим. Если необходимо, то Сервис отправляет в BitBucket запрос на сброс одобрения. После того, как одобрение сброшено, Сервис обращается в Jira, чтобы сменить состояние задачи на проверку кода на «Сделать», после чего посылает проверяющему уведомление о том, что его одобрение было сброшено (рис. 2.4.).
Когда проверяющий одобряет или отклоняет Pull request, его задача на проверку кода меняет своё состояние на «Выполнено» или «Сделать» соответственно (рисунки 2.5. и 2.6.)
Рисунок 2.5. Диаграмма последовательности “Одобрить Pull request”
Рисунок 2.6. Диаграмма последовательности “Отклонить Pull request”
Когда Pull request одобрен всеми проверяющими, менеджер проекта принимает его. Сервис, в свою очередь, закрывает все задачи на проверку кода, изменяет состояние задачи на «Выполнено». После этого, сервис отправляет менеджеру проекта списки новых и удаленных файлов в проекте [2] (чтобы тот мог обновить карту ответственности) и перестаёт отслеживать данный Pull request (рисунок 2.7.).
Рисунок 2.7. Диаграмма последовательности “Принять Pull request”
Компоненты сервиса автоматизации.
Основные компоненты приложения, выделенные на основании анализа процесса в предыдущем пункте, являются клиентами для взаимодействия с внешними системами:
BitBucket клиент - для взаимодействия с REST API BitBucket;
Jira клиент - для взаимодействия с REST API Jira;
Slack клиент - для взаимодействия с Slack (отправка уведомлений проверяющим);
Mail клиент - отправка электронных писем менеджеру проекта.
Также, для выполнения внутренних операций, внутри приложения также присутствуют два микросервиса [7]:
Diff сервис - для разбора Git diff и определения списка измененных файлов и их состояний;
Reviewers сервис - для сопоставления списка измененных файлов с картой ответственности.
Кроме того, для обработки событий, создаваемых BitBucket, используется диспетчер запросов, который принимает информацию посредством механизма Webhooks.
Архитектура сервиса автоматизации.
Сервис подписан на BitBucket Webhooks, тем самым при возникновении какого-либо события в системе контроля версий, диспетчер получает HTTP POST запрос. После определения типа события, он передаёт его соответствующему обработчику события (Event handler) [4].
Обработчик, в свою очередь, взаимодействует с REST API BitBucket для получения данных об изменениях в репозитории. Далее, он передаёт ответ BitBucket сервису различия (Diff service) и получает список измененных файлов. Полученный результат подаётся на вход сервису проверяющих (Reviewers service), который сверяет список файлов с картой ответственности, полученной из базы данных MS SQL Server. Ответ Reviewers service является словарём, где ключ - проверяющий, а значение - список файлов, которые он должен проверить по данной задаче. Далее, список сопоставляется с текущими проверяющими задачи (при наличии) и Event handler, если это необходимо, отправляет данные о новых проверяющих и сбросе одобрения в BitBucket через BitBucket client.
Основываясь на том же списке проверяющих, Event handler создаёт задачи на проверку кода или меняет их состояние через Jira client. После того, как все операции успешно выполнены, Slack client отправляет необходимые уведомления.
Когда Pull request принимается менеджером проекта, приходит соответствующее событие. После выполнения действий по смену статуса задач в Jira, отправляется письмо менеджеру проекта через Mail client.
Все взаимодействия с внешними сервисами происходят по протоколу HTTPS в целях безопасности. Данные между модулями приложения и во внешние системы передаются в формате JSON.
Сервис реализован на языке JavaScript (ES6) с использованием серверного фреймворка NodeJS версии 8.9.4, в качестве HTTP сервера используется Express[10]. Архитектура приложения представлена на рисунке 2.9.
Рисунок 2.8. Диаграмма компонентов
Сервис и его компоненты спроектированы, чтобы удовлетворить технические и функциональные требования созданной модели процесса проверки кода. Рассмотрены три части сервиса: база данных, пользовательский интерфейс и архитектура сервиса непосредственно.
В процессе проектирования базы данных сделан выбор СУБД (MS SQL Server) и создана схема БД, отвечающая требованиям третьей нормальной формы и покрывающей все необходимые сценарии использования сервиса. Пользовательский интерфейс спроектирован в качестве макета главной страницы и содержит основные элементы управления и определяет их местоположение.
В качестве платформы для реализации служит фреймворк Node.js и язык программирования JavaScript. Архитектура сервиса построена по принципам SOLID и предоставляет возможности для расширения функциональности сервиса посредством добавления новых клиентов и поддержки дополнительных микросервисов.
3. Разработка сервиса автоматизации
В рамках разработки сервиса автоматизации процесса проверки кода реализуется база данных, спроектированная во второй главе, с использованием СУБД Microsoft SQL Server. Также, согласно макету интерфейса, создаётся веб-интерфейс приложения с использованием современных средств разработки (CSS3, HTML5) и веб-фреймворка Bulma. Для обеспечения функционала сервиса разрабатывается веб-сервис на основе серверного фреймворка Node.js и HTTP сервера Express, который взаимодействует с внешними системами. Кроме того, описывается процесс развертывания сервиса в инфраструктуре компании «6th Grain» и ввод сервиса автоматизации процесса проверки кода в опытную эксплуатацию.
Реализация базы данных сервиса автоматизации.
Сервис использует для хранения данных реляционную СУБД Microsoft SQL Server 2016. Таблицы базы данных были сгенерированы автоматически, после проектирования базы данных в конструкторе Microsoft SQL Server Management Studio 2017 (см. раздел 2.1).
Отдельно был реализован уникальный индекс для поля FilePath таблицы TrackedFiles. Как уже было упомянуто в разделе 2.2, создание индекса для полей, чей размер превышает 900 байт, не поддерживается. Для соблюдения целостности и третьей нормальной формы, индекс был реализован вручную, посредством добавления вычислимого поля и индекса для этого поля. Содержанием поля является SHA1 хэш значения из поля FilePath, таким образом достигается требуемый размер индекса. Скрипт создания индекса представлен на рисунке ниже.
Рисунок 3.1. Скрипт добавления индекса TrackedFiles.FilePath
В данном скрипте первая команда создаёт вычислимое поле Hashed_FilePath, а вторая создаёт уникальный индекс по данному полю в таблице TrackedFiles. Данная конструкция позволяет избежать дубликаты файлов в базе [6].
Разработка интерфейса сервиса автоматизации.
Вёрстка страниц списка проверок кода.
Веб-интерфейс сервиса предназначен для отображения списка ревью и его фильтрации. Поскольку это внутренняя разработка компании, к внешнему виду интерфейса не предъявляется высоких требований с точки зрения технологичности и различных дизайнерских решений.
Тем не менее, для удобства поддержки и сокращения трудозатрат на вёрстку и разметку, был выбран фреймворк Bulma. Bulma это современный CSS фреймворк, который представляет собой готовые стилистические компоненты, такие как: таблицы, кнопки, контейнеры, заголовки и так далее. Кроме того, Bulma оптимизирован для работы на различных разрешениях экрана и во всех современных браузерах.
Bulma подключается к странице как обычный CSS файл. В случае данного проекта, используется сжатая версия, загружаемая с CDN. Подключение Bulma осуществляется добавлением тега <link rel=”stylesheet> с указанием источника в тег <head> HTML файла страницы.
Помимо стилей, предоставляемых Bulma, были добавлены стили, позволяющие создавать сворачиваемые разделы без применения JavaScript, используя только HTML и CSS:
input[type=checkbox] {
position: absolute;
cursor: pointer;
width: 100%;
height: 35px;
z-index: 1;
opacity: 0;
}
input[type=checkbox]:checked+a+ol {
display: none;
}
С помощью данных стилей, достаточно добавить перед кнопкой, отвечающей за сворачивание раздела, HTML элемент <input type="checkbox" checked>.
Шаблонная разметка в сервисе автоматизации.
Для проецирования объектов ревью используется движок разметки Handlebars, который позволяет обозначить специальные участки в HTML документе, экранированные двойными фигурными скобками, которые будут заполнены, используя свойства объекта, переданные движку. К примеру, данная разметка:
<strong>#{{pullrequestId}}:</strong> {{pullrequestTitle}}
при передаче движку объекта
{ pullrequestId: “1”, pullrequestTitle: “Some Title” }
будет скомпилирована в
<strong>#1:</strong> Some Title
Также, Handlebars поддерживает вспомогательные функции, такие как условия и циклы, которые облегчают разметку циклов. Разметка, компилируемая движком, кэшируется, таким образом при последующих отрисовках страниц Handlebars знает, в какие блоки необходимо вставить данные, поэтому скорость загрузки страницы практически не увеличивается, в сравнении с обычным HTML документом, как и не возрастает нагрузка на сервер.
Элементы управления сервиса автоматизации.
Согласно макету, в интерфейсе присутствуют фиксированная навигационная панель (элемент <nav class=”navbar is-dark is-fixed-top”>), который содержит две кнопки для фильтрации списка по статусу одобрения и выпадающий список для фильтрации по проверяющим. Также, в правой части панели расположена кнопка для перехода на служебную страницу, содержащую историю работы сервиса (лог). Скриншот разработанного интерфейса представлен в Приложении E.
Список ревью оформлен в виде карточек (элемент <div class=”card”>), в заголовке которой указан номер и название Pull request (<h2 class=”title”>). Далее идут три строки, содержащий название Git ветки, имя автора и проверяющего соответственно. Под блоком информации находятся две кнопки, позволяющие скрыть или показать разделы, в которых перечислены файлы для проверки или не отслеживаемые файлы. Общий размер пользовательских файлов, загружаемых при открытии страницы, не превышает 40 килобайт, что обеспечивает быструю работу сайта.
Разработка служб сервиса автоматизации.
Node.js был выбран в качестве серверной платформы для службы автоматизации. Поскольку в компании имеется тенденция к росту, количество файлов, рецензентов и изменений в коде также будет увеличиваться. Таким образом, служба автоматизации должна быть готова обслуживать потребности команды и достигать цели. API должен быть разработан с четким пониманием базовой платформы.
Авторизация в REST API BitBucket и Jira.
Поскольку репозитории компании являются приватными, доступ к ним ограничен для любых агентов, запрашивающих информацию. Для интеграции со сторонними сервисами BitBucket REST API предоставляет интерфейсы для авторизации по протоколу OAuth2 (RFC 6749).
Данный протокол базируется на токенах доступа: зашифрованных объектах, содержащий в себе информацию об пользователе, агенте доступа и его полномочиях. Токены становятся недействительными через определенный промежуток времени (в случае с BitBucket - 1 час) и требуют обновления. Для получения первоначального токена, пользователь должен разрешить агенту использовать его профиль в рамках определенных полномочий. Для разрабатываемого сервиса необходимы права на чтение данных о пользователе, чтение и запись данных о репозитории и чтение и запись данных в pull request'ы.