15 промтов для CI/CD: GitHub Actions, GitLab CI и ArgoCD
Современная CI/CD — это не просто автоматизация сборки и деплоя. Это культура, инструменты и постоянная оптимизация. Как разработчик, который ежедневно работает с пайплайнами, я подготовил подборку из 15 промтов, которые реально ускоряют настройку, отладку и расширение CI/CD-процессов. Каждый промт проверен в бою — на проектах с GitHub Actions, GitLab CI и ArgoCD.
Введение
CI/CD (Continuous Integration / Continuous Delivery) — это практика автоматизации сборки, тестирования и развертывания кода. В 2026 году это стандарт для любой команды, которая хочет выпускать релизы быстро и без багов. GitHub Actions, GitLab CI и ArgoCD — три самых популярных инструмента, каждый со своими фишками. Но как быстро написать рабочий пайплайн, не тратя часы на документацию? Ответ — промты для AI.
Промты — это готовые запросы к AI-моделям (например, GPT-4o, Claude 4.5 или Gemini), которые генерируют код, конфиги и документацию. Я использую их ежедневно: от создания YAML-файлов для GitHub Actions до настройки синхронизации в ArgoCD. Ниже — 15 промтов, разбитых по инструментам. Для каждого есть пример применения и пояснение.
Промты для GitHub Actions
GitHub Actions — самый популярный CI/CD-инструмент для репозиториев на GitHub. Он встроен в экосистему, поддерживает матричные сборки и тысячи готовых actions. Вот 5 промтов, которые я использую чаще всего.
Промт 1. Базовый CI-пайплайн для Node.js
Текст промта:
Напиши GitHub Actions workflow для Node.js проекта. Он должен запускаться на push в main и на pull request. Используй матрицу: node-версии 18, 20, 22. Установи зависимости через npm ci, запусти линтер (eslint), тесты (jest) и сборку (npm run build). Результаты тестов опубликуй как artifact.
Пример вывода (сокращённый):
name: Node.js CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [18, 20, 22]
steps:
- uses: actions/checkout@v4
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- run: npm ci
- run: npx eslint .
- run: npm test -- --coverage
- run: npm run build
- name: Upload test results
uses: actions/upload-artifact@v4
with:
name: test-results-${{ matrix.node-version }}
path: coverage/
Почему это работает: Промт явно указывает триггеры, матрицу, шаги и артефакты. AI генерирует готовый YAML, который можно скопировать в .github/workflows/ci.yml. Экономит 10–15 минут на ручном написании.
Промт 2. Дефолтные secrets для безопасности
Текст промта:
Создай GitHub Actions workflow для деплоя на AWS ECS. Используй OIDC для аутентификации вместо статических ключей. Шаги: checkout, настроить AWS credentials через configure-aws-credentials, собрать Docker образ, запушить в ECR, обновить сервис ECS. Все переменные (AWS_REGION, ECR_REPOSITORY, ECS_CLUSTER, ECS_SERVICE) должны быть секретами.
Зачем: OIDC — современный стандарт безопасности. Промт заставляет AI генерировать код с assume role, без хранения долгоживущих ключей. Пример вывода включает permissions: id-token: write и role-to-assume.
Промт 3. Кэширование зависимостей
Текст промта:
Напиши GitHub Actions workflow для Python проекта с Poetry. Настрой кэширование зависимостей через actions/cache по хешу poetry.lock. Добавь шаги: установка Python 3.12, установка Poetry, установка зависимостей, запуск pytest с coverage. Если кэш не найден — полная установка.
Эффект: Кэширование сокращает время установки зависимостей с 3 минут до 15 секунд. Промт включает restore-keys и key на основе хеша, что минимизирует промахи кэша.
Промт 4. Concurrency и отмена дублирующихся запусков
Текст промта:
Создай GitHub Actions workflow для тестирования на push. Добавь concurrency: отменяй предыдущий запуск для той же ветки (group: ${{ github.workflow }}-${{ github.ref }}, cancel-in-progress: true). Шаги: checkout, установка Go 1.22, go mod download, go test ./... .
Почему это важно: При частых пушах без concurrency очередь забивается старыми пайплайнами. Промт решает проблему «гонки» тестов.
Промт 5. Планировщик и ручной триггер
Текст промта:
Напиши GitHub Actions workflow для ночного бэкапа базы данных. Запускай по расписанию (cron: 0 2 * * *) и вручную через workflow_dispatch. Шаги: установить pg_dump, создать дамп, загрузить в S3 через aws-cli, удалить локальный дамп. Используй secrets для DATABASE_URL и AWS_CREDENTIALS.
Результат: Гибридный триггер — идеально для задач, которые нужно выполнять и по расписанию, и по требованию.
Промты для GitLab CI
GitLab CI — мощный инструмент с встроенным registry, средами и Auto DevOps. Он глубже интегрирован в GitLab, чем GitHub Actions. Вот 5 промтов для работы с ним.
Промт 6. DIND (Docker in Docker) для сборки образов
Текст промта:
Напиши GitLab CI .gitlab-ci.yml для сборки Docker образа с DinD (service: docker:24.0.7-dind). Этапы: test (запуск тестов в контейнере с golang:1.22), build (сборка Docker образа и push в GitLab Container Registry), deploy (запуск на production сервере через SSH). Используй before_script для логина в registry. Теги: docker.
Пример вывода (фрагмент):
stages:
- test
- build
- deploy
variables:
DOCKER_TLS_CERTDIR: "/certs"
IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
services:
- docker:24.0.7-dind
test:
stage: test
image: golang:1.22
script:
- go test ./...
except:
- tags
build:
stage: build
image: docker:24.0.7
before_script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
script:
- docker build -t $IMAGE_TAG .
- docker push $IMAGE_TAG
only:
- tags
Фишка: DinD требует особого тюнинга (переменные DOCKER_TLS_CERTDIR, тег docker). Промт явно это указывает.
Промт 7. GitLab Environments и manual approval
Текст промта:
Создай GitLab CI пайплайн с тремя средами: staging, production и canary. staging запускается автоматически на push в main. production — только по нажатию кнопки (when: manual, environment: production). canary — после production с ограничением 10% трафика. Добавь review apps для каждой ветки.
Зачем: Environments в GitLab CI — мощный механизм отслеживания деплоев. Промт генерирует конфиг с environment: name: production и action: start, что даёт автоматические метрики и откаты.
Промт 8. Кэширование в GitLab CI
Текст промта:
Настрой GitLab CI для Ruby on Rails проекта. Используй кэширование vendor/bundle через cache:key: $CI_COMMIT_REF_SLUG. Этапы: bundle install, rubocop, rspec, build assets. Кэш обновляй только при изменении Gemfile.lock.
Эффект: Без кэша bundle install занимает 2-3 минуты, с кэшем — 10 секунд. Промт использует cache:paths и cache:policy: pull-push для оптимизации.
Промт 9. Include templates для переиспользования
Текст промта:
Создай GitLab CI конфиг, который использует include:template: Auto-DevOps.gitlab-ci.yml и переопределяет stages. Добавь кастомный job для SAST (Semgrep) и секретный сканер (TruffleHog). Используй include:project для общего шаблона из другого репозитория.
Почему это удобно: Include templates — стандарт GitLab CI для модульности. Промт генерирует include:
- template: Auto-DevOps.gitlab-ci.yml
- project: 'myorg/shared-pipelines'
file: '/templates/sast.yml', что сокращает дублирование.
Промт 10. Multi-project pipelines
Текст промта:
Настрой GitLab CI для монорепозитория с микросервисами. Используй rules:changes для запуска только изменённых пайплайнов. Добавь триггер для пайплайна в другом проекте (trigger: project: myorg/infra, branch: main). Параметры: передай COMMIT_SHA и SERVICE_NAME.
Результат: Промт решает проблему «каждый push запускает все пайплайны». Rules с changes экономят ресурсы в 5-10 раз.
Промты для ArgoCD
ArgoCD — GitOps-инструмент для Kubernetes. Он синхронизирует состояние кластера с Git-репозиторием. В 2026 году это стандарт для деплоя в K8s. Вот 5 промтов для настройки и отладки.
Промт 11. ApplicationSet с генерацией по Git
Текст промта:
Создай ArgoCD ApplicationSet для генерации приложений из папок в Git-репозитории. Используй generators: git: directories с путём apps/*/. Для каждой папки создай Application с параметрами: name: {{path.basename}}, namespace: {{path.basename}}, syncPolicy: automated. Укажи source: repoURL, targetRevision: HEAD, path: apps/{{path.basename}}.
Пример вывода:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: my-apps
spec:
generators:
- git:
repoURL: https://github.com/myorg/k8s-configs.git
revision: HEAD
directories:
- path: apps/*
template:
metadata:
name: '{{path.basename}}'
spec:
project: default
source:
repoURL: https://github.com/myorg/k8s-configs.git
targetRevision: HEAD
path: '{{path}}'
destination:
server: https://kubernetes.default.svc
namespace: '{{path.basename}}'
syncPolicy:
automated:
prune: true
selfHeal: true
Фишка: ApplicationSet — киллер-фича ArgoCD для массового деплоя. Промт генерирует шаблон, который автоматически создаёт приложения для каждой новой папки.
Промт 12. Sync phases и waves для канареечного деплоя
Текст промта:
Настрой ArgoCD Application для канареечного деплоя. Используй syncPolicy: automated с syncOptions: CreateNamespace=true. Добавь sync waves: wave 0 (ConfigMap, Secret), wave 1 (Deployment), wave 2 (Service, Ingress). Для Deployment укажи annotation argocd.argoproj.io/sync-wave: "1".
Зачем: Sync waves гарантируют порядок применения ресурсов. Например, ConfigMap должен быть создан до Deployment. Промт задаёт правильные аннотации и параметры.
Промт 13. Health checks для кастомных ресурсов
Текст промта:
Создай ArgoCD Application для оператора PostgreSQL. Добавь кастомный health check через resource.customizations: для ресурса PostgresCluster (группа postgres-operator.crunchydata.com) — проверяй статус .status.state == "Running". Укажи syncPolicy: automated с selfHeal.
Результат: Без health check ArgoCD считает ресурс здоровым сразу после создания. Промт добавляет LUA-скрипт или JSON-путь для проверки реального состояния.
Промт 14. Multi-source и Helm values
Текст промта:
Настрой ArgoCD Application с двумя источниками: основной — Helm-чарт из репозитория (source 1), дополнительный — файл values.yaml из другого репозитория (source 2). Используй plugin: helm для объединения. Укажи ref: values для второго источника.
Почему это нужно: Multi-source — функция ArgoCD 2.6+, позволяющая переопределять values без форка чарта. Промт генерирует sources: [...] вместо одного source.
Промт 15. ArgoCD Rollout для прогрессивного деплоя
Текст промта:
Создай Argo Rollouts Rollout для канареечного деплоя с анализом трафика. Шаги: 10% трафика на 5 минут, анализ через prometheus (success rate > 99%), затем 50% на 5 минут, затем 100%. Используй template: spec из Deployment. Добавь ingress с canary-сервисом.
Пример вывода (упрощённо):
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: my-app
spec:
replicas: 10
strategy:
canary:
steps:
- setWeight: 10
- pause: {duration: 5m}
- analysis:
templates:
- templateName: success-rate
- setWeight: 50
- pause: {duration: 5m}
- setWeight: 100
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: myapp:latest
Фишка: Argo Rollouts — отдельный инструмент для прогрессивного деплоя. Промт объединяет Rollout с AnalysisTemplate, что автоматически откатывает релиз при падении метрик.
Заключение
Промты для CI/CD — не магия, а инструмент, который экономит часы рутинной работы. GitHub Actions, GitLab CI и ArgoCD — мощные системы, но их конфигурация требует точности. Используя эти 15 промтов, вы можете:
- Сократить время настройки пайплайна с 30 минут до 2-3 минут.
- Избежать типичных ошибок (например, забытые secrets или неправильный кэш).
- Стандартизировать процессы в команде через шаблоны.
Попробуйте эти промты в своей работе. Адаптируйте их под ваш стек — замените Node.js на Python, Go или Java. Главное — понимать, что каждый промт — это основа, которую нужно дорабатывать под конкретный проект.
Если вы хотите углубиться в тему промтов для DevOps, обратите внимание на курсы по автоматизации. ASI Biont поддерживает подключение к GitHub, GitLab и Kubernetes через API — подробнее на asibiont.com/courses. Там разобраны реальные кейсы с пайплайнами для микросервисных архитектур.
Автоматизируйте рутину, фокусируйтесь на архитектуре. CI/CD должен работать сам — а вы должны пилить код.
Комментарии