GitFlic CI/CD: первый конвейер с нуля — от коммита до деплоя

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

GitFlic имеет встроенный инструмент CI/CD, который не требует установки сторонних решений вроде Jenkins. Достаточно добавить в репозиторий файл конфигурации, настроить агента — и конвейер заработает сам.

В этой статье разберем, как устроен GitFlic CI/CD, из каких концепций он состоит и как написать первый рабочий конвейер с нуля.

Как устроен GitFlic CI/CD

GitFlic CI/CD реализует несколько ключевых концепций:

Конвейер (Pipeline) — Структурирует задачи через определение стадий и последовательности выполнения
Задача (Job) — Фундаментальная единица конфигурации CI/CD — инструкция, которую нужно выполнить
Артефакты (Artifacts) — Файлы, являющиеся результатом выполнения задачи, которые сохраняются для дальнейшего использования
Кэш (Cache) — Хранение файлов (например, зависимостей) в рамках рабочего окружения агента для ускорения повторных действий и сборки
Агент (Runner) — приложение, которое физически выполняет задачи

Вся конфигурация описывается в YAML-файле, который хранится прямо в репозитории.

Файл конфигурации: gitflic-ci.yaml

Пайплайн описывается в файле gitflic-ci.yaml в корне репозитория. Это аналог .gitlab-ci.yml — если вы работали с GitLab CI, многое покажется знакомым. GitFlic даже публикует [сравнение синтаксиса с GitLab](https://docs.gitflic.ru/latest/common/compare_yaml/).

Рассмотрим основные ключевые слова файла конфигурации.

stages — стадии конвейера

Задает порядок выполнения стадий. Задачи одной стадии выполняются параллельно; стадии выполняются последовательно.

«`yaml

stages:

— test

— build

— deploy

«`

image — Docker-образ

Указывает Docker-образ, в котором будет выполняться задача.

«`yaml

image:

«`

Поддерживаются уточняющие параметры: image:name, image:entrypoint, image:docker, image:pull_policy.

variables — переменные

Задает переменные окружения, доступные внутри задач.

«`yaml

variables:

APP_ENV: «production»

REGISTRY: «registry.gitflic.ru«

«`

GitFlic также поддерживает набор предопределенных переменных (CI_COMMIT_SHA, CI_PROJECT_NAME, CI_PIPELINE_ID и другие), которые автоматически доступны в каждом пайплайне.

cache — кэш зависимостей

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

«`yaml

cache:

paths:

— .venv/

key: $CI_COMMIT_REF_NAME

«`

script, before_script, after_script

Основная часть задачи. before_script выполняется перед script, after_script — после (даже если script завершился с ошибкой).

«`yaml

job_name:

before_script:

— pip install -r requirements.txt

script:

— pytest tests/

after_script:

— echo «Done»

«`

artifacts — артефакты

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

«`yaml

artifacts:

paths:

— build/

expire_in: 7 days

«`

rules и when — условия запуска

Задают, при каких условиях задача должна запускаться.

«`yaml

rules:

— if: ‘$CI_COMMIT_BRANCH == «main»‘

when: always

— when: never

«`

when может принимать значения: always, on_success, on_failure, manual, never.

tags — выбор агента

Направляет задачу на конкретного агента по его тегу.

«`yaml

tags:

— docker

— linux

«needs — зависимости между задачами

Нельзя запустить задачу, пока не будет успешно выполнена другая указанная задача.

«`yaml

deploy:

needs: [build]

script:

— ./deploy.sh

«`

Агент (Runner): кто выполняет задачи

Агент — это приложение, которое опрашивает GitFlic на наличие задач и выполняет их используя ресурсы сервера, на котором запущен. Без агента конвейер не запустится.

В GitFlic доступны разные варианты развертывания агента:

— Shell — выполняет команды напрямую в оболочке сервера.

— PowerShell — для задач на Windows.

— Docker — выполняет каждую задачу в изолированном Docker-контейнере.

— Также поддерживается запуск агента в Docker-контейнере или в Kubernetes.

Подробные инструкции по установке агента для каждого типа — в документации:

— [Агент Shell](https://docs.gitflic.ru/latest/setup/runner/installshell/)

— [Агент PowerShell](https://docs.gitflic.ru/latest/setup/runner/installpowershell/)

— [Агент Docker](https://docs.gitflic.ru/latest/setup/runner/installdocker/)

— [Агент в Kubernetes](https://docs.gitflic.ru/latest/setup/runner/kuber_run/)

После установки агент регистрируется в настройках проекта: Настройки проекта → Агенты CI/CD. Там же можно управлять зарегистрированными агентами и просматривать задачи, которые они выполняют.

Практика: пишем первый пайплайн

Разберем реальный пример — пайплайн для Python-проекта: установка зависимостей, запуск тестов и деплой на сервер.

Структура проекта

my-project/

├── app/

│ └── main.py

├── tests/

│ └── test_main.py

├── requirements.txt

└── gitflic-ci.yaml

Файл gitflic-ci.yaml

«`yaml

stages:

— test

— build

— deploy

variables:

APP_NAME: «my-app»

«`

Кэшируем зависимости между запусками

«`yaml

cache:

paths:

— .venv/

key: $CI_COMMIT_REF_NAME

«`

Стадия 1: тесты

«`

run-tests:

stage: test

image:

before_script:

— source .venv/bin/activate

script:

— pytest tests/ —tb=short

artifacts:

paths:

— test-results/

when: always

expire_in: 7 days

«`

Стадия 2: сборка

«`

install-deps:

stage: build

needs: [run-tests]

image:

before_script:

— python -m venv .venv

— source .venv/bin/activate

script:

— pip install -r requirements.txt

artifacts:

paths:

— .venv/

expire_in: 1 hour

Стадия 3: деплой (только из main)

«`

deploy-production:

stage: deploy

needs: [install-deps]

script:

— echo «Deploying $APP_NAME to production…»

— ./scripts/deploy.sh

rules:

— if: ‘$CI_COMMIT_BRANCH == «main»‘

when: on_success

— when: never

tags:

— production

— linux

environment:

url: https://my-app.example.com

Разбор конфигурации

stages задает три стадии: test → build → deploy. Они выполняются строго последовательно. Если тесты упадут, деплой не запустится.

cache сохраняет виртуальное окружение .venv/ между запусками, привязывая кэш к имени ветки ($CI_COMMIT_REF_NAME). Это сильно ускоряет повторные сборки: зависимости не нужно скачивать заново.

needs: [install-deps] в задаче run-tests говорит GitFlic запустить тесты сразу после установки зависимостей, не дожидаясь конца всей стадии build.

rules в задаче deploy-production ограничивают деплой только ветками main. На всех остальных ветках задача не запустится (when: never).

environment связывает деплой с окружением production и задает URL приложения. Это позволяет отслеживать состояние окружений прямо в GitFlic — в разделе [Окружения](https://docs.gitflic.ru/latest/cicd/environment/).

tags: [production, linux] направляет деплой на агента с тегами production и linux. Это нужно, чтобы деплой выполнялся только на том сервере, у которого есть доступ к продакшн-окружению.

Оптимизация конфигурационного файла

Когда конвейеры разрастаются, файл gitflic-ci.yaml может стать громоздким. GitFlic поддерживает несколько механизмов оптимизации.

extends — наследование задач

Позволяет вынести общие параметры в шаблон и переиспользовать их:

«`yaml

.base-python:

image:

before_script:

— source .venv/bin/activate

run-tests:

extends: .base-python

stage: test

script:

— pytest tests/

run-linter:

extends: .base-python

stage: test

script:

— flake8 app/

«`

Задачи, начинающиеся с точки (.base-python), не запускаются как самостоятельные джобы — они служат шаблонами.

YAML Anchors

Стандартные YAML-якоря тоже работают:

«`yaml

.defaults: &defaults

image:

tags:

— linux

run-tests:

<<: *defaults

script:

— pytest

«`

include — подключение внешних файлов конфигурации

Поддерживается включение конфигурации из других файлов. Это удобно для монорепозиториев или общих шаблонов:

«`yaml

include:

— local: ‘.ci/templates.yml’

— project: ‘gitflic/ci-templates’

file: ‘/python.yml’

«`

Варианты: include:local, include:project, include:remote, include:component.

Шаблоны конфигураций

GitFlic предоставляет готовые [шаблоны конфигураций](https://docs.gitflic.ru/latest/cicd/cicd_templates/), которые можно использовать как отправную точку. Они покрывают типовые сценарии: сборку приложений, работу с Docker, публикацию пакетов.

Настройка CI/CD в настройках проекта

Прежде чем конвейер начнет работать, нужно включить CI/CD в настройках проекта. В разделе Настройки проекта → Настройка CI/CD ([документация](https://docs.gitflic.ru/latest/cicd/cicd-settings/)) доступны:

— настройка пути к конфигурационному файлу (по умолчанию gitflic-ci.yaml в корне);

— управление переменными окружения для CI/CD;

— настройка артефактов и их хранения.

Встроенные инструменты безопасности

GitFlic CI/CD идет дальше простой сборки и тестирования — есть возможность подключить инструменты анализа безопасности:

— [SAST](https://docs.gitflic.ru/latest/cicd/sast/) — статический анализ кода на уязвимости.

— [DAST](https://docs.gitflic.ru/latest/cicd/dast/) — динамическое тестирование безопасности запущенного приложения.

— [SCA](https://docs.gitflic.ru/latest/cicd/sca/) — анализ зависимостей на известные уязвимости.

— [Unit-тесты](https://docs.gitflic.ru/latest/cicd/unit-tests/) — отчеты о покрытии кода тестами.

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

Планировщик конвейеров

Если нужно запускать конвейер по расписанию — например, ночная сборка или еженедельный прогон регресс-тестов — GitFlic поддерживает [планировщик конвейеров](https://docs.gitflic.ru/latest/cicd/pipeline-scheduler/). Расписание настраивается прямо в интерфейсе без изменения gitflic-ci.yaml.

Пример, как обновлять тестовые окружения каждые 12 часов.

Переменные и секреты

Пароли, токены и другие чувствительные данные не должны храниться в репозитории. В GitFlic CI/CD для этого есть:

— Переменные CI/CD — задаются в настройках проекта и доступны во всех пайплайнах как переменные окружения.

— Vault — интеграция с HashiCorp Vault для централизованного управления секретами ([документация](https://docs.gitflic.ru/latest/cicd/vault/)).

— StarVault — собственное хранилище секретов GitFlic ([документация](https://docs.gitflic.ru/latest/cicd/starvault/)).

Интеграция с Kubernetes

GitFlic CI/CD поддерживает интеграцию с Kubernetes-кластерами. Для этого в кластере разворачивается специальный агент, который регистрируется в GitFlic. После этого задачи конвейера могут запускаться прямо в Kubernetes. Подробности — в разделе [Интеграция с Kubernetes](https://docs.gitflic.ru/latest/cicd/kuber-integration/connect_to_kuber_cluster/).

Поезда слияния (Merge Trains)

Для команд, которые активно используют запросы на слияние, GitFlic CI/CD предлагает [поезда слияния](https://docs.gitflic.ru/latest/cicd/merge_trains/). Это механизм, при котором несколько запросов на слияние объединяются в очередь и тестируются последовательно — как если бы они уже были слиты вместе. Это повышает надежность интеграции и снижает количество конфликтов.

Типичные ошибки при настройке первого пайплайна

Агент не подключен. Убедитесь, что агент зарегистрирован в настройках проекта и работает. Без агента задачи будут висеть в статусе «Ожидает выполнения».

Теги задачи не совпадают с тегами агента. Если в задаче указан тег docker, а у агента тег shell, задача не запустится. Проверьте теги в настройках агента и в конфигурации задачи.

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

Артефакты не передаются между задачами. Убедитесь, что задача, которая создает артефакты, указана в needs задачи, которая их потребляет.

> Тут явно кто-то забыл включить GitFlic Runner.

Итоги

GitFlic CI/CD — полноценный инструмент непрерывной интеграции и доставки, встроенный прямо в платформу. Он не требует сторонних сервисов и настраивается через один YAML-файл в репозитории.

Для старта достаточно двух шагов:

Установить и зарегистрировать агента.
Добавить файл gitflic-ci.yaml в репозиторий.

Дальше — расширяйте пайплайн по мере роста потребностей: добавляйте SAST, настраивайте окружения, подключайте Vault для секретов.

Полная документация по теме:

— [Введение в GitFlic CI/CD](https://docs.gitflic.ru/latest/cicd/introduction/ )

— [Справочник по gitflic-ci.yaml](https://docs.gitflic.ru/latest/cicd/gitflic-ci-yaml/ )

— [Агенты CI/CD](https://docs.gitflic.ru/latest/cicd/agent/ )

— [Конвейер](https://docs.gitflic.ru/latest/cicd/pipeline/ )

— [Примеры использования](https://docs.gitflic.ru/latest/cicd/examples/)

Автор: Андрей Козлов, руководитель отдела тестирования GitFlic

ссылка на оригинал статьи https://habr.com/ru/articles/1056640/