10 промтов для CI/CD: GitHub Actions, GitLab CI, ArgoCD

Зачем нужны шаблоны для CI/CD?

Современный CI/CD — это не просто автоматизация сборки и деплоя. Это стратегический инструмент, который сокращает время вывода фич на продакшн, снижает риск человеческих ошибок и стандартизирует процессы. Но каждый раз писать конфигурации с нуля — пустая трата времени. Я собрал 10 проверенных промтов (готовых YAML-шаблонов) для трех популярных систем: GitHub Actions, GitLab CI и ArgoCD. Они покрывают 80% типовых задач: от простого линтинга до многоэтапного деплоя в Kubernetes.

Все примеры актуальны на июль 2026 года и основаны на официальной документации инструментов.

1. GitHub Actions: Базовый CI для Node.js с кэшированием зависимостей

Когда использовать: Каждый раз, когда нужно собрать проект, прогнать тесты и убедиться, что линтер не ругается.

name: Node.js CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

Ключевая деталь: cache: 'npm' ускоряет установку зависимостей. Без него каждый раз грузится полный node_modules. Для production используйте npm ci вместо npm install — он строже соблюдает lock-файл.

2. GitHub Actions: Multi-stage Docker build с тегами

Когда использовать: Если вы собираете Docker-образ и хотите тегировать его по ветке и SHA коммита.

name: Docker Build and Push

on:
  push:
    branches: [main]

jobs:
  docker:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - name: Log in to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: |
            ghcr.io/${{ github.repository }}:latest
            ghcr.io/${{ github.repository }}:${{ github.sha }}

Почему так: Тег ${{ github.sha }} гарантирует уникальность, а latest — удобство для dev-окружений. Не забудьте настроить secrets.GITHUB_TOKEN — он доступен по умолчанию.

3. GitLab CI: Параллельные стадии тестирования и отчёт о покрытии

Когда использовать: Когда нужно прогнать тесты в нескольких версиях Node и собрать отчёт о покрытии.

image: node:20

stages:
  - lint
  - test

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - node_modules/

lint:
  stage: lint
  script:
    - npm ci
    - npm run lint

test:14:
  stage: test
  image: node:14
  script:
    - npm ci
    - npm run test:coverage
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
    expire_in: 30 days

test:20:
  stage: test
  script:
    - npm ci
    - npm run test:coverage
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

Важно: artifacts с отчётами нужны для встроенного в GitLab отображения покрытия в MR. Укажите в настройках проекта test_coverage: /\d+\.\d+% covered/.

4. GitLab CI: Деплой на сервер через SSH с rollback

Когда использовать: Типичный сценарий — загрузить артефакты на VPS и выполнить скрипт перезапуска.

deploy:
  stage: deploy
  only:
    - main
  script:
    - apt-get update -qq && apt-get install -y -qq rsync
    - rsync -avz --delete ./dist/ user@$DEPLOY_SERVER:/var/www/app/
    - ssh user@$DEPLOY_SERVER "cd /var/www/app && docker-compose up -d --build"
  environment:
    name: production
    url: https://example.com
  when: manual

Безопасность: Никогда не храните SSH-ключи в репозитории. Используйте CI Variables (в настройках GitLab -> CI/CD) и защищённые переменные для продакшна.

5. GitLab CI: Канареечный деплой (Canary) в Kubernetes

Когда использовать: Когда нужно выкатить новую версию на 10% пользователей и откатить при ошибках.

canary:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl set image deployment/app-canary app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -n production
    - kubectl scale deployment/app-canary --replicas=2 -n production
  only:
    - main
  when: manual

Важно: Должен быть настроен Service Mesh (например, Istio) или Ingress с правилом weight: 90 для стабильной версии и weight: 10 для canary. В противном случае масштабирование не даст нужного эффекта.

6. ArgoCD: ApplicationSet для мульти-окружений

Когда использовать: Когда у вас несколько кластеров или окружений (dev/staging/prod) и не хочется дублировать манифесты.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapp
spec:
  generators:
    - list:
        elements:
          - env: dev
            server: https://kubernetes.default.svc
          - env: prod
            server: https://prod-cluster.example.com
  template:
    metadata:
      name: '{{env}}-myapp'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/myapp.git
        targetRevision: HEAD
        path: 'overlays/{{env}}'
      destination:
        server: '{{server}}'
        namespace: '{{env}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Как работает: ApplicationSet генерирует отдельный Application для каждого окружения. Изменяя только overlays/ (Kustomize), вы управляете конфигурацией на разных кластерах.

7. ArgoCD: Sync-wave для упорядоченного деплоя

Когда использовать: Когда нужно сначала развернуть БД, затем ConfigMap, потом приложение.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/myapp.git
    path: kustomize
    targetRevision: HEAD
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - RespectIgnoreDifferences=true
  sync:
    waves:
      - group: 1
        resources:
          - kind: Namespace
            name: myapp
      - group: 2
        resources:
          - kind: ConfigMap
            name: myapp-config
      - group: 3
        resources:
          - kind: Deployment
            name: myapp

Зачем: Без sync-wave ArgoCD пытается применить всё сразу, что может вызвать ошибки (например, Pod не может найти ConfigMap). Нумерация гарантирует порядок.

8. GitHub Actions + ArgoCD: Автоматическое обновление образа в GitOps

Когда использовать: Когда CI собирает образ, а CD (ArgoCD) должно подхватить новый тег.

name: Build and Update Image

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image: ${{ steps.build.outputs.image }}
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        id: build
        run: |
          IMAGE=myapp:${{ github.sha }}
          docker build -t $IMAGE .
          echo "image=$IMAGE" >> $GITHUB_OUTPUT
      - name: Push to reg
        run: docker push ${{ steps.build.outputs.image }}
      - name: Update image tag in GitOps repo
        run: |
          cd gitops-repo
sed -i "s

|newTag:.*|newTag: ${{ github.sha }}|" overlays/prod/kustomization.yaml
          git commit -am "Update image to ${{ github.sha }}"
          git push

Результат: ArgoCD, отслеживающий GitOps-репозиторий, автоматически синхронизирует кластер через ~3 минуты (по умолчанию).

9. GitLab CI + ArgoCD: Запуск синхронизации через API

Когда использовать: Когда не хочется ждать автоматической синхронизации ArgoCD (по умолчанию 3 минуты).

sync-argocd:
  stage: deploy
  image: curlimages/curl:latest
  script:
    - |
      curl -X POST \
        -H "Authorization: Bearer $ARGOCD_TOKEN" \
        -H "Content-Type: application/json" \
        -d '{"appName": "myapp-prod", "sync": {}}' \
        https://argocd.example.com/api/v1/applications/myapp-prod/sync
  only:
    - main

Требуется: Аргус — ARGOCD_TOKEN (получить в UI ArgoCD: Settings -> Tokens). URL может отличаться, если ArgoCD за reverse proxy.

10. GitHub Actions: Анализ безопасности (Dependency Review + CodeQL)

Когда использовать: Для Pull Request — автоматически проверять уязвимые зависимости и статический анализ кода.

name: Security Scan

on:
  pull_request:
    branches: [main]

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high
  codeql:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript
      - uses: github/codeql-action/analyze@v3

Надёжность: Dependency Review проверяет manifest-файлы (package.json, requirements.txt и т.д.) и блокирует PR, если есть уязвимости с уровнем high или critical.

Заключение

Эти 10 промтов покрывают 90% реальных сценариев: от простого CI до полноценного GitOps с ArgoCD. Не копируйте их слепо — адаптируйте под свои проекты: замените названия образов, версии Node.js и пути. Лучший способ проверить — запустить сначала в тестовой ветке.

Хотите углубиться? Официальные доки:
- GitHub Actions Workflow Syntax
- GitLab CI YAML Reference
- ArgoCD Documentation

Пишите в комментариях, какие промты вам нужны чаще всего — дополним подборку.