Организация непрерывной интеграции в процессе разработки программного обеспечения



Непрерывная интеграция (CI, англ. Continuous Integration) — это подход к разработке программного продукта, заключающийся в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для как можно скорейшего выявления потенциальных дефектов и решения интеграционных проблем. [1]

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

Для контроля версий исходного кода и организации автоматических тестов и сборок мы будем использовать GitLab [2]. GitLab — система управления репозиториями кода для Git и система отслеживания ошибок, дополнительно расширяемая при помощи Omnibus.

В нашем примере мы будем упаковывать приложение на Node.js (Рис. 1) в Docker контейнер для последующей доставки его на сервер.

Рис. 1. Серверное приложение на Node.js

Следующим шагом после создание простого Node.js приложения будет написание автоматического теста, используя библиотеку Mocha. Эта библиотека позволяет писать асинхронные тесты, используя JavaScript, и предоставляет детальный отчет по каждому тест кейсу.

В нашем случае мы будем проверять ответ от сервера, что в нашем случае будет означать его успешную инициализацию. На Рис. 2 представлен пример кода, используемый для тестирования приложения. На строке 10 к нашему серверу будет направлен запрос, на которой он должен ответить, возвратив код 200 и строку “Hello Node.js Server!”.

Рис. 2. Пример теста на библиотеке Mocha

Для запуска теста, изображенного на Рис. 2 необходимо выполнить команду:

“mocha test.js”, где text.js — полное имя файла с тестом. По итогу выполнения этой команды мы увидим результат тестирования (Рис. 3).

Рис. 3. Результат выполнения теста

Для сборки проекта и доставки его на сервер будем использовать Docker. Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы. Для создания Docker образа используются Docker-файлы. Для примера создадим Dockerfile (Рис. 4), наследуя новый образ от node:8.9.0-alpine, с уже предустановленной платформой Node.js.

Рис. 4. Dockerfile для сборки образа контейнера

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

“docker build -t docker-registry.site.com/bushev/example.”, где “docker-registry.site.com” URL адрес Docker регистра а “.” — путь до директории в которой находится Dockerfile.

По завершению сборки готовый образ контейнера можно размещать в Docker регистре. Для этого будем использовать команду для загрузки образа: “docker push docker-registry.site.com/bushev/example”.

Подводя промежуточный итог, мы можем тестировать программный код нашего приложения, причем делать это автоматически, используя специальные команды. Умеем упаковывать программный продукт в Docker образ и размещать его на специальном ресурсе для последующего использования. Теперь нам необходимо реализовать процесс загрузки нашего приложения на сервер и его развертывания. Но перед этим создадим специальный файл -.gitlab-ci.yml (Рис. 5), который будет соответствующим образом управлять нашим GitLab репозиторием и производить сборку, тестирование и доставку продукта при каждом коммите в Git репозиторий на ветку master.

Рис. 5. Структура.gitlab-ci.yml файла

Как видно из.gitlab-ci.yml файла у нас существует четыре основных этапа:

1. Сборка Docker образа
2. Тестирование приложения
3. Выпуск релиза Docker образа в регистр
4. Развертывание приложения на сервере

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

В интерфейсе GitLab можно следить за выполнением всех этапов и видеть историю доставки кода на сервер. На Рис. 6 изображен процесс непрерывной интеграции, состоящий из четырех этапов.

Рис. 6. Процесс непрерывной интеграции

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

Литература:

1. Continuous integration. // Wikipedia. URL: https://en.wikipedia.org/wiki/Continuous_integration (дата обращения: 02.12.2017).
2. GitLab. // URL: https://en.wikipedia.org/wiki/GitLab (дата обращения: 04.12.2017)
3. Docker. // What is Docker. URL: https://www.docker.com/what-docker (дата обращения: 23.11.2017)