10 промтов для CI/CD: GitHub Actions, GitLab CI и ArgoCD — от базовых до экспертных

Введение

CI/CD (Continuous Integration/Continuous Deployment) — это backbone современной DevOps-культуры. Без автоматизации сборки, тестирования и выкладки кода сложно представить себе проект, который обновляется чаще раза в месяц. В 2026 году инструменты вроде GitHub Actions, GitLab CI и ArgoCD стали стандартом де-факто, но настройка пайплайнов всё ещё требует глубокого понимания синтаксиса и best practices.

Промты (от англ. prompt — подсказка, инструкция) в контексте CI/CD — это шаблоны конфигураций, которые можно адаптировать под свои задачи. Я собрал 10 промтов для трёх популярных платформ: от простых «Hello World» до экспертных сценарiев с канареечным деплоем и интеграцией с Terraform. Каждый пример сопровождается пояснениями и ссылками на документацию.

1. Базовый промт для GitHub Actions: запуск тестов при пуше

Задача: Автоматически запускать тесты каждый раз, когда разработчик пушит в любую ветку.

name: Run tests
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
      - run: npm ci
      - run: npm test

Пояснение: Здесь on: [push] — триггер на любой пуш. actions/checkout клонирует репозиторий, setup-node настраивает окружение. npm ci — быстрая установка зависимостей из lock-файла.

Источник: GitHub Actions Documentation — Events that trigger workflows

2. Промт для GitLab CI: мульти-стадийный пайплайн

Задача: Собрать, протестировать и задеплоить приложение в три стадии.

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Building application..."
    - docker build -t myapp:$CI_COMMIT_SHORT_SHA .

test_job:
  stage: test
  script:
    - echo "Running tests..."
    - docker run myapp:$CI_COMMIT_SHORT_SHA npm test

deploy_job:
  stage: deploy
  script:
    - echo "Deploying to production..."
    - kubectl set image deployment/myapp myapp=myapp:$CI_COMMIT_SHORT_SHA
  only:
    - main

Пояснение: Каждая стадия выполняется последовательно. only: main ограничивает деплой только веткой main. Используется CI_COMMIT_SHORT_SHA — встроенная переменная GitLab.

Источник: GitLab CI/CD Pipeline Configuration Reference

3. Продвинутый промт для GitHub Actions: матрица тестов

Задача: Запускать тесты на нескольких версиях Node.js и ОС параллельно.

name: Matrix tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node-version: [16, 18, 20]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

Пояснение: Матрица генерирует 9 комбинаций (3 ОС × 3 версии). Это позволяет выловить платформозависимые баги. Важно: для больших проектов может быть дорого по минутам.

Источник: GitHub Actions — Using a matrix for your jobs

4. Промт для GitLab CI: кэширование зависимостей

Задача: Ускорить пайплайн за счёт кэширования node_modules.

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/

stages:
  - install
  - test

install_deps:
  stage: install
  script:
    - npm ci

test_app:
  stage: test
  script:
    - npm test

Пояснение: Кэш привязан к имени ветки (CI_COMMIT_REF_SLUG). Если dependencies не менялись, npm ci просто распакует кэш, экономя время.

Источник: GitLab CI — Caching in GitLab CI/CD

5. Экспертный промт для ArgoCD: декларативный деплой с Helm

Задача: Настроить ArgoCD для автоматической синхронизации приложения из Git-репозитория с помощью Helm-чарта.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/myorg/myapp.git'
    path: charts/myapp
    targetRevision: HEAD
    helm:
      valueFiles:
        - values-production.yaml
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Пояснение: ArgoCD — это GitOps-инструмент. Он следит за состоянием кластера и автоматически применяет изменения из Git. prune: true удаляет ресурсы, которых нет в Git. selfHeal восстанавливает желаемое состояние при ручных правках.

Источник: ArgoCD Documentation — Application Specification

6. Промт для GitHub Actions: канареечный деплой с Actions

Задача: Сначала выкатить новую версию на 10% трафика, проверить метрики, затем раскатить на 100%.

name: Canary deploy
on:
  push:
    branches:
      - main
jobs:
  canary:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy canary
        run: |
          kubectl set image deployment/myapp-canary myapp=myapp:${{ github.sha }}
          kubectl scale deployment/myapp-canary --replicas=1
      - name: Wait and check
        run: sleep 60
      - name: Promote to stable
        run: |
          kubectl set image deployment/myapp-stable myapp=myapp:${{ github.sha }}
          kubectl scale deployment/myapp-stable --replicas=10
          kubectl scale deployment/myapp-canary --replicas=0

Пояснение: Канареечный деплой снижает риски. Сначала обновляется canary-деплоймент с одним pod'ом. Через минуту (имитация проверки метрик) он промотируется до stable. В реальности вместо sleep используют HTTP-запросы к мониторингу.

Источник: GitHub Actions — Deploying to Kubernetes

7. Промт для GitLab CI: интеграция с SAST и линтингом

Задача: Добавить статический анализ безопасности (SAST) и линтинг Docker-образов.

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

stages:
  - test
  - build
  - security

docker_lint:
  stage: test
  image: hadolint/hadolint:latest
  script:
    - hadolint Dockerfile

Пояснение: GitLab предоставляет готовые шаблоны для SAST и Dependency Scanning. include подключает их. hadolint проверяет Dockerfile на best practices.

Источник: GitLab SAST documentation

8. Экспертный промт для ArgoCD: multi-cluster деплой

Задача: Развернуть приложение в нескольких кластерах Kubernetes (staging, production).

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

Пояснение: ApplicationSet генерирует отдельный Application для каждого кластера из списка. Это стандартный способ управления multi-cluster в ArgoCD. overlays/{{cluster}} — кастомные Kustomize-оверлеи для staging и production.

Источник: ArgoCD ApplicationSet — List Generator

9. Промт для GitHub Actions: автообновление версии и changelog

Задача: При мерже в main автоматически увеличивать версию, генерировать changelog и создавать релиз.

name: Release
on:
  pull_request:
    types:
      - closed
    branches:
      - main
jobs:
  release:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Bump version
        run: |
          git config user.name "github-actions"
          git config user.email "actions@github.com"
          npm version patch -m "chore: bump version to %s"
      - name: Generate changelog
        uses: conventional-changelog/action@v3
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          output-file: CHANGELOG.md
      - name: Create release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: v${{ steps.bump.outputs.new_version }}
          release_name: Release v${{ steps.bump.outputs.new_version }}
          body: ${{ steps.changelog.outputs.changelog }}

Пояснение: Работает только при мерже PR. npm version patch увеличивает patch-версию. conventional-changelog генерирует changelog на основе conventional commits. Релиз создаётся автоматически.

Источник: conventional-changelog/action on GitHub

10. Промт для GitLab CI: Terraform и инфраструктура

Задача: Запускать terraform plan на каждый MR и terraform apply при мерже.

stages:
  - validate
  - plan
  - apply

validate:
  stage: validate
  script:
    - terraform init
    - terraform validate

plan:
  stage: plan
  script:
    - terraform plan -out=plan.tfplan
  artifacts:
    paths:
      - plan.tfplan
  only:
    - merge_requests

apply:
  stage: apply
  script:
    - terraform apply plan.tfplan
  only:
    - main
  when: manual

Пояснение: terraform plan создаёт артефакт, который передаётся в apply. Apply запускается вручную (when: manual) и только с ветки main. Это защищает от случайного изменения инфраструктуры.

Источник: GitLab CI/CD with Terraform

Заключение

CI/CD — это не просто «запустить тесты». Это культура автоматизации, которая включает безопасность, инфраструктуру и управление релизами. Представленные промты покрывают 80% типовых сценариев: от базового тестирования до multi-cluster деплоя с ArgoCD.

Важно помнить: каждый пайплайн нужно адаптировать под конкретный проект. Начинайте с малого — добавьте линтер и тесты, затем постепенно усложняйте. И главное — документируйте свои пайплайны, чтобы через полгода не гадать, что делает тот или иной job.

Если вы хотите углубиться в тему CI/CD и DevOps, рекомендуем обратить внимание на специализированные ресурсы. ASI Biont поддерживает подключение к GitHub и GitLab через API — подробнее на asibiont.com/courses.