Skip to content
Santekno.com | Level Up Your Engineering Skills
ID
📖 0%
08 Oct 2026 · 22 mnt baca ·Artikel 62 / 208
Go

Arsitektur CI/CD Pipeline AI-Assisted untuk Golang: Blueprint Lengkap

Blueprint arsitektur pipeline AI-assisted untuk Go service. Layer-by-layer design: syntactic, semantic, AI review, spec compliance — dengan GitHub Actions workflow yang production-ready.

IH
Ihsan Arif
Penulis di Santekno · Backend Engineer

Sebelum menulis satu baris YAML pipeline, kita perlu blueprint yang jelas untuk arsitektur CI/CD AI golang yang akan dibangun. Pipeline yang dibangun tanpa arsitektur yang well-thought-out berakhir menjadi kumpulan steps yang susah di-maintain, terlalu lambat, atau terlalu banyak false positive.

Artikel ini adalah architecture session — kita akan design pipeline dari atas ke bawah sebelum implementasi.


02.1 Prinsip Desain Pipeline Kita

Sebelum masuk ke diagram, ada tiga prinsip yang akan guide semua keputusan arsitektur di Topik 4. Ketiga prinsip berikut — fail fast, parallel, dan graduated enforcement — menjadi acuan setiap trade-off yang kita ambil nanti.

text
 1PRINSIP 1: FAIL FAST, FAIL CHEAP
 2  Step yang paling cepat dan paling sering fail harus dijalankan pertama.
 3
 4  Order: build → test → lint → architecture → AI review → spec audit
 5
 6  Rationale:
 7  - Build fail: paling sering, paling cepat (30 detik)
 8  - Test fail: sering, 2-5 menit
 9  - AI review: jarang block, 2 menit (tapi mahal relatif)
10  - Spec audit: jarang dijalankan, 1 menit
11
12  Jangan: jalankan spec audit sebelum test — sia-sia kalau test fail
13
14PRINSIP 2: PARALLEL WHERE POSSIBLE
15  Steps yang tidak saling dependent harus parallel.
16
17  Parallel group A (blocking):
18    go build, go test, golangci-lint, architecture-check
19
20  Parallel group B (informational, non-blocking awal):
21    AI review, PR description generation
22
23  Total wall time: max(group A) + security-scan
24  Bukan: sum semua steps
25
26PRINSIP 3: GRADUATED ENFORCEMENT
27  Bukan semua failure harus block merge dari hari pertama.
28
29  Level 1 (blocking dari hari pertama):
30    Build fail, test fail, critical security vulnerability
31
32  Level 2 (blocking setelah 2 sprint):
33    AI review CRITICAL issues, architecture violations
34
35  Level 3 (informational always):
36    AI review SUGGESTION, PR description quality

Kalau harus dipilih satu yang paling sering dilanggar orang, itu adalah prinsip 1: jangan pernah membakar token AI untuk me-review kode yang tesnya saja belum lulus.


02.2 Layer Architecture: 4 Layer, 1 Pipeline

Pipeline kita disusun berlapis, dari yang paling murah dan deterministik sampai yang paling mahal dan semantik. Diagram layer berikut menunjukkan keempat lapisan itu beserta waktu dan status blocking masing-masing.

text
 1┌─────────────────────────────────────────────────────────────┐
 2│  LAYER 1: SYNTACTIC (Deterministik, Zero AI Cost)           │
 3│  go build | go test -race | go vet | golangci-lint          │
 4│  Waktu: 2-5 menit | Blocking: YES dari day 1                │
 5├─────────────────────────────────────────────────────────────┤
 6│  LAYER 2: SEMANTIC-STATIC (Custom Script, Zero AI Cost)     │
 7│  Architecture boundary | Import graph | Naming convention   │
 8│  Waktu: 30 detik | Blocking: YES (sprint 2+)                │
 9├─────────────────────────────────────────────────────────────┤
10│  LAYER 3: SEMANTIC-AI (LLM-Powered, Low Cost)               │
11│  Copilot PR review | Claude error pattern check             │
12│  Waktu: 2 menit (parallel) | Blocking: CRITICAL only        │
13├─────────────────────────────────────────────────────────────┤
14│  LAYER 4: SPEC COMPLIANCE (Spec Kit, Optional)              │
15│  specify audit | AC coverage | Contract validation          │
16│  Waktu: 1 menit | Blocking: jika score < 80                 │
17└─────────────────────────────────────────────────────────────┘

Perhatikan bahwa hanya dua layer teratas yang bebas biaya AI — inilah alasan mayoritas beban validasi sengaja ditaruh di Layer 1 dan 2, dan AI hanya menangani apa yang tidak bisa ditangkap secara statis.


02.3 Full Pipeline Diagram

Setelah memahami layer secara konseptual, mari lihat bagaimana semuanya tersambung dalam satu alur eksekusi. Diagram lengkap berikut menampilkan trigger strategy, urutan layer, dan titik-titik blocking beserta gerbang parallel-nya.

flowchart TD
    Push[Git Push / PR Open] --> Trigger

    subgraph Trigger["Trigger Strategy"]
        direction LR
        T1[push to main/develop] -->|full pipeline| Pipeline
        T2[PR opened/updated] -->|full pipeline + AI review| Pipeline
        T3[push to feature branch] -->|Layer 1 only| L1
    end

    subgraph L1["Layer 1: Syntactic"]
        direction LR
        Build[go build ./...] --> Test[go test -race -count=1 ./...]
        Test --> Vet[go vet ./...]
        Vet --> Lint[golangci-lint]
        Lint --> SecScan[gosec + gitleaks]
    end

    subgraph L2["Layer 2: Semantic-Static"]
        Arch[architecture-check.go]
        DepCheck[dependency guard]
    end

    subgraph L3["Layer 3: Semantic-AI (parallel)"]
        direction LR
        CopilotReview[Copilot PR Review]
        PRDesc[PR Description Generator]
        FailureAnalysis[Test Failure Analysis]
    end

    subgraph L4["Layer 4: Spec Compliance"]
        SpecAudit[specify audit]
    end

    Pipeline --> L1
    L1 -->|PASS| L2
    L1 -->|FAIL| BlockL1[❌ Block: Fix Build/Test/Lint]
    L2 -->|PASS| ParallelGate
    L2 -->|FAIL| BlockL2[⚠️ Block: Fix Architecture]

    ParallelGate --> L3
    ParallelGate --> L4

    L3 -->|CRITICAL| BlockL3[⚠️ Block: Fix Critical AI Issues]
    L3 -->|OK/SUGGESTION| PassL3[✅ AI Review Passed]

    L4 -->|score < 80| BlockL4[⚠️ Block: Spec Non-Compliant]
    L4 -->|score >= 80| PassL4[✅ Spec Compliant]

    PassL3 --> Merge
    PassL4 --> Merge
    BlockL3 -.->|after fix| Merge
    BlockL4 -.->|after fix| Merge
    Merge[✅ Ready to Merge]

    style L3 fill:#e8f4ff,stroke:#4a90d9
    style L4 fill:#e8f4ff,stroke:#4a90d9
    style CopilotReview fill:#dceeff,stroke:#4a90d9
    style PRDesc fill:#dceeff,stroke:#4a90d9
    style SpecAudit fill:#dceeff,stroke:#4a90d9

Diagram: Full AI-augmented pipeline — blue nodes adalah AI-powered steps

Poin terpenting dari diagram ini: L3 dan L4 bercabang dari titik yang sama (ParallelGate) setelah L1+L2 lulus, sehingga keduanya berjalan bersamaan dan menghemat wall time.


02.4 GitHub Actions Job Structure

Diagram di atas perlu diterjemahkan menjadi jobs yang actual di GitHub Actions. Workflow berikut adalah struktur penuh keempat layer, dari trigger hingga job spec-audit — perhatikan bagaimana needs mengatur urutan dan if membatasi kapan job jalan.

yaml
  1# .github/workflows/ci.yml — Full Structure
  2
  3name: CI — AI-Assisted Quality Pipeline
  4on:
  5  push:
  6    branches: [main, develop]
  7  pull_request:
  8    branches: [main, develop]
  9    types: [opened, synchronize, ready_for_review]
 10
 11# Satu env block untuk semua jobs
 12env:
 13  GO_VERSION: '1.22'
 14
 15jobs:
 16  # ============================================================
 17  # LAYER 1: SYNTACTIC — Always runs, blocks everything
 18  # ============================================================
 19
 20  syntactic:
 21    name: "L1: Build, Test & Lint"
 22    runs-on: ubuntu-latest
 23    outputs:
 24      status: ${{ job.status }}
 25    steps:
 26      - uses: actions/checkout@v4
 27      - uses: actions/setup-go@v5
 28        with: { go-version: '${{ env.GO_VERSION }}', cache: true }
 29      - name: Build
 30        run: go build ./...
 31      - name: Test
 32        run: go test -race -count=1 -timeout=5m ./...
 33      - name: Coverage gate
 34        run: |
 35          go test -coverprofile=cov.out ./...
 36          COVERAGE=$(go tool cover -func=cov.out | grep total | awk '{print $3}' | tr -d '%')
 37          echo "Coverage: ${COVERAGE}%"
 38          awk "BEGIN {exit ($COVERAGE >= 70) ? 0 : 1}" || \
 39            { echo "❌ Coverage below 70%"; exit 1; }
 40      - name: Vet
 41        run: go vet ./...
 42      - name: Lint
 43        uses: golangci/golangci-lint-action@v6
 44      - name: Security scan
 45        run: |
 46          go install github.com/securego/gosec/v2/cmd/gosec@latest
 47          gosec -severity medium -no-fail ./...
 48
 49  # ============================================================
 50  # LAYER 2: SEMANTIC-STATIC — Runs after L1, blocks merge
 51  # ============================================================
 52
 53  architecture:
 54    name: "L2: Architecture Boundary Check"
 55    runs-on: ubuntu-latest
 56    needs: syntactic
 57    steps:
 58      - uses: actions/checkout@v4
 59      - uses: actions/setup-go@v5
 60        with: { go-version: '${{ env.GO_VERSION }}' }
 61      - name: Check layer boundaries
 62        run: go run ./scripts/check-architecture.go ./...
 63      - name: Check dependency guard
 64        run: |
 65          # Ensure no cross-service internal imports
 66          go run ./scripts/check-monorepo-boundaries.go ./...
 67
 68  # ============================================================
 69  # LAYER 3: SEMANTIC-AI — Parallel with L4, PR only
 70  # ============================================================
 71
 72  ai-review:
 73    name: "L3: AI Semantic Review"
 74    runs-on: ubuntu-latest
 75    needs: syntactic          # hanya jalan setelah L1 pass
 76    if: |
 77      github.event_name == 'pull_request' &&
 78      !github.event.pull_request.draft
 79    permissions:
 80      pull-requests: write
 81      contents: read
 82    steps:
 83      - uses: actions/checkout@v4
 84        with: { fetch-depth: 0 }
 85      - name: Copilot PR Review
 86        uses: github/copilot-for-pull-requests@v1
 87        with:
 88          github-token: ${{ secrets.GITHUB_TOKEN }}
 89          review-instructions: |
 90            Review Go code per CLAUDE.md rules.
 91            CRITICAL (block): error not wrapped, float64 for money,
 92            architecture violations, _ ignoring errors.
 93            End with REVIEW_SCORE: X/100
 94
 95  pr-enrichment:
 96    name: "L3: PR Description & Metadata"
 97    runs-on: ubuntu-latest
 98    needs: syntactic
 99    if: |
100      github.event_name == 'pull_request' &&
101      github.event.action == 'opened'
102    permissions:
103      pull-requests: write
104      contents: read
105    env:
106      ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
107    steps:
108      - uses: actions/checkout@v4
109        with: { fetch-depth: 0 }
110      - name: Generate PR description
111        uses: actions/github-script@v7
112        with:
113          script: |
114            // Auto-generate PR description (detail di Artikel 10)
115            console.log('PR description generation — see Article 10');
116
117  # ============================================================
118  # LAYER 4: SPEC COMPLIANCE — Parallel with L3, PR only
119  # ============================================================
120
121  spec-audit:
122    name: "L4: Spec Compliance Audit"
123    runs-on: ubuntu-latest
124    needs: syntactic
125    if: |
126      github.event_name == 'pull_request' &&
127      !github.event.pull_request.draft
128    steps:
129      - uses: actions/checkout@v4
130      - uses: actions/setup-node@v4
131        with: { node-version: '20' }
132      - name: Install specify CLI
133        run: npm install -g @santekno/spec-kit
134      - name: Run spec audit
135        run: specify audit --fail-on-score-below 80

Kunci membaca workflow ini: ai-review dan spec-audit sama-sama needs: syntactic (bukan needs: architecture), sehingga keduanya jalan paralel setelah Layer 1 lulus — persis seperti gerbang paralel di diagram sebelumnya.


02.5 Trigger Strategy: Kapan Apa Dijalankan

Tidak semua pipeline perlu dijalankan di semua events; trigger yang salah menghasilkan pipeline yang lambat dan mahal. Rincian berikut memetakan setiap event ke layer mana yang dijalankan dan estimasi waktunya.

text
 1Tidak semua pipeline perlu dijalankan di semua events.
 2Trigger yang salah = pipeline yang lambat dan mahal.
 3
 4EVENT: push ke feature branch
 5  Tujuan: fast feedback untuk developer yang sedang coding
 6  Run: Layer 1 only (build + test + lint)
 7  Tidak run: AI review (tidak ada PR), spec audit
 8  Waktu: 3-5 menit
 9
10EVENT: PR opened atau synchronize (commit baru ke PR)
11  Tujuan: quality gate sebelum code review
12  Run: Layer 1 + 2 + 3 + 4
13  Waktu: 7 menit (L1+L2 sequential, L3+L4 parallel)
14
15EVENT: push ke main atau develop
16  Tujuan: verify post-merge health
17  Run: Layer 1 + 2 (L3 dan L4 tidak relevan — PR sudah di-review)
18  Waktu: 5 menit
19
20EVENT: PR marked ready_for_review (dari draft)
21  Tujuan: run full pipeline untuk PR yang baru ready
22  Run: Layer 1 + 2 + 3 + 4 (full)
23  Waktu: 7 menit
24
25EVENT: schedule (nightly)
26  Tujuan: full health check + dependency update check
27  Run: Layer 1 + security deep scan
28  Waktu: 10 menit (comprehensive scan)

Prinsip yang bisa diambil: event push ke feature branch cukup Layer 1 untuk feedback cepat, sedangkan pipeline penuh dengan AI hanya perlu jalan saat ada PR yang benar-benar akan di-review.


02.6 Cost Architecture: Estimasi Biaya per Event

Sebelum meng-enable pipeline, ada baiknya kita hitung biayanya agar tidak ada kejutan di tagihan bulanan. Breakdown berikut menjumlahkan biaya per layer sampai estimasi bulanan untuk tim 8 developer.

text
 1Biaya per pipeline run:
 2
 3Layer 1 (no AI cost):
 4  GitHub Actions: ~$0.002 (ubuntu runner, 5 menit)
 5  Total L1: $0.002
 6
 7Layer 2 (no AI cost):
 8  GitHub Actions: ~$0.001 (30 detik)
 9  Total L2: $0.001
10
11Layer 3 (AI cost):
12  Copilot PR review: sudah included di subscription
13  Claude PR description: ~500 tokens input, ~200 output
14    Cost: (500 × $0.80 + 200 × $4.00) / 1,000,000 = $0.0012
15  GitHub Actions: ~$0.001
16  Total L3: ~$0.002
17
18Layer 4 (no AI cost):
19  specify CLI: gratis
20  GitHub Actions: ~$0.001
21  Total L4: $0.001
22
23TOTAL per full pipeline run: ~$0.006
24
25Monthly estimate (24 PRs/week × 4 minggu = 96 PRs/bulan):
26  96 × $0.006 = $0.58/bulan
27  Plus GitHub Actions compute: ~$2/bulan
28
29  TOTAL: ~$2.60/bulan untuk tim 8 developer
30  (di luar Copilot subscription yang sudah ada)

Angka ~$2.60/bulan ini praktis tidak berarti dibandingkan waktu engineer yang dihemat — biaya bukanlah faktor pembatas dalam keputusan mengadopsi pipeline ini.


02.7 Repository Structure untuk Pipeline

Pipeline butuh dukungan struktur repository yang rapi agar setiap script dan config mudah ditemukan. Struktur direktori berikut menunjukkan di mana workflow, script, dan file konfigurasi ditempatkan.

text
 1santekno-shop/
 2├── .github/
 3│   ├── workflows/
 4│   │   ├── ci.yml              ← main pipeline (artikel ini)
 5│   │   ├── release.yml         ← release notes generator (artikel 11)
 6│   │   └── nightly.yml         ← scheduled security scan
 7│   ├── copilot-instructions.md ← AI review context
 8│   └── pull_request_template.md
 9├── scripts/
10│   ├── check-architecture.go   ← dari Topik 3
11│   ├── check-monorepo-boundaries.go
12│   └── review-bot/
13│       └── main.go             ← custom AI review (artikel 5)
14├── CLAUDE.md                   ← universal context
15├── .golangci.yml               ← lint configuration
16├── .gitleaks.toml              ← secret scan rules
17└── go.work                     ← workspace (jika monorepo)

Perhatikan bahwa semua file pendukung — CLAUDE.md, config lint, script arsitektur — hidup di dalam repo yang sama, sehingga pipeline dan aturannya ter-version bersama kode.


02.8 .golangci.yml yang Comprehensive

Layer 1 hanya sekuat konfigurasi linter-nya. Konfigurasi .golangci.yml berikut adalah yang kita pakai di Santekno Shop — mengaktifkan linter untuk correctness, idiom, performa, keamanan, sampai aturan import kustom.

yaml
 1# .golangci.yml — konfigurasi untuk Santekno Shop
 2
 3run:
 4  timeout: 5m
 5  go: '1.22'
 6  tests: true
 7
 8linters:
 9  enable:
10    # Core correctness
11    - errcheck          # check error yang tidak di-handle
12    - govet             # suspicious constructs
13    - staticcheck       # comprehensive static analysis
14    - unused            # unused code
15
16    # Go idioms
17    - gofmt             # formatting
18    - goimports         # import ordering
19    - misspell          # typo
20
21    # Performance
22    - prealloc          # slice preallocation
23    - bodyclose         # HTTP response body close check
24
25    # Security
26    - gosec             # security issues
27    - exhaustive        # switch exhaustiveness
28
29    # Custom rules
30    - depguard          # forbidden import paths
31    - gomodguard        # module usage rules
32
33linters-settings:
34  depguard:
35    rules:
36      main:
37        deny:
38          # Pastikan tidak ada cross-service internal import
39          - pkg: "github.com/santekno/santekno-shop/services/*/internal"
40            desc: "Cross-service internal imports forbidden. Use Kafka events."
41          # Pastikan tidak ada deprecated mock library
42          - pkg: "github.com/golang/mock"
43            desc: "Use go.uber.org/mock instead"
44
45  errcheck:
46    check-type-assertions: true
47    check-blank: true
48
49  govet:
50    enable-all: true
51
52issues:
53  exclude-rules:
54    # Test files boleh ignore errors
55    - path: _test\.go
56      linters: [errcheck]
57    # Generated files dikecualikan
58    - path: ".*\\.pb\\.go"
59      linters: [all]
60    - path: ".*mock.*\\.go"
61      linters: [all]
62
63  max-issues-per-linter: 50
64  max-same-issues: 3

Bagian depguard adalah yang paling bernilai di sini: ia menegakkan boundary arsitektur (larangan cross-service internal import) secara deterministik tanpa biaya AI sepeser pun.


02.9 Secrets Management di CI

Pipeline yang memanggil API eksternal butuh secrets yang dikelola dengan aman. Blok berikut merangkum secret apa saja yang diperlukan, cara set-nya via GitHub CLI, dan praktik terbaik pengelolaannya.

bash
 1# GitHub Secrets yang perlu di-setup:
 2
 3# Required untuk AI review via Claude API:
 4ANTHROPIC_API_KEY      # dari console.anthropic.com
 5
 6# Required untuk secret scanning:
 7# (tidak ada — gitleaks dan trufflehog tidak butuh secret)
 8
 9# Optional untuk extended features:
10SLACK_WEBHOOK          # untuk notifikasi deployment
11SONAR_TOKEN            # jika pakai SonarQube
12
13# Setup via GitHub CLI:
14gh secret set ANTHROPIC_API_KEY --body "sk-ant-xxx"
15gh secret set SLACK_WEBHOOK --body "https://hooks.slack.com/xxx"
16
17# Verify:
18gh secret list
19
20# Security best practices untuk secrets di CI:
21# 1. Minimal permissions — API key hanya untuk yang diperlukan
22# 2. Rotation schedule — rotate setiap 90 hari
23# 3. Environment scoping — production secrets hanya di production env
24# 4. Audit logs — monitor usage di Anthropic console
25
26# Environment protection (untuk production secrets):
27# GitHub → Settings → Environments → production → Protection rules
28# Required reviewers: [tech lead]
29# Restrict to protected branches: main only

Intinya, hanya ANTHROPIC_API_KEY yang benar-benar wajib; secret scanning tidak butuh kredensial sama sekali — dan environment protection adalah lapisan tambahan untuk memisahkan secret production dari branch lain.


02.10 Caching Strategy untuk Speed

Waktu pipeline sebagian besar dihabiskan untuk mengunduh dependency dan build ulang — caching memangkas keduanya. Konfigurasi berikut menunjukkan empat lapis cache dan estimasi waktu yang dihemat masing-masing.

yaml
 1# Cache yang significant untuk Go pipeline:
 2
 3# 1. Go module cache (paling impactful, 30-60 detik saved)
 4- uses: actions/setup-go@v5
 5  with:
 6    go-version: '1.22'
 7    cache: true          # ini saja sudah cache go modules
 8
 9# 2. golangci-lint cache (10-20 detik saved)
10- uses: golangci/golangci-lint-action@v6
11  with:
12    # Cache sudah built-in di action ini
13
14# 3. Build cache untuk custom scripts
15- uses: actions/cache@v4
16  with:
17    path: |
18      ~/.cache/go-build
19      ~/go/pkg/mod
20    key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}
21    restore-keys: |
22      ${{ runner.os }}-go-
23
24# 4. Node modules untuk specify CLI
25- uses: actions/cache@v4
26  with:
27    path: ~/.npm
28    key: ${{ runner.os }}-npm-specify-${{ hashFiles('package-lock.json') }}
29
30# Expected cache hit improvement:
31# Cold run (no cache): 8-12 menit
32# Warm run (cache hit): 3-5 menit
33# Savings: ~60% pipeline time

Dengan caching yang benar, warm run turun dari 8-12 menit ke 3-5 menit — penghematan ~60% yang langsung terasa oleh developer setiap kali push.


02.11 Notification dan Feedback Loop

Notifikasi yang berlebihan justru membuat tim mengabaikan alert. Pola notifikasi berikut sengaja hemat — hanya memberi tahu saat benar-benar perlu, dengan contoh workflow Slack untuk kegagalan di branch main.

yaml
 1# Notifikasi yang useful (tidak overwhelming):
 2
 3# Pattern yang disarankan:
 4# - SUCCESS: tidak perlu notifikasi (developer tidak perlu distract)
 5# - FAILURE di main: notif ke Slack channel #engineering-alerts
 6# - FAILURE di PR: GitHub comment (auto dari Actions)
 7# - WEEKLY summary: digest di Slack #engineering
 8
 9# Workflow untuk Slack notification saat main fail:
10- name: Notify on main branch failure
11  if: failure() && github.ref == 'refs/heads/main'
12  uses: 8398a7/action-slack@v3
13  with:
14    status: failure
15    fields: repo,message,commit,author,workflow
16    text: ':red_circle: Main branch CI failed! Check immediately.'
17  env:
18    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}
19
20# GitHub comment untuk PR failure (built-in dari Actions):
21# Ketika job fail, GitHub otomatis show di PR checks tab
22# Developer langsung lihat apa yang fail tanpa perlu Slack

Prinsipnya sederhana: makin sedikit notifikasi, makin tinggi perhatian per notifikasi — jangan latih tim untuk mengabaikan alert dengan membanjiri mereka pesan sukses.


02.12 Measuring Pipeline Health

Pipeline perlu dimonitor sama seperti service production. Kumpulan perintah gh dan jq berikut menghitung tiga metrik kesehatan pipeline langsung dari GitHub Actions API.

bash
 1# Dashboard metrics yang perlu di-track:
 2
 3# 1. Pipeline success rate (target: > 95%)
 4# Via GitHub Actions API:
 5gh run list --workflow=ci.yml --json conclusion \
 6  | jq '[.[] | select(.conclusion != null)] | {
 7      total: length,
 8      success: [.[] | select(.conclusion == "success")] | length
 9    } | .success / .total * 100 | floor'
10
11# 2. Average pipeline duration (target: < 10 menit)
12gh run list --workflow=ci.yml --json createdAt,updatedAt \
13  | jq '[.[] | ((.updatedAt | fromdateiso8601) - (.createdAt | fromdateiso8601))] | add / length / 60'
14
15# 3. Most common failure reason
16gh run list --workflow=ci.yml --status failure --json jobs \
17  | jq '[.[].jobs[] | select(.conclusion == "failure") | .name] | group_by(.) | map({job: .[0], count: length}) | sort_by(-.count) | .[0:5]'
18
19# Simpan metrics mingguan:
20# Spreadsheet atau Grafana dashboard
21# Review di sprint retrospective

Metrik “most common failure reason” adalah yang paling actionable: kalau satu job mendominasi kegagalan, di situlah usaha tuning kamu harus difokuskan.


02.13 Blue/Green Pipeline Rollout

Mengganti pipeline yang aktif berisiko mengganggu development jika dilakukan sekaligus. Strategi rollout tiga fase berikut memperkenalkan pipeline baru secara bertahap — dari shadow mode sampai enforcement penuh.

text
 1Cara rollout pipeline baru tanpa disrupt development:
 2
 3PHASE 1 (Week 1): Shadow mode
 4  Pipeline baru berjalan parallel dengan pipeline lama
 5  Hasilnya hanya di-log, tidak block merge
 6  Tujuan: validate false positive rate
 7
 8PHASE 2 (Week 2-3): Warning mode
 9  Pipeline baru replace pipeline lama
10  Failures menjadi GitHub comments (tidak block)
11  Developer bisa lihat tapi tidak di-block
12  Tujuan: developer familiar dengan output format
13
14PHASE 3 (Week 4+): Enforcement mode
15  CRITICAL issues block merge
16  SUGGESTION tetap informational
17  Monitor: ada yang complain false positive?
18
19Cara implement shadow mode:
20  continue-on-error: true  # pada semua AI-related steps
21
22  # Setelah shadow period:
23  # Remove continue-on-error dari CRITICAL checks

Kunci teknis rollout ini ada pada continue-on-error: true: flag inilah yang membuat pipeline baru bisa “mengintip” tanpa memblokir siapa pun selama fase shadow dan warning.


02.14 Pipeline as Code: Versioning dan Review

Pipeline YAML adalah code, dan harus diperlakukan seperti code. Lima praktik berikut menegakkan disiplin itu — dari review via PR sampai rollback plan dengan git tag.

text
 1Pipeline YAML adalah code — perlu diperlakukan seperti code:
 2
 31. PR untuk pipeline changes
 4   Perubahan ke .github/workflows/*.yml harus via PR
 5   Bukan langsung push ke main
 6
 72. Review oleh senior developer
 8   Pipeline affect semua developer — perlu careful review
 9
103. Testing di branch sebelum merge
11   Feature branch: buat perubahan pipeline
12   Test: push beberapa commits, verify pipeline behavior
13   Merge: setelah confirmed working
14
154. CHANGELOG untuk pipeline
16   Simpan changelog di .github/PIPELINE_CHANGELOG.md
17   Dokumentasikan setiap perubahan signifikan
18
195. Rollback plan
20   Tag pipeline state sebelum perubahan besar:
21   git tag pipeline-v1.0 (sebelum AI review ditambahkan)
22   git tag pipeline-v2.0 (setelah AI review)
23
24   Rollback: git checkout pipeline-v1.0 -- .github/workflows/

Karena perubahan pipeline berdampak ke seluruh tim, poin 2 dan 3 bukan formalitas: satu YAML yang salah bisa memblokir semua orang, jadi review dan uji di branch dulu adalah keharusan.


02.15 Security Architecture Pipeline

Pipeline yang punya akses ke secrets dan write permission adalah permukaan serangan baru. Panduan berikut menegakkan least-privilege untuk permissions, secrets, third-party actions, dan runner.

text
 1Security considerations untuk pipeline yang aman:
 2
 3PERMISSIONS (principle of least privilege):
 4  Default untuk semua jobs:
 5    permissions:
 6      contents: read  # read-only by default
 7
 8  Override per-job hanya yang butuh:
 9    ai-review job:
10      permissions:
11        pull-requests: write  # untuk post comment
12        contents: read
13
14    pr-enrichment job:
15      permissions:
16        pull-requests: write
17        contents: read
18
19SECRETS:
20  - Jangan expose secrets di logs
21  - Gunakan ${{ secrets.XXX }} bukan environment variable hardcode
22  - secrets.GITHUB_TOKEN: auto-generated, scope minimal
23
24THIRD-PARTY ACTIONS:
25  - Pin ke commit hash, bukan tag floating
26  - Verified creator actions lebih aman
27
28  BAD:  uses: some-action@main
29  OK:   uses: some-action@v1
30  BEST: uses: some-action@abc123def456  # pinned commit
31
32RUNNER:
33  - ubuntu-latest untuk non-sensitive
34  - Self-hosted runner untuk sensitive secrets
35  - Isolated environment via container untuk high-security

Satu praktik yang sering diabaikan tapi krusial: pin third-party action ke commit hash, bukan tag — karena tag bisa diubah pemiliknya dan menjadi vektor supply chain attack.


02.16 Skeleton Implementasi: Mulai Dari Sini

Semua teori di atas akan kita eksekusi mulai dari satu file starter yang minimal. Template berikut adalah titik awal ci.yml — hanya Layer 1 yang aktif, dengan Layer 2-4 disiapkan sebagai komentar untuk diisi di artikel berikutnya.

yaml
 1# STARTER TEMPLATE: .github/workflows/ci.yml
 2# Copy ini, customise, dan extend di artikel-artikel berikutnya
 3
 4name: CI — Santekno Shop
 5on:
 6  push:
 7    branches: [main, develop]
 8  pull_request:
 9    branches: [main, develop]
10    types: [opened, synchronize, ready_for_review]
11
12env:
13  GO_VERSION: '1.22'
14
15jobs:
16  # Layer 1: Core Go checks
17  go-quality:
18    name: Go Quality Gates
19    runs-on: ubuntu-latest
20    steps:
21      - uses: actions/checkout@v4
22      - uses: actions/setup-go@v5
23        with: { go-version: '${{ env.GO_VERSION }}', cache: true }
24      - run: go build ./...
25      - run: go test -race -count=1 ./...
26      - run: go vet ./...
27      - uses: golangci/golangci-lint-action@v6
28
29  # Layer 2: Architecture (kita tambahkan di artikel berikutnya)
30  # architecture-check: ...
31
32  # Layer 3: AI Review (artikel 03 dan seterusnya)
33  # ai-review: ...
34
35  # Layer 4: Spec Audit (artikel 04)
36  # spec-audit: ...

Mulailah dari skeleton ini: commit Layer 1 yang berjalan lebih dulu, baru buka komentar Layer 2, 3, dan 4 satu per satu di artikel selanjutnya — persis semangat prinsip “start dengan skeleton, iterasi”.


02.17 Perbandingan Pipeline Kita vs Pipeline Populer Lainnya

Untuk menempatkan pipeline ini dalam konteks, ada baiknya dibandingkan dengan pipeline standar di komunitas Go. Perbandingan berikut menunjukkan di mana pipeline Santekno berdiri relatif terhadap pipeline standar dan advanced.

text
 1Perbandingan dengan pipeline standard di komunitas Go:
 2
 3STANDARD Go pipeline (mayoritas tim):
 4  ✅ build, test, vet, lint
 5  ❌ architecture enforcement
 6  ❌ AI review
 7  ❌ spec compliance
 8  ❌ PR description generation
 9
10ADVANCED Go pipeline (10% tim):
11  ✅ semua di atas
12  ✅ security scanning (gosec, snyk)
13  ✅ coverage gate
14  ❌ AI review
15  ❌ spec compliance
16
17SANTEKNO AI-AUGMENTED (apa yang kita bangun):
18  ✅ semua di atas
19  ✅ architecture enforcement (custom script)
20  ✅ AI semantic review (Copilot + Claude)
21  ✅ spec compliance (Spec Kit)
22  ✅ PR description generation
23  ✅ cost monitoring
24  ✅ graduated enforcement
25
26Posisi kompetitif:
27  Mayoritas tim Go di Indonesia: Standard pipeline
28  Target kita: AI-Augmented yang belum banyak diterapkan
29
30  Membangun ini sekarang = 12-18 bulan head start
31  sebelum ini menjadi "standard" industri

Kesimpulannya jelas: dengan membangun pipeline AI-augmented sekarang, tim kamu mendapat head start 12-18 bulan sebelum pendekatan ini menjadi standar industri.


02.18 Timeline Implementasi Part 1-4

Blueprint ini akan dieksekusi bertahap sepanjang Topik 4. Roadmap berikut memetakan apa yang dikerjakan di setiap artikel, dari skeleton hari ini sampai LLMOps di Part 4.

text
 1Roadmap implementasi sepanjang Topik 4:
 2
 3SEKARANG (Artikel 2):
 4  ✅ Blueprint arsitektur (artikel ini)
 5  ✅ Skeleton workflow YAML
 6  ✅ Directory structure
 7
 8ARTIKEL 3 (next):
 9  Claude Code setup di GitHub Actions
10  Environment, auth, CLAUDE.md access
11  Basic Claude API call dari CI
12
13ARTIKEL 4:
14  Spec validation integration
15  specify audit di pipeline
16
17ARTIKEL 5-9 (Part 2):
18  Quality gates: AI review, security, coverage, architecture
19
20ARTIKEL 10-14 (Part 3):
21  Automation: PR description, changelog, migration check
22
23ARTIKEL 15-20 (Part 4):
24  LLMOps: prompt versioning, cost monitoring, incident playbook

Roadmap ini juga berfungsi sebagai kontrak ekspektasi: artikel ini menuntaskan fondasi arsitektur, dan artikel berikutnya langsung masuk ke setup Claude di CI.


02.19 Tips & Gotchas Arsitektur

Sebelum menutup, ada beberapa tips dan jebakan praktis yang layak dicatat saat menyusun arsitektur pipeline. Daftar berikut merangkum tiga tip dan tiga gotcha yang paling sering menentukan sukses-tidaknya implementasi.

💡 Tip 1: Start dengan skeleton, iterasi. Jangan bangun full pipeline sekaligus. Mulai dengan Layer 1 yang berjalan, commit ke main, baru tambahkan Layer 2, 3, 4 secara bertahap.

💡 Tip 2: Test pipeline di feature branch. Sebelum merge perubahan pipeline ke main, test di feature branch dengan beberapa dummy commits untuk verify behavior.

💡 Tip 3: Comment your YAML. Pipeline YAML yang tidak ada comment susah untuk di-maintain 6 bulan kemudian. Comment setiap job dengan purpose dan kondisi.

⚠️ Gotcha 1: needs yang tidak tepat. Jika L3 tidak punya needs: syntactic, ia akan jalan bersamaan dengan L1 — dan mungkin fail karena L1 belum selesai. Selalu define dependency dengan needs.

⚠️ Gotcha 2: if condition yang terlalu complex. Jika satu job punya 5+ conditions, pecah ke multiple jobs atau gunakan reusable workflows.

⚠️ Gotcha 3: Tidak ada timeout. Jobs tanpa timeout bisa jalan selamanya jika ada infinite loop atau stuck. Selalu tambahkan timeout-minutes: 10.

Kalau hanya satu yang bisa kamu ingat, ingat Gotcha 1: kesalahan needs adalah penyebab paling umum pipeline yang “kadang lulus kadang gagal” tanpa alasan yang jelas.


02.20 Ringkasan

Blueprint arsitektur yang kita design di artikel ini adalah fondasi untuk semua implementasi di Topik 4. Key decisions:

4 layer yang jelas: Syntactic → Semantic-Static → Semantic-AI → Spec Compliance. Setiap layer punya tujuan dan biaya yang berbeda.

Parallel where possible: L3 dan L4 parallel setelah L1+L2 selesai. Total wall time ≤ 8 menit.

Graduated enforcement: Warning dulu, block kemudian. Pipeline yang terlalu strict dari awal akan di-bypass.

Cost yang predictable: ~$3/bulan untuk tim 8 developer dengan 24 PRs/week.

Di artikel selanjutnya, kita mulai implementasi dengan langkah yang paling critical: setup Claude Code di GitHub Actions.

Artikel Terkait

💬 Komentar