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

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

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

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

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

1. Конвейер (Pipeline) — Структурирует задачи через определение стадий и последовательности выполнения 

2. Задача (Job) — Фундаментальная единица конфигурации CI/CD — инструкция, которую нужно выполнить 

3. Артефакты (Artifacts) — Файлы, являющиеся результатом выполнения задачи, которые сохраняются для дальнейшего использования 

4. Кэш (Cache) — Хранение файлов (например, зависимостей) в рамках рабочего окружения агента для ускорения повторных действий и сборки 

5. Агент (Runner) — приложение, которое физически выполняет задачи 

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

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

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

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

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

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

stages:

 - test

 - build

 - deploy

image — Docker-образ

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

image:

  name: python:3.11

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

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

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

variables:

  APP_ENV: "production"

  REGISTRY: "registry.gitflic.ru"

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

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

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

cache:

  paths:

    - .venv/

  key: $CI_COMMIT_REF_NAME

script, before_script, after_script

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

job_name:

  before_script:

    - pip install -r requirements.txt

  script:

    - pytest tests/

  after_script:

    - echo "Done"

artifacts — артефакты

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

artifacts:

  paths:

    - build/

  expire_in: 7 days

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

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

rules:

  - if: '$CI_COMMIT_BRANCH == "main"'

    when: always

  - when: never

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

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

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

tags:

  - docker

  - linux

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

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

deploy:

  needs: [build]

  script:

    - ./deploy.sh

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

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

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

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

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

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

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

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

• Агент Shell

• Агент PowerShell

• Агент Docker

• Агент в Kubernetes

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

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

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

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

my-project/

├── app/

│   └── main.py

├── tests/

│   └── test_main.py

├── requirements.txt

└── gitflic-ci.yaml

Файл gitflic-ci.yaml

stages:

  - test

  - build

  - deploy

variables:

  APP_NAME: "my-app"

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

cache:

  paths:

    - .venv/

  key: $CI_COMMIT_REF_NAME

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

run-tests:

  stage: test

  image:

    name: python:3.11

  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:

    name: python:3.11

  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:

    name: production

    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 — наследование задач

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

.base-python:

  image:

    name: python:3.11

  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-якоря тоже работают:

.defaults: &defaults

  image:

    name: python:3.11

  tags:

    - linux

run-tests:

  <<: *defaults

  script:

    - pytest

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

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

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 — статический анализ кода на уязвимости.

• DAST — динамическое тестирование безопасности запущенного приложения.

• SCA — анализ зависимостей на известные уязвимости.

• Unit-тесты — отчеты о покрытии кода тестами.

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

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

Если нужно запускать конвейер по расписанию — например, ночная сборка или еженедельный прогон регресс-тестов — GitFlic поддерживает планировщик конвейеров. Расписание настраивается прямо в интерфейсе без изменения gitflic-ci.yaml.

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

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

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

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

• Vault — интеграция с HashiCorp Vault для централизованного управления секретами документация.

• StarVault — собственное хранилище секретов GitFlic документация.

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

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

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

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

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

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

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

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

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

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

Итоги

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

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

1. Установить и зарегистрировать агента.

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

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

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

• Введение в GitFlic CI/CD

• Справочник по gitflic-ci.yaml

• Агенты CI/CD

• Конвейер

• Примеры использования

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

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