1. Создание файла `.gitlab-ci.yml`
Для начала, создайте файл .gitlab-ci.yml в корне вашего репозитория. Это основной файл конфигурации GitLab CI, который будет содержать все инструкции для вашего CI/CD пайплайна.
2. Структура файла
Файл .gitlab-ci.yml состоит из трех ключевых элементов:
- stages — определяют последовательность шагов.
- jobs — описания отдельных шагов, которые выполняются в пайплайне.
- variables — переменные окружения, которые могут использоваться в пайплайне.
stages:
- build
- test
- deploy
variables:
IMAGE_TAG: "latest"
build:
stage: build
script:
- echo "Building project..."
- make build
test:
stage: test
script:
- echo "Running tests..."
- make test
deploy:
stage: deploy
script:
- echo "Deploying application..."
- make deploy
only:
- master
3. Разбор примера
1. Stages: У нас есть три стадии — build, test, и deploy. Эти стадии будут выполняться по очереди.
2. Variables: В разделе variables мы объявили переменную окружения IMAGE_TAG, которая может быть использована в скриптах на разных этапах. Это позволяет гибко управлять окружением.
3. Jobs: В разделе jobs мы определяем задачи для каждой стадии. Каждый job включает:
- stage — на какой стадии выполняется задача.
- script — команды, которые выполняются в контейнере. Например, для сборки проекта мы используем make build.
- В deploy job мы добавили параметр only, чтобы этот этап выполнялся только при пуше в ветку master.
4. Настройки для Docker
Если ваш проект использует Docker, можно настроить запуск контейнеров на различных этапах. Например, чтобы собрать Docker образ, можно добавить в build job следующие команды:
build:
stage: build
script:
- docker build -t myapp:$CI_COMMIT_REF_NAME .
- docker push myapp:$CI_COMMIT_REF_NAME
Здесь $CI_COMMIT_REF_NAME — это переменная GitLab CI, которая автоматически подставляет имя текущей ветки в команду.
5. Тестирование
Для тестирования мы можем добавить выполнение юнит-тестов с использованием Docker или других инструментов:
test:
stage: test
script:
- docker run --rm myapp:$CI_COMMIT_REF_NAME pytest
6. Деплой
Чтобы развернуть приложение на сервере, можно использовать различные методы — SSH, Kubernetes, Helm, и так далее. Например, для деплоя через SSH:
deploy:
stage: deploy
script:
- echo "Deploying application to server..."
- ssh user@myserver "cd /path/to/project && git pull && docker-compose up -d"
only:
- master
7. Множественные окружения
Для более сложных пайплайнов можно настроить несколько окружений для тестирования и деплоя, например:
stages:
- build
- test
- staging
- production
staging:
stage: staging
script:
- echo "Deploying to staging..."
- ssh user@staging-server "deploy-script.sh"
only:
- develop
production:
stage: production
script:
- echo "Deploying to production..."
- ssh user@production-server "deploy-script.sh"
only:
- master
8. Кэширование
Чтобы ускорить сборку, можно использовать кэширование зависимостей или артефактов:
cache:
paths:
- node_modules/
- .mypy_cache/
- .pytest_cache/
artifacts:
paths:
- build/
expire_in: 1 week
Здесь мы кэшируем папки с зависимостями и артефакты сборки, которые могут быть использованы в последующих шагах.
9. Уведомления и алерты
GitLab CI позволяет настроить уведомления о статусе сборок. Это можно сделать через GitLab интерфейс или с помощью интеграции с Slack, email и другими сервисами. В конфигурации .gitlab-ci.yml для этого можно использовать следующий блок:
notifications:
email:
recipients:
- team@example.com
on_success: always
on_failure: always
10. Заключение
GitLab CI — это мощный инструмент для автоматизации процессов разработки, и его настройка в файле .gitlab-ci.yml даёт гибкость для любых нужд проекта. Главное — правильно организовать этапы и задачи, а также использовать переменные и кэширование для ускорения работы.