CI CD And Automation

CI/CD and Automation

Overview

Automate quality gates so that no change reaches production without passing tests, lint, type checking, and build. CI/CD is the enforcement mechanism for every other skill — it catches what humans and agents miss, and it does so consistently on every single change.

Shift Left: Catch problems as early in the pipeline as possible. A bug caught in linting costs minutes; the same bug caught in production costs hours. Move checks upstream — static analysis before tests, tests before staging, staging before production.

Faster is Safer: Smaller batches and more frequent releases reduce risk, not increase it. A deployment with 3 changes is easier to debug than one with 30. Frequent releases build confidence in the release process itself.

When to Use

• Setting up a new project's CI pipeline
• Adding or modifying automated checks
• Configuring deployment pipelines
• When a change should trigger automated verification
• Debugging CI failures

The Quality Gate Pipeline

Every change goes through these gates before merge:

Pull Request Opened
    │
    ▼
┌─────────────────┐
│   LINT CHECK     │  eslint, prettier
│   ↓ pass         │
│   TYPE CHECK     │  tsc --noEmit
│   ↓ pass         │
│   UNIT TESTS     │  jest/vitest
│   ↓ pass         │
│   BUILD          │  npm run build
│   ↓ pass         │
│   INTEGRATION    │  API/DB tests
│   ↓ pass         │
│   E2E (optional) │  Playwright/Cypress
│   ↓ pass         │
│   SECURITY AUDIT │  npm audit
│   ↓ pass         │
│   BUNDLE SIZE    │  bundlesize check
└─────────────────┘
    │
    ▼
  Ready for review

No gate can be skipped. If lint fails, fix lint — don't disable the rule. If a test fails, fix the code — don't skip the test.

GitHub Actions Configuration

Basic CI Pipeline

# .github/workflows/ci.yml
name: CI

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

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Type check
        run: npx tsc --noEmit

      - name: Test
        run: npm test -- --coverage

      - name: Build
        run: npm run build

      - name: Security audit
        run: npm audit --audit-level=high

With Database Integration Tests

  integration:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_DB: testdb
          POSTGRES_USER: ci_user
          POSTGRES_PASSWORD: ${{ secrets.CI_DB_PASSWORD }}
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - name: Run migrations
        run: npx prisma migrate deploy
        env:
          DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
      - name: Integration tests
        run: npm run test:integration
        env:
          DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb

Note: Even for CI-only test databases, use GitHub Secrets for credentials rather than hardcoding values. This builds good habits and prevents accidental reuse of test credentials in other contexts.

E2E Tests

  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - name: Install Playwright
        run: npx playwright install --with-deps chromium
      - name: Build
        run: npm run build
      - name: Run E2E tests
        run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

Feeding CI Failures Back to Agents

The power of CI with AI agents is the feedback loop. When CI fails:

CI fails
    │
    ▼
Copy the failure output
    │
    ▼
Feed it to the agent:
"The CI pipeline failed with this error:
[paste specific error]
Fix the issue and verify locally before pushing again."
    │
    ▼
Agent fixes → pushes → CI runs again

Key patterns:

Lint failure → Agent runs `npm run lint --fix` and commits
Type error  → Agent reads the error location and fixes the type
Test failure → Agent follows debugging-and-error-recovery skill
Build error → Agent checks config and dependencies

Deployment Strategies

Preview Deployments

Every PR gets a preview deployment for manual testing:

# Deploy preview on PR (Vercel/Netlify/etc.)
deploy-preview:
  runs-on: ubuntu-latest
  if: github.event_name == 'pull_request'
  steps:
    - uses: actions/checkout@v4
    - name: Deploy preview
      run: npx vercel --token=${{ secrets.VERCEL_TOKEN }}

Feature Flags

Feature flags decouple deployment from release. Deploy incomplete or risky features behind flags so you can:

• Ship code without enabling it. Merge to main early, enable when ready.
• Roll back without redeploying. Disable the flag instead of reverting code.
• Canary new features. Enable for 1% of users, then 10%, then 100%.
• Run A/B tests. Compare behavior with and without the feature.

// Simple feature flag pattern
if (featureFlags.isEnabled('new-checkout-flow', { userId })) {
  return renderNewCheckout();
}
return renderLegacyCheckout();

Flag lifecycle: Create → Enable for testing → Canary → Full rollout → Remove the flag and dead code. Flags that live forever become technical debt — set a cleanup date when you create them.

Staged Rollouts

PR merged to main
    │
    ▼
  Staging deployment (auto)
    │ Manual verification
    ▼
  Production deployment (manual trigger or auto after staging)
    │
    ▼
  Monitor for errors (15-minute window)
    │
    ├── Errors detected → Rollback
    └── Clean → Done

Rollback Plan

Every deployment should be reversible:

# Manual rollback workflow
name: Rollback
on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Version to rollback to'
        required: true

jobs:
  rollback:
    runs-on: ubuntu-latest
    steps:
      - name: Rollback deployment
        run: |
          # Deploy the specified previous version
          npx vercel rollback ${{ inputs.version }}

Environment Management

.env.example       → Committed (template for developers)
.env                → NOT committed (local development)
.env.test           → Committed (test environment, no real secrets)
CI secrets          → Stored in GitHub Secrets / vault
Production secrets  → Stored in deployment platform / vault

CI should never have production secrets. Use separate secrets for CI testing.

Automation Beyond CI

Dependabot / Renovate

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    open-pull-requests-limit: 5

Build Cop Role

Designate someone responsible for keeping CI green. When the build breaks, the Build Cop's job is to fix or revert — not the person whose change caused the break. This prevents broken builds from accumulating while everyone assumes someone else will fix it.

PR Checks

• Required reviews: At least 1 approval before merge
• Required status checks: CI must pass before merge
• Branch protection: No force-pushes to main
• Auto-merge: If all checks pass and approved, merge automatically

CI Optimization

When the pipeline exceeds 10 minutes, apply these strategies in order of impact:

Slow CI pipeline?
├── Cache dependencies
│   └── Use actions/cache or setup-node cache option for node_modules
├── Run jobs in parallel
│   └── Split lint, typecheck, test, build into separate parallel jobs
├── Only run what changed
│   └── Use path filters to skip unrelated jobs (e.g., skip e2e for docs-only PRs)
├── Use matrix builds
│   └── Shard test suites across multiple runners
├── Optimize the test suite
│   └── Remove slow tests from the critical path, run them on a schedule instead
└── Use larger runners
    └── GitHub-hosted larger runners or self-hosted for CPU-heavy builds

Example: caching and parallelism

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '22', cache: 'npm' }
      - run: npm ci
      - run: npm run lint

  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '22', cache: 'npm' }
      - run: npm ci
      - run: npx tsc --noEmit

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '22', cache: 'npm' }
      - run: npm ci
      - run: npm test -- --coverage

Common Rationalizations

Red Flags

• No CI pipeline in the project
• CI failures ignored or silenced
• Tests disabled in CI to make the pipeline pass
• Production deploys without staging verification
• No rollback mechanism
• Secrets stored in code or CI config files (not secrets manager)
• Long CI times with no optimization effort

RPA and Scheduled Automation

Beyond CI/CD pipelines, automate repetitive business processes with scheduled tasks and robotic process automation (RPA).

Scheduled Tasks (Cron / Scheduler)

Use for periodic data processing, report generation, and system maintenance:

# scheduler.py — Task scheduling framework
import schedule
import time
from datetime import datetime

class TaskScheduler:
    def __init__(self):
        self.jobs = []
    
    def add_daily(self, task_func, hour=9, minute=0):
        """Add daily recurring task"""
        job = schedule.every().day.at(f"{hour:02d}:{minute:02d}").do(task_func)
        self.jobs.append(job)
        return job
    
    def add_weekly(self, task_func, day_of_week='monday', hour=9):
        """Add weekly recurring task"""
        day_map = {
            'monday': schedule.every().monday,
            'tuesday': schedule.every().tuesday,
            'wednesday': schedule.every().wednesday,
            'thursday': schedule.every().thursday,
            'friday': schedule.every().friday,
        }
        job = day_map[day_of_week].at(f"{hour:02d}:00").do(task_func)
        self.jobs.append(job)
        return job
    
    def run_pending(self):
        """Check and run pending jobs"""
        schedule.run_pending()
    
    def run_continuously(self, interval=60):
        """Run scheduler loop"""
        while True:
            self.run_pending()
            time.sleep(interval)

# Usage example
def generate_daily_report():
    """Generate daily financial report"""
    print(f"[{datetime.now()}] Generating daily report...")
    # Call data-analysis skill
    # Save to data-analysis-local/daily-report-<YYYYMMDD>/

scheduler = TaskScheduler()
scheduler.add_daily(generate_daily_report, hour=8, minute=30)
# scheduler.run_continuously()

Data Synchronization Pipeline

Automate data extraction, transformation, and loading (ETL):

# etl_pipeline.py
class DataSyncPipeline:
    """
    Automated data synchronization pipeline
    Stages: Extract → Transform → Validate → Load → Notify
    """
    
    def extract(self, source: str, query: str = None):
        """Extract data from source (DB, API, file)"""
        pass
    
    def transform(self, data, rules: list):
        """Apply transformation rules (cleaning, aggregation)"""
        pass
    
    def validate(self, data, schema: dict):
        """Validate data against schema"""
        pass
    
    def load(self, data, destination: str):
        """Load data to destination (DB, file, API)"""
        pass
    
    def notify(self, status: str, details: dict):
        """Send notification (Feishu, email, log)"""
        pass
    
    def run(self, config: dict):
        """Execute full pipeline"""
        try:
            data = self.extract(config['source'], config.get('query'))
            data = self.transform(data, config.get('rules', []))
            self.validate(data, config.get('schema', {}))
            self.load(data, config['destination'])
            self.notify('success', {'records': len(data)})
        except Exception as e:
            self.notify('failure', {'error': str(e)})
            raise

Automated Report Generation

Generate periodic reports with data analysis skills:

# report_generator.py
class AutomatedReport:
    """
    Automated report generation
    - Fetch data using sql-generation skill
    - Analyze using data-analysis skill
    - Generate charts and markdown report
    - Sync to Obsidian Vault
    """
    
    def __init__(self, topic: str, output_dir: str):
        self.topic = topic
        self.output_dir = output_dir
        self.date_str = datetime.now().strftime('%Y%m%d')
    
    def create_task_directory(self):
        """Create <topic>-<YYYYMMDD> structure"""
        task_dir = f"{self.output_dir}/{self.topic}-{self.date_str}"
        os.makedirs(f"{task_dir}/raw", exist_ok=True)
        os.makedirs(f"{task_dir}/charts", exist_ok=True)
        return task_dir
    
    def generate(self, sql_queries: list, analysis_config: dict):
        """
        Generate complete analysis report
        1. Execute SQL queries (sql-generation skill)
        2. Run analysis (data-analysis skill)
        3. Generate charts
        4. Write markdown report
        5. Sync to Obsidian
        """
        task_dir = self.create_task_directory()
        
        # Step 1: Extract data
        raw_data = []
        for query in sql_queries:
            # Execute via sql-generation skill
            raw_data.append(self.execute_sql(query))
        
        # Step 2: Analyze
        analysis_result = self.run_analysis(raw_data, analysis_config)
        
        # Step 3: Generate charts
        charts = self.generate_charts(analysis_result)
        
        # Step 4: Write report
        report_path = f"{task_dir}/report_{self.date_str}.md"
        self.write_report(report_path, analysis_result, charts)
        
        # Step 5: Sync to Obsidian
        self.sync_to_obsidian(report_path)
        
        return report_path

RPA Implementation Patterns

RPA Task Checklist

When implementing RPA automation:

• Define trigger (schedule / event / file watch / API webhook)
• Define input source (DB / API / file / message queue)
• Define transformation rules (cleaning, aggregation, enrichment)
• Define validation rules (schema, range, referential integrity)
• Define output destination (DB / file / API / notification)
• Define error handling (retry, fallback, alert)
• Define monitoring (success rate, latency, data quality)
• Test in staging before production deployment
• Document in data-analysis-local/<topic>-<YYYYMMDD>/report_*.md

Verification

After setting up or modifying CI:

• All quality gates are present (lint, types, tests, build, audit)
• Pipeline runs on every PR and push to main
• Failures block merge (branch protection configured)
• CI results feed back into the development loop
• Secrets are stored in the secrets manager, not in code
• Deployment has a rollback mechanism
• Pipeline runs in under 10 minutes for the test suite

Source: yangwei2603/Claude-code — distributed by TomeVault.