Где в GitLab настраивается CI/CD?

Основная конфигурация CI/CD в GitLab задается через YAML-файл .gitlab-ci.yml, который должен находиться в корне репозитория. Этот файл определяет весь пайплайн: этапы, задания, скрипты и политики выполнения.

Почему именно файл в репозитории? Это реализация принципа GitOps и Infrastructure as Code (IaC) для CI/CD. Конфигурация пайплайна версионируется вместе с кодом, проходит code review, и её изменения отслеживаются так же, как и изменения в коде приложения.

Базовая структура файла .gitlab-ci.yml:

# 1. Определяем этапы пайплайна (выполняются последовательно)
stages:
  - build
  - test
  - deploy

# 2. Переменные, общие для всех заданий
variables:
  DOCKER_IMAGE_TAG: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"

# 3. Задание для сборки
build_job:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $DOCKER_IMAGE_TAG .
    - docker push $DOCKER_IMAGE_TAG
  only:
    - main  # Запускать только при пуше в main

# 4. Задание для тестирования
test_unit:
  stage: test
  image: python:3.9
  script:
    - pip install -r requirements.txt
    - pytest tests/unit/
  artifacts: # Сохраняем отчеты для следующего этапа
    reports:
      junit: report.xml
    paths:
      - coverage/

# 5. Задание для деплоя в staging
deploy_to_staging:
  stage: deploy
  image: alpine/helm:latest
  script:
    - helm upgrade --install myapp ./chart --namespace staging --set image.tag=$CI_COMMIT_SHORT_SHA
  environment:
    name: staging
    url: https://staging.myapp.com
  when: manual # Требует ручного запуска

Дополнительные настройки в интерфейсе GitLab (Settings > CI/CD):

• Variables: Задаю защищенные (masked) или секретные (file) переменные окружения (например, KUBECONFIG, AWS_ACCESS_KEY_ID). Никогда не храню секреты в .gitlab-ci.yml.
• Runners: Настраиваю специфичных раннеров (например, с тегами docker или kubernetes) для разных типов заданий.
• General pipelines: Устанавливаю лимиты времени выполнения, политики слияния (merge trains).

Для сложных проектов я активно использую include: для подключения общих шаблонов из других репозиториев и extends: для повторного использования конфигурации заданий, что позволяет избежать дублирования кода в CI/CD.