CI/CD — авторские материалы Сергея Соловьёва

CI/CD расшифровывается как Continuous Integration (CI) и Continuous Delivery/Deployment (CD). Это практики, которые фокусируются на автоматизации процессов разработки и доставки приложений, чтобы ускорить и упростить выпуск изменений.

Иллюстрация к материалу «CI/CD»

Continuous Integration (CI)

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

Основные принципы CI:

Частые коммиты: Разработчики регулярно (и часто) коммитят код в репозиторий.
Автоматизированные тесты: Тесты автоматически запускаются на настроенных событиях — например, при push или создании merge request.
Быстрое исправление ошибок: Проблемы и баги, выявленные на этапе CI, исправляются как можно скорее.

Continuous Delivery (CD)

Continuous Delivery – это практика обеспечения того, чтобы ваш код всегда был готов к развертыванию в продакшн. Это включает в себя дополнительные стадии тестирования и автоматизацию следующих этапов до момента ручного развертывания.

Основные принципы CD:

Автоматизированные релизы: Все изменения кода, прошедшие стадию CI, автоматически переходят к стадии доставки.
Продукт всегда готов к выпуску: Система находится в состоянии, когда ее можно в любой момент безопасно развернуть.

Continuous Deployment (также CD)

Continuous Deployment, хотя и имеет аналогичную аббревиатуру CD, отличается от Continuous Delivery тем, что изменения кода автоматически развертываются в продакшн без ручного вмешательства, при условии, что они прошли все этапы тестирования.

Основные принципы Continuous Deployment:

Автоматическое развертывание: Изменения развертываются без человеческого вмешательства.
Быстрый фидбек: Непосредственный отклик на изменения, позволяя быстрее получать отзывы от конечных пользователей.

Как работает CI/CD:

Коммит кода: Разработчик делает коммит изменений в кодовую базу.
Сборка и тестирование (CI): Изменения автоматически тестируются на ошибки и проблемы с помощью автоматизированных тестов и собираются в артефакт (например, Docker-образ).
Дополнительные этапы тестирования и одобрения (CD - Continuous Delivery): Код проходит дополнительные этапы тестирования и, возможно, стадию одобрения перед развертыванием.
Развертывание (CD - Continuous Deployment): Код автоматически развертывается в продакшн (если речь идет о Continuous Deployment) или готов к ручному развертыванию (если речь идет о Continuous Delivery).

Кто делает всю эту работу?

На примере Gitlab GitLab Runner — это компонент GitLab CI/CD, который используется для выполнения CI/CD jobs и отправки результатов обратно в GitLab. Каждая задача (job) определяется в .gitlab-ci.yml файле в вашем репозитории и будет выполнена в Runner, когда условия выполнения этой задачи будут удовлетворены.

Основные аспекты GitLab Runner:

Регистрация Runner'а:

Runner может быть установлен на различных ОС и облачных платформах.
Runner должен быть зарегистрирован в GitLab, прежде чем он сможет начать обрабатывать задачи.

Executor:

Executor определяет, как Runner будет выполнять задачи. Например, он может выполнять задачи в Docker контейнерах, на виртуальной машине, или даже на физическом хосте.
Примеры executor'ов: shell, docker, kubernetes, ssh и другие. docker-machine executor устарел; для autoscaling GitLab рекомендует Docker Autoscaler.

Concurrency and Scalability:

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

Environment Isolation:

Задачи могут быть выполнены в изолированных средах, например, используя Docker, чтобы обеспечить чистую, управляемую и воспроизводимую среду сборки.

Cache and Artifacts:

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

Tags:

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

Pipelines:

GitLab создаёт и оркестрирует pipeline, а Runner исполняет назначенные ему jobs. Порядок задают stages, dependencies/needs и rules в .gitlab-ci.yml.

Security:

Вы контролируете, где и как Runner запущен, что дает гибкость и контроль над безопасностью окружения CI/CD.

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

Установка и регистрация Runner'а: После установки Runner на подходящем хосте, он регистрируется с использованием токена из вашего GitLab.
**Настройка ****.gitlab-ci.yml**: Определите pipeline, задачи, стадии, скрипты, и т.д. в вашем .gitlab-ci.yml файле в репозитории проекта.
Автоматизация: Когда код пушится в репозиторий или создается merge request, GitLab CI/CD автоматически создает и выполняет pipeline, используя Runner для выполнения задач.

stages:
  - lint
  - test
  - build

lint_code:
  image: python:3.13-slim
  stage: lint
  script:
    - pip install pre-commit black
    - pre-commit run --all-files
    - black --check .

run_tests:
  image: python:3.13-slim
  stage: test
  script:
    - pip install -r requirements.txt
    - pytest

build_image:
  image: docker:29-cli
  stage: build
  services:
    - docker:29-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
    IMAGE_NAME: "$CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG"
  before_script:
    - echo "$CI_JOB_TOKEN" | docker login -u gitlab-ci-token --password-stdin "$CI_REGISTRY"
  script:
    - docker build --pull -t "$IMAGE_NAME" .
    - docker push "$IMAGE_NAME"
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH || $CI_COMMIT_TAG'

Вариант с Docker-in-Docker требует Runner, настроенный для такого режима (обычно privileged). В production стоит выбрать и документировать одну поддерживаемую стратегию сборки: DinD, socket binding или BuildKit.