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.
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.
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 qualityKalau 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.
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.
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 80Kunci 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.
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.
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.
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.
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: 3Bagian 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.
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 onlyIntinya, 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.
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 timeDengan 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.
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 SlackPrinsipnya 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.
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 retrospectiveMetrik “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.
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 checksKunci 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.
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.
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-securitySatu 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.
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.
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" industriKesimpulannya 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.
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 playbookRoadmap 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.