УДК 004.05

Развертывание и непрерывная интеграция приложений с помощью GITLAB CI/CD

Мулдакаев Марсель Альбертович – студент Казанского национального исследовательского технического университета имени А.Н. Туполева,

Аннотация. В данной статье рассмотрены методы развертывания и непрерывной интеграции приложений с помощью GitLab CI/CD, и представлены  основные принципы и подходы к автоматизации этих процессов.

Ключевые слова: непрерывное развертывание, непрерывная интеграция, тестирование, автоматизация, разработка

Введение

С развитием современных технологий и повышением требований к скорости разработки и поставки программного обеспечения, автоматизация процессов развертывания и непрерывной интеграции становится все более важной задачей для разработчиков. Одним из популярных инструментов для реализации этих процессов является GitLab CI/CD, который позволяет автоматизировать сборку, тестирование и развертывание приложений.

Основная часть

GitLab - это веб-сервис, предоставляющий хостинг для репозиториев Git. GitLab также предоставляет возможности управления проектами, задачами, ветками, запросами на слияние (Merge Requests), системами отслеживания ошибок и многое другое.

GitLab CI/CD - это инструмент для автоматизации процессов непрерывной интеграции и непрерывной поставки (CI/CD) в GitLab. Он позволяет создавать, тестировать и развертывать приложения автоматически, ускоряя процесс разработки и улучшая качество кода.

Сама идея CI/CD является абстракцией. GitLab же в свою очередь представили свое видение CI/CD и реализацию.

CI/CD (Continuous Integration/Continuous Deployment) - это практика в разработке программного обеспечения, которая состоит из двух основных составляющих:

  1. Continuous Integration (непрерывная интеграция) - процесс автоматической сборки и тестирования кода каждый раз, когда разработчики вносят изменения в репозиторий. Это помогает обнаруживать ошибки на ранних этапах разработки и интегрировать новый код в общий репозиторий более эффективно.
  2. Continuous Deployment (непрерывное развертывание) - автоматизированный процесс развертывания изменений, прошедших все проверки и тестирование, в целевую среду (production, staging и т. д.). Это позволяет ускорить процесс поставки новых функций в продакшн и обеспечить непрерывную доставку изменений пользователю.

Структура GitLab CI/CD включает:

  1. Pipeline (Пайплайн) - это набор шагов (jobs), которые выполняются в определенном порядке для сборки, тестирования, развертывания и других операций с приложением.
  2. Job - индивидуальная задача, которая выполняется в рамках pipeline. Каждый job может запускаться параллельно или последовательно в зависимости от конфигурации.
  3. Runner - это агент, который выполняет jobs в pipeline. Он может быть настроен для запуска на локальной машине или в облаке.
  4. YAML-конфигурация - все параметры и настройки для pipeline и jobs определяются в специальном YAML-файле, который хранится в репозитории проекта.

Графически пример пайплайна представлен на Рисунке 1.

d35da4720c5968f3

Рисунок 1. Абстрактный пример пайплайна

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

Для настройки пайплайна в GitLab CI/CD используется файл .gitlab-ci.yml, в котором описывается конфигурация для всех задач пайплайна. Пример конфигурации может выглядеть следующим образом (Рисунок 2)

В примере определены три задачи: build, test и deploy, которые выполняются в порядке, заданном в файла .gitlab-ci.yml. Пайплайн будет запущен автоматически при каждом коммите в репозиторий, и задачи будут выполнены последовательно.

45b623866d383d6f

Рисунок 2. Файл .gitlab-ci.yml

Рассмотрим конкретный пример для API-приложения, написанного на Python в связке с СУБД PostgreSQL. Используя функционал GitLab CI/CD, был реализован следующий пайплайн (Рисунок 3):

f965b7056bb07e50

Рисунок 3. Реализованный пайплайн для API-приложения

На первом этапе в стадии prepare_env подготавливаются переменные окружения приложения. Это различные конфигурационные данные, необходимые перед разворачиванием. Стадии lint-flake8, lint-isort, lint-mypy – это стилистические проверки кода. Стадия build – сборка образа приложения, опираясь на код в репозитории.

На втором этапе при успешном прохождении прошлых стадий идет тестирование кода test-api и миграции для СУБД migrations. Изоляция пайплайна в рамках одного коммита, то есть определенных изменений в коде, позволяет корректно протестировать код в случаях параллельной разработки, когда несколько разработчиков работают на разных ветках репозитория.

В конечном счете, если код удалось собрать для развертывания, и все тесты прошли успешно, коммит с изменениями кода попадает на сервер через стадию run.

Заключение

Таким образом, использование CI/CD в разработке хорошо сказывается на качестве эксплуатации и экономит время. Разработчику нет необходимости при изменениях в коде каждый раз совершать рутинные действия. Тестирование кода через CI/CD позволяет сразу отсекать изменения, которые могут вызвать неработоспособность. В данной статье был рассмотрен инструмент GitLab CI/CD и его использование с примером.

Список литературы

  1. Дюваль Поль М., Матиас Стивен, Гловер Эндрю: Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска. – М.: Вильямс, 2016.
  2. Документация GitLab CI/CD [Электронный ресурс]. https://docs.gitlab.com/ee/ci

Интересная статья? Поделись ей с другими: