Дипломная работа: Разработка сервиса для автоматизации процесса проверки кода

Анализ средств для автоматизации проверки кода.

Обзор средств для автоматизации процесса проверки кода.

Исследуя рынок современных средств для разработки, было выявлено, что средств, позволяющих автоматизировать процесс проверки кода сравнительно мало. Так, среди систем, являющихся законченными решениями и поддерживающих настройку для отдельных команд, существуют только 2 системы от крупных разработчиков: Atlassian Crucible и JetBrains Upsource.

Crucible -- это приложение для совместного обзора кода от компании Atlassian. Как и другие продукты Atlassian, Crucible -- это веб-приложение, ориентированное прежде всего на предприятие. Crucible особенно адаптирован к распределенным командам и облегчает асинхронный просмотр и комментирование кода. Crucible также интегрируется с популярными инструментами управления кодом, такими как Git и Subversion. Crucible не является проектом с открытым исходным кодом, но клиентам разрешено просматривать и изменять код для собственного использования. Поддерживается интеграция с Jira и BitBucket Server.

У Upsource есть много инструментов, автоматизирующих рутинные работы, которые следует использовать для минимизации нагрузки на авторов и рецензентов кода, есть способы облегчить создание обзоров кода в соответствии с рабочим процессом. Также, как и в Crucible, присутствует веб интерфейс, для совместного просмотра кода, формирования замечаний и коммуникации между разработчиками. Также, в состав решения входит расширенное управление пользователями, и поддерживается несколько модулей аутентификации.

В общих чертах, функционал обеих систем достаточно схож, и помимо управления процессом проверки кода, включает также средства, которые его упрощают. К примеру, пометки, комментарии, общение между разработчиками прямо в рамках запроса на включение изменений. Однако, учитывая то, что BitBucket Cloud использует технологии Crucible в части коллаборации разработчиков, средства, облегчающие визуальную часть проверки кода не включаются в список требований, предъявляемых к сервису автоматизации.

Сравнение решений для автоматизации процесса проверки кода.

Учитывая тот фактор, что самая дорогая с точки зрения разработки и доли в стоимости подписки на сервисы часть, то есть средства для совместной проверки кода и коммуникации в процессе разработки, уже предоставлены BitBucket Cloud, было решено разработать собственный сервис, который отвечает только за фоновые процессы, происходящие при проверке кода. Таким образом, собственное средство позволит не только сохранить финансы компании в долгосрочной перспективе, но и гибко настроить сервис, чтобы соответствовать нуждам команды разработки.

Таблица 1.1. Сравнение функционала решений

Как видно из таблицы 1.1., использование уже существующих средств не только не удовлетворяет потребности компании, но и невозможно технически, ввиду отсутствия интеграции с системой контроля версий BitBucket Cloud. Таким образом, единственным возможным решением, позволяющим оптимизировать процесс проверки кода на предприятии, является разработка собственного сервиса.

Помимо функциональных и технических недостатков Crucible и Upsource, также относительно высока стоимость подписки на данные решения. Так, стоимость первого года использования Upsource составляет 1300$ (подписка для 25 пользователей), и каждый год продления 650$. Такая же подписка на Crucible стоит 1650$ и 825$ соответственно. В свою очередь, трудоёмкость разработки сервиса автоматизации была оценена в 160 часов (20 рабочих дней) и на поддержку и дальнейшее развитие выделяется 6 часов в месяц, при средней ставке разработчика в компании в 430 рублей за рабочий час (около 7$ по курсу центрального банка России на 22.04.2018).

В таблице 1.2 представлена оценка стоимости использования каждого решения с расчётом на 3 года в долларах США.

Таблица 1.2. Сравнение стоимости решений

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

Проведён анализ текущего процесса проверки кода, который позволил выявить его «узкие» места:

Ручное сопоставление файлов с картой ответственности;

Отсутствие связи между BitBucket и Jira;

Ручное управление состоянием задач.

На основании выделенных слабых мест и выбранной методики оптимизации процесса, была построена TO-BE модель процесса проверки кода, которая подразумевает внедрение сервиса для автоматизации:

Назначения проверяющих;

Смена состояния задач.

Помимо функциональных требований, к решению для автоматизации процесса проверки кода предъявляются технические требования, связанные со спецификой используемого в компании ПО для разработки:

Поддержка BitBucket Cloud;

Размещение на собственном сервере;

Поддержка Jira Cloud.

Учитывая требования к средству автоматизации, выявлено, что существующие решения (Crucible и Upsource) не могут быть применены в компании технически, ввиду отсутствия поддержки системы контроля версий BitBucket Cloud. Кроме того, упомянутые средства не удовлетворяют функциональным характеристикам, в связи с этим, принято решение о разработке собственного сервиса.

2. Проектирование сервиса автоматизации

Поскольку на этапе анализа были сделаны выводы о необходимости разработки собственного сервиса для автоматизации процесса проверки кода, в данной главе проводится проектирование основных компонентов сервиса: уровня данных, уровня представления и бизнес-логики. В процессе создания архитектуры сервиса выявляются его варианты использования и последовательности взаимодействий в соответствии с построенной моделью процесса проверки кода TO-BE.

Проектирование базы данных сервиса автоматизации.

Исходя из требований, предъявленных к функционалу сервиса, необходимо хранить данные о следующих объектах:

Запрос на включение изменений (Pull request) - как представление решения задачи в виде исходного кода.

Проверяющий - для сопоставления со списком файлов и картой ответственности, назначения задач на проверку кода и смены состояний задачи.

Файлы - список всех отслеживаемых файлов в проекте.

Файлы проверяющего - представление карты ответственности, где файлу соответствует один или несколько проверяющих.

Ревью - представление проверки кода по каждому запросу на включение изменений (Pull request).

Файлы для ревью - список файлов для каждого проверяющего для отдельного ревью.

В качестве СУБД, используемой для хранения данных сервисом, используется Microsoft SQL Server 2016, поскольку на момент проектирования свободные экземпляры данной СУБД находятся в распоряжении компании. Также, Microsoft SQL Server 2016 используется компанией в качестве основной СУБД на проектах, в связи с чем, её применение в данном сервисе позволит обеспечить дальнейшую поддержку всеми членами команды разработки [1].

В таблице 2.1 представлено детальное описание таблиц базы данных, их полей и типов данных. По умолчанию все поля во всех таблицах обязательные.

токен программный пользовательский интерфейс

Таблица 2.1. Описание таблиц базы данных

В данной таблице следует учесть, что TrackedFiles.FilePath мог бы использоваться в качестве первичного ключа. Однако, Microsoft SQL Server не поддерживает создание ключей длиной более 900 символов. Также, стандартными средствами невозможно создать индекс по данному полю, так как тип данных - строка неограниченной длины (ограничение на длину пути в UNIX системах отсутствует), поэтому UNIQUE CONSTRAINT будет реализован дополнительно.

Уникальность значений полей, не являющихся ключами, обеспечивается посредством уникальных индексов (UNIQUE INDEX). Это позволяет избежать ошибок при заполнении таблиц данными, характерными для одной сущности. К примеру, не может быть нескольких проверяющих с одинаковым идентификатором пользователя в BitBucket или Jira.

На рисунке 2.1. представлена схема базы данных, построенная средствами Microsoft SQL Server Management Studio:

Рисунок 2.1. Схема базы данных

Проектирование интерфейса сервиса автоматизации

Пользовательский интерфейс должен обеспечивать следующие возможности:

Просмотр списка текущих ревью.

Фильтрация списка ревью:

По проверяющему.

По статусу проверки.

Отображение в ревью информации:

Автор.

Проверяющий.

Запрос на включение изменений.

Git ветка.

Статус проверки.

Для каждого ревью:

Просмотр списка проверяемых файлов.

Просмотр списка не отслеживаемых файлов.

Элементы управления для фильтрации списка расположены в верхней навигационной панели, и включают в себя два переключателя: Approved/Not approved, для отображения только одобренных и не одобренных соответственно. Также, в правой части навигационной панели находится выпадающий список, в котором представлен список проверяющих. Выбрав значение из списка можно также осуществить фильтрацию. Навигационная панель зафиксирована в верхней части и остаётся на месте при прокрутке. На рисунке 2.2 представлен макет интерфейса.

Рисунок 2.2. Макет веб-интерфейса

Данные по проверке представлены в виде карточек, где одна карточка соответствует одному ревью. Заголовком карточки является название задачи, также в ней представлена информация о Git ветке, авторе и проверяющем. В скрываемых разделах “Files to review” и “Not tracked files” находятся файлы для проверки и не отслеживаемые файлы соответственно. Все данные являются гиперссылками на соответствующие объекты в BitBucket.