Ответ
В моих проектах пайплайн Continuous Integration (CI) обычно состоит из следующих этапов, автоматически запускаемых при каждом push в репозиторий:
- Fetch & Checkout: Клонирование репозитория и переход в нужную ветку/коммит.
- Dependency Installation: Установка зависимостей проекта. Например, для Node.js это
npm ci, для Python —pip install -r requirements.txt, для Java/Maven — загрузка артефактов из Nexus. - Static Analysis (Linting/SAST): Проверка кода на соответствие стилю и поиск потенциальных уязвимостей. Я использую
sonarqube-scanner,golangci-lint,hadolintдля Dockerfile. - Build/Compilation: Сборка артефакта приложения. Например,
docker build -t app:$CI_COMMIT_SHA .,mvn clean package,go build -o bin/app. - Unit Testing: Запуск модульных тестов с измерением покрытия. Я настраиваю сборку отчетов для инструментов вроде JaCoCo (Java) или
pytest-cov(Python). - Integration Testing: Запуск тестов, проверяющих взаимодействие с внешними сервисами (БД, очереди сообщений). Часто для этого разворачивается временное тестовое окружение с помощью Docker Compose или в Kubernetes (namespace
ci-*). - Artifact Publishing: Сохранение собранного артефакта (Docker-образа, JAR-файла) в реестр. Я пушил образы в GitLab Container Registry или Harbor, а бинарники — в Nexus или S3.
- Smoke Testing (Optional): Базовая проверка работоспособности только что собранного артефакта, например, запуск health-check эндпоинта.
Пример конфигурации в GitLab CI:
stages:
- test
- build
- integration
- publish
variables:
DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
lint:
stage: test
script:
- golangci-lint run ./...
unit-test:
stage: test
script:
- go test -v -coverprofile=coverage.out ./...
artifacts:
reports:
coverage_report:
coverage_format: cobertura
path: coverage.out
build:
stage: build
script:
- docker build -t $DOCKER_IMAGE .
- docker push $DOCKER_IMAGE
only:
- main
- merge_requests