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

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

В больших командах разработки, где требуется обеспечивать чистоту и понятность кода и поддерживать масштабируемую архитектуру приложений [8], широко распространена практика проверки кода (Code Review). Проверка кода происходит после того, как какой-либо функционал разработан и протестирован, и позволяет на ранних стадиях выявить скрытые проблемы в реализации, уменьшить вероятность архитектурных ошибок и возможных проблем с производительностью при масштабировании системы. Кроме того, проверка кода помогает распространять опыт и знания среди членов команды, повышая общий уровень профессионализма в команде [2].

Однако, несмотря на пользу проверки кода, при неумелом подходе и неправильном выборе регламента она может стать узким местом в процессе разработки программного обеспечения. В компании «6th Grain», которая занимается разработкой веб-приложений, при анализе времени, потраченного разработчиками компании, было выявлено, что в среднем проверка кода занимает около 30% от общего количества. Таким образом, вместе с тестированием, проверка занимает столько же времени, сколько и разработка (около 50%). Данные получены в рамках внутреннего исследования в компании, основываясь на эмпирических данных и аналитике в системе управления задачами Jira, которая оценивает время нахождения той или иной задачи в каждом из состояний.

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

Объект исследования -- разработка ПО в компании «6th Grain».

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

Цель работы -- разработать сервис для оптимизации процесса проверки кода в компании «6th Grain».

Для достижения целей будет решен ряд следующих задач:

1. Проанализировать текущий процесс проверки кода.

2. Построить TO-BE модель процесса проверки кода.

3. Спроектировать сервис для автоматизации процесса проверки кода.

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

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

Во время исследования был проведён сбор и анализ эмпирических данных, рассмотрена профессиональная литература, посвящённая лучшим практикам в управлении процессом разработки. Также, с помощью нотации BPMN описаны AS-IS и TO-BE модели процесса проверки кода. В процессе проектирования приложения диаграммы последовательностей и классов построены используя средства UML.

Работа состоит из трёх глав, описывающих: анализ модели процесса проверки и сравнение решений для автоматизации этого процесса; проектирование и разработку сервиса для автоматизации.

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

Для разработки сервиса автоматизации процесса проверки кода требуется, в первую очередь, проанализировать процесс разработки ПО в компании «6th Grain». В рамках данной главы анализируется процесс проверки кода и исследуется ИТ-инфраструктура предприятия. На основании полученных данных строится модель TO-BE процесса проверки кода и формируются требования к средству автоматизации, реализующему эту модель. Согласно требованиям, проводится сравнение существующих решений и собственного сервиса.

Анализ ИТ-инфраструктуры предприятия.

Общие сведения о предприятии.

Фирма «6th Grain» является международной компанией, предоставляющей услуги по оцифровке сельскохозяйственных полей. Предприятие специализируется на преобразовании данных, предоставленных фермером, в информацию, которая может быть использована для увеличения успеха и использования в предоставлении кредитов, высокопродуктивных семян, удобрений, фунгицидов и других услуг по защите растений. Головной офис предприятия расположен в Сингапуре, а подразделения расположены по миру: отдел исследований в США, отдел анализа данных в Индии и отдел разработки в России. Организационная структура предприятия отражена на рисунке 1.1.

Рисунок 1.1. Организационная структура предприятия

В рамках данной работы рассматриваются процессы, происходящие в отделе разработки, который состоит из менеджера проекта, ведущего разработчика, трёх старших разработчиков, шести рядовых разработчиков и трёх тестировщиков. Программисты также имеют различные области экспертизы, они пишут на различных языках и работают с различными платформами. Структура отдела разработки представлена на рисунке 1.2. Данная иерархия является условной, поскольку в команде применяются гибкие методологии разработки и динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп (Agile), где сотрудники в относительно равной степени участвуют в принятии решений [1].

Рисунок 1.2. Организационная структура отдела разработки

Описание используемых средств разработки ПО.

В отделе разработки используется стандартный для ИТ подразделения набор ПО: система управления задачами, система контроля версий и корпоративный мессенджер. Задачи и их состояние управляются с помощью Atlassian Jira Cloud (далее - Jira), который частично интегрирован с хранилищем исходного кода Atlassian BitBucket Cloud (далее - BitBucket) посредством внутренней шины сообщений Atlassian Connect. Интеграция между Jira и BitBucket информационно-справочная: задачи связаны посредством идентификационного номера с соответствующими ветками и запросами на включения изменений в BitBucket, обеспечивающая навигацию между двумя системами.

Atlassian также предоставляет интерфейсы для подключения сторонних приложений. В компании в качестве корпоративного мессенджера используется Slack. Slack - это облачный набор собственных инструментов и сервисов для совместной работы и коммуникации, обеспечивающий создание ботов и каналов. Так, Atlassian предоставляет доступ к jirabot и bitbucketbot, которые оповещают с помощью Slack об изменении статуса задач из Jira и сообщения о слияниях веток в основную (merge) из BitBucket.

Кроме использования готовых интеграций, BitBucket и Jira предоставляют точки подключения (API) для разработки собственных сервисов для взаимодействия с системами и создания собственных способов интеграции. Используемые технические средства представлены на рисунке ниже.

Рисунок 1.3. Технологическая среда предприятия

Анализ AS-IS модели процесса проверки кода.

Описание текущего процесса проверки кода.

С момента основания компании в процессе разработки применяется практика проверки кода (Code Review). Проверка кода происходит после того, как функционал задачи разработан и протестирован и осуществляется для выявления скрытых недостатков реализации и возможных архитектурных проблем, которые будут тормозить развитие приложения в будущем [2]. Полный сценарий разработки задачи представлен в Приложении А.

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

Когда задача поступает на проверку кода, разработчик сверяет список изменённых файлов с картой ответственности и назначает проверяющих в BitBucket. Трудоемкость данного этапа пропорциональна количеству файлов, и может занимать от минуты до часа [3]. Далее, разработчик уведомляет о готовности задачи к проверке менеджера проекта. Тот, в свою очередь, назначает в Jira задачи на проверку кода для необходимых проверяющих. После того, как задача поступает проверяющему, тот в свою очередь также должен сопоставить список изменённых файлов с собственной зоной ответственности и перевести задачу на проверку в статус «В работе». Далее, если в результате проверки появляются замечания, исходная задача переводится в статус «Сделать», а задача на проверку - в отложенные. Если замечаний нет, то задача на проверку переводится в состояние «Сделано». Когда все ответственные закончили проверку и одобрили задачу, менеджер проекта принимает задачу и переводит её в «Сделано».

Слабые места в текущем процессе проверки кода.

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

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

Поскольку процесс разработки итеративный и развивается нелинейно, указанная модель процесса AS-IS не может учитывать все факторы [1]. Например, при исправлении замечаний могут быть изменены ранее не тронутые блоки, что требует повторной сверки с картой ответственности, назначением проверяющих и так далее. Более того, код может быть перебазирован (rebase), подвергнут «откату» (revert) или «слит» с основной веткой (merge) [9], в результате чего наличие некоторых проверяющих более не требуется. Это также требует повторного распределения в соответствии с картой ответственности, а следовательно - траты времени. В виду того, что разработка продукта компании ведётся в динамичном темпе, данные повторные рутинные действия складываются в большие затраты рабочего времени, что влечет за собой удорожание продукта и потерю прибыли [1].

Модель TO-BE процесса проверки кода.

Внедрив подход к проверке кода с использованием вспомогательных средств, разработчики смогут просматривать код за одну пятую времени, необходимого прежде [2]. Данный способ, представленный Коэном [3], определил концепцию к оптимизации процесса в данной работе. Этот подход базируется на том, что специальный инструмент должен автоматически проводить сравнение файлов, назначение проверяющих и управлять рабочим процессом.

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

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

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

Таким образом, процесс проверки кода, с точки зрения участников, будет сведён к непосредственно «значимым» действиям, минуя этапы, являющийся рутинной работой и формальностями.

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

Диаграмма процесса, с учётом внедрения сервиса автоматизации, представлена в Приложении C. В результате сервис берёт на себя все рутинные и занимающие большое количество времени операции, назначая проверяющих и синхронизируя действия в BitBucket с задачами в Jira.

Формирование требований к средству автоматизации.

Согласно требованиям, предъявляемым выбранным подходом к оптимизации проверки кода, средство автоматизации должно обеспечивать:

Распределение проверяющих в зависимости от карты ответственности.

Назначение задач на проверку кода.

Отображение списка файлов по каждой задаче для каждого проверяющего.

Синхронизация состояния задач между BitBucket и Jira.

Оповещения в Slack.

Обработка дополнительных изменений в коде.

Назначение дополнительных проверяющих.

Сброс состояния проверки кода, если в результате изменений были затронуты соответствующие блоки.

Отображение не отслеживаемых файлов (новые файлы или те, для которых не назначен конкретный проверяющий).

Оповещение проверяющих о новых файлах, включённых в проект в результате выполнения задачи.

Кроме перечисленных функциональных требований, средство должно также отвечать следующим техническим параметрам:

Использование BitBucket Cloud в качестве системы контроля версий.

Использование Jira Cloud в качестве системы управления задачами.

Работа под управлением ОС Windows Server либо Ubuntu 14.04 или аналогичным дистрибутивом Linux.

Возможность размещения на сервере компании.

Наличие Веб-интерфейса.

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

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

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

Исследуя рынок современных средств для разработки, было выявлено, что средств, позволяющих автоматизировать процесс проверки кода сравнительно мало. Так, среди систем, являющихся законченными решениями и поддерживающих настройку для отдельных команд, существуют только 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. Сравнение функционала решений

Критерий	Atlassian Crucible	JetBrains Upstorm	Собственный сервис
Распределение проверяющих в зависимости от карты ответственности	+	+	+
Назначение задач на проверку кода	+	+	+
Отображение списка файлов по каждой задаче для каждого проверяющего	-	+	+
Синхронизация состояния задач между BitBucket и Jira	+	- (BitBucket не поддерживается)	+
Оповещения в Slack	+ (через JiraBot)	+ (через JiraBot)	+
Назначение дополнительных проверяющих	+	+	+
Отображение не отслеживаемых файлов (новые файлы или те, для которых не назначен конкретный проверяющий)	-	-	+
Оповещение проверяющих о новых файлах, включённых в проект в результате выполнения задачи	-	+	+
Использование BitBucket Cloud в качестве системы контроля версий	- (только BitBucket Server)	- (только GitHub)	+
Использование Jira Cloud в качестве системы управления задачами	+	+	+
Работа под управлением ОС Windows Server либо Ubuntu 14.04 или аналогичным дистрибутивом Linux	+	+	+
Возможность размещения на сервере компании	+	+	+
Веб-интерфейс	+	+	+

Как видно из таблицы 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. Сравнение стоимости решений

Решение	Стоимость разработки	Стоимость первого года	Стоимость следующих двух лет	Итого за три года
Собственный сервис	1120	504	1008	2632
JetBrains Upsource	0	1300	1300	2600
Atlassian Crucible	0	1650	1650	3300

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

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

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

Отсутствие связи между 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. Описание таблиц базы данных

Таблица	Поле	Тип данных	Ключ	Внешний ключ	Уникальный	Комментарий
PullRequests	UUID	Идентификатор	+	-	+
	Title	Строка	-	-	-	Название задачи
	Branch	Строка	-	-	-	Название ветки Git
	Author	Строка	-	-	-	Имя автора
Reviewers	UUID	Идентификатор	+	-	+
	KnownName	Строка	-	-	-	Имя проверяющего для отображения
	BitBucketUUID	Идентификатор	-	-	+	Идентификатор пользователя в BitBucket
	JiraUUID	Идентификатор	-	-	+	Идентификатор пользователя в Jira
TrackedFiles	UUID	Идентификатор	+	-	+
	FilePath	Строка	-	-	+*	Путь к файлу
ReviewersFiles	Reviewer	Идентификатор	+	-	+	Составной ключ, связь многие-ко-многим между Reviewers и TrackedFiles
	File	Идентификатор	+	-
Reviews	UUID	Идентификатор	+	-	+
	PullRequest	Идентификатор	-	+	-	Связь с таблицей PullRequest
	Approved	Логический	-	-	-	Состояние проверки: одобрено или нет
FilesToReview	Review	Идентификатор	+	+	+	Составной ключ, связь многие-ко-многим между Reviews и ReviewersFiles
	Reviewer	Идентификатор	+	+
	File	Идентификатор	+

В данной таблице следует учесть, что 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.

Проектирование служб сервиса автоматизации

Варианты использования сервиса автоматизации

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

Разработчик отправляет задачу в проверку кода, создавая 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'ы.

После того, как пользователь авторизовал сервис, BitBucket отправляет код авторизации на указанный при регистрации агента адрес (URL) в виде HTTP GET запроса. Обработка запроса выглядит следующим образом:

app.get('/BitBucket/auth', (req, res) => {

const code = req.query.code;

if (code) {

BitBucketClient.authorizeUser(code);

} else {

res.sendStatus(400);

return;

}

res.sendStatus(200);

});

Полученный код в последствии используется для получения токена доступа и токена обновления. Данная процедура необходима для выполнения запросов к BitBucket API, связанных с операциями с приватной информацией, а также операциями, выполняемыми от лица пользователей (к примеру, сброс состояния одобрения возможен только самим проверяющим). Для авторизации запроса сервиса, необходимо добавить данные токена в HTTP заголовок Authorization.

Jira, в отличие от BitBucket, использует протокол OAuth (RFC 5849), которая не требует постоянного обновления токенов. Кроме того, операции, выполняемые сервисом в Jira, не требуют персональных токенов, поэтому был создан сервисный аккаунт, от лица которого выполняются все операции с задачами в Jira. В остальном, механизм авторизации соответствует описанному для OAuth2 в BitBucket.

Взаимодействие с BitBucket и Jira.

Сервис получает уведомления о новых событиях в системе посредством механизма Webhooks. Панель управления BitBucket позволяет настроить отправку уведомлений по различным категориям событий и на различные URL. Тип события передаётся в заголовке “X-Event-Key” HTTP POST запроса, генерируемого BitBucket. Помимо типа события, передаётся объект данных, над которым было произведено действие. Так, в теле запроса события “pullrequest:created” содержится только что созданный запрос на включение изменений. Пример тела запроса представлен в Приложении F.

Обмен информацией между сервисом и внешними системами происходит по протоколу HTTPS. Сервис использует GET запросы для получения и POST отправки данных. Операции выполняются асинхронно, что позволяет обеспечить быстродействие системы, поскольку одновременно могут обрабатываться несколько событий [10].

Для поддержки асинхронности кода используется механизм Promise и ключевые слова async / await. Async указывает на то, что данная функция асинхронная, и поток может продолжать выполнение без ожидания завершения функции. Await позволяет дождаться выполнения метода в требуемом участке кода (в своего рода критической точке). Работа данного механизма схожа с аналогичным в языке программирования C# и доступна с версии JavaScript ES6 и NodeJS 7.8. Цель функций async/await упростить использование асинхронных функций и обратного вызова функций, сохранив при этом линейную структуру кода без потерь в производительности.

Обработка разницы файлов с помощью git-diff.

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

Git-diff является стандартной операцией для всех Git систем контроля версий [8]. Помимо полной разницы, команда поддерживает опции, позволяющие получить только имена файлов или разницу конкретных файлов. Однако, API BitBucket не поддерживает опциональные параметры, возвращая только полную разницу. Ответ сервера представляет собой простой текст следующего вида:

diff --git a/about.html b/about.html

index d09ab79..0c20c33 100644

--- a/about.html

+++ b/about.html

@@ -19,7 +19,7 @@

</div>

<div id="headerContainer">

- <h1>About&lt/h1>

+ <h1>About This Project&lt/h1>

</div>

<div id="contentContainer">

Для работы сервиса требуется определить, какие файлы были изменены. В данном примере, первая строка и вторая строки содержат информацию о том, какие ревизии сравниваются (формально, разница между ветками, это разница их последних ревизий). Следующие две строки содержат данные о соответствующих файлах, измененных в конечной ревизии. В данном случае, префиксы a и b указывают, из какой ревизии взят файл (a - начальная, b - конечная). Далее следует детальное различие между файлами, а после его окончания идёт следующий блок, содержащий ту же информацию для другого файла (при наличии).

Также, файлы могут добавляться в проект или удаляться из него. В случае добавления, во третьей строке будет содержаться “a/null” (файла не существовало), в случае удаления - наоборот, в строке конечной ревизии будет “b/null”.

При обработке git-diff сервис разбивает ответ сервера на блоки, соответствующие отдельным файлам, а затем, при помощи регулярного выражения получает имена файлов и их состояние (измененный, новый, удаленный). Полученная информация передаётся обработчику события и затем используется Reviewers service для назначения проверяющих и формировании отчёта менеджеру проекта.

Также, для удобства обновления карты ответственности, сервис определяет перемещения и переименования файлов, используя алгоритм схожести строк (библиотека string-similarity). После того, как изменения в ветке были совершены и задача принята, сервис пытается найти файлы, похожие содержанием и наименованием на удалённые, среди добавленных. При определении степени схожести используется стандартный для Git-diff коэффициент 0.5 (50%) [8].

Развёртывание сервиса автоматизации.

Для работы сервиса необходима его публикация в сети интернет. На данном этапе работы сервиса не требуется высокая производительная мощность сервера, поэтому компания выделила место на виртуальной машине, работающей рамках её домена. Данное решение, помимо экономии средств, продиктовано ещё и требованиями безопасности: для шифрованного взаимодействия с BitBucket и Jira используется протокол HTTPS, требующий наличия SSL сертификата. Ввиду того, что на используемом сервере и соответствующем ему домене уже имеется SSL сертификат, процедура настройки и регистрации не требуется.

Сервер, на котором работает сервис, является виртуальной машиной и базируется в облачном хостинге Amazon EC2. Операционной системой является Microsoft Windows Server 2010, в качестве веб сервера (обратного прокси) используется Microsoft IIS 7.5. Поскольку для хранения данных предусмотрен уже существующий сервер СУБД, установка и настройка экземпляра Microsoft SQL Server не требуется.

Для работы сервиса, разработанного на Node.js требуется наличие среды исполнения, которая находится на официальном сайте фреймворка. Для поддержки последних нововведений среды и стабильной работы сервис использует последнюю LTS сборку Node.js версии 8.11.1 (по состоянию на 02.05.2018).

Запуск сервиса происходит посредством выполнения команды “node app.js” в командной строке Windows из директории с исходным кодом приложения. Однако, при этом возникают две проблемы: необходимость в постоянной открытой командной строке и отсутствие автоматического перезапуска сервиса при критических ошибках или перезагрузке сервиса[5]. Для того, чтобы решить данные проблемы, используется сервисный менеджер NSSM с открытым исходным кодом, который позволяет упаковывать исполняемые команды в службы Windows. Используя встроенные в Windows механизмы служб, сервис автоматически запускается при старте системы и возобновляет работу, в случае экстренного завершения работы. Также, посредством системы событий Windows ведётся архив работы сервиса, что позволяет восстановить логику работы в случае ошибок или неправильного выполнения алгоритма [7].

Поскольку служба работает «всегда», если возникает некоторая ошибка, невозможно остановить экземпляр и отладить некорректные процессы, так как данные и события являются уникальными для конкретной операции [4]. Кроме того, микросервис выполняет несколько операций для каждого события, поэтому также могут возникать каскадные ошибки [7]. Для того, чтобы быть уверенным, что все работает так, как ожидается [6], потому что вы даже при работе с небольшим проектом могут возникать непредвиденные ошибки[8], служба регистрирует свою работу, события, ошибки и запросы в журналах (логах). Эти журналы структурированы и содержат всю необходимую информацию для воссоздания состояния службы из моментального снимка.

В процессе разработки сервиса, была создана база данных с использованием СУБД Microsoft SQL Server, реализованная в соответствии с схемой базы данных, построенной в разделе 2.2. Также, дополнительно реализован уникальный индекс для названий файлов в таблице с текущими файлами проекта.

Пользовательский интерфейс, разработанный для приложения, является веб страницей и разработан с использованием CSS фреймворка Bulma и движка разметки Handlebars. С помощью данных средств интерфейс открыт для дальнейшего расширения и стилизации, при этом используя шаблонные средства, позволяющие сохранить простоту в поддержке решения.

При разработке сервиса была произведена интеграция приложения с BitBucket и Jira с применением авторизации на основе токенов доступа (OAuth2 и OAuth соответственно). Также, для обработки событий BitBucket, были созданы конечные точки и настроена подписка на механизм Webhooks. Сервис, реагируя на события, обменивается данными с REST API обеих систем, используя специально разработанные клиенты. Помимо метаданных, сервис также получает и обрабатывает Git-diff, на основе которого сопоставляется список файлов и карта ответственности.

Сервис был развёрнут на виртуальной машине в облаке Amazon EC2 под управлением ОС Windows Server 2010 в качестве службы Windows и опубликован в сети интернет на домене компании по адресу https://bbapprovals.6grain.com:4431.

Заключение

В ходе написания данной выпускной квалификационной работы был проанализирован процесс разработки программного обеспечения в компании «6th Grain», в частности, процесс проверки кода, который является «узким» местом и значительно ухудшает общую производительность команды разработки. Были выделены проблемные зоны процесса, построена TO-BE модель процесса проверки кода, опирающаяся на современные практики крупных ИТ-компаний.

Для реализации новой модели процесса проверки кода, был спроектирован сервис автоматизации, распределяющий задачи на проверку кода между проверяющими на основании карты ответственности, и управляющий рабочим процессом. Проектирование сервиса происходило с использованием UML, в частности были построены диаграммы прецедентов, последовательностей и компонентов.

На этапе разработки сервис был реализован в качестве REST API, базирующегося на серверном фреймворке Node.js. Сервис взаимодействует с BitBucket и Jira используя механизмы Webhooks, а также напрямую через собственные REST API систем. Сервис также включает в себя два микросервиса, призванных снизить централизацию вычислений в одном компоненте. Исходный код приложения является открытым и доступен в Git репозитории по адресу: https://github.com/almostcake/code-review-service.

Во время развёртывания сервис был успешно запущен на облачном хостинге Amazon EC2 в качестве службы Windows с использованием сервисного менеджера NSSM. Также, сервис обладает веб интерфейсом и системой записи логов. Актуальная версия сервиса доступна в сети интернет по адресу https://bbapprovals.6grain.com:4431. Первичный запуск сервиса состоялся 16.04.2018.

...