CI Pipeline
Cegah Code Rusak Masuk Staging

CI adalah pagar otomatis antara kode di laptop dan environment yang dipakai bersama.

Di React atau Node kamu mungkin sudah terbiasa dengan pipeline yang menjalankan npm run lint, npm test, lalu npm run build. Di Laravel ada composer test, Pint, PHPStan, dan PHPUnit. Di Go konsepnya sama, hanya tool intinya jauh lebih dekat dengan toolchain bahasa.

Untuk backend online shop skincare, CI bukan formalitas. Bug kecil di checkout bisa membuat stok tidak berkurang. Bug kecil di webhook payment bisa membuat order tidak pernah berubah ke paid. Satu file yang lupa di-gofmt atau satu Dockerfile yang rusak bisa membuat staging gagal deploy tepat saat tim butuh demo cepat. CI menangkap semua itu di pull request, bukan di production jam dua pagi.

Sebelum menulis pipeline, pahami dulu kosakata workflow, job, step, dan runner.

GitHub Actions adalah CI bawaan GitHub. Satu file YAML di .github/workflows/ mendeskripsikan kapan pipeline jalan dan apa yang dikerjakan. Istilahnya berlapis, jadi mari samakan dulu kosakatanya.

Dua hal kecil yang sering bikin pendatang bingung. Pertama, uses: memanggil action yang dipublikasikan orang lain dan di-pin ke versi mayor, misalnya actions/checkout@v4. Kedua, setiap job mulai dari runner bersih: tidak ada file dari job sebelumnya kecuali kamu checkout ulang. Inilah kenapa hampir setiap job mengulang checkout dan setup-go.

Kerangka minimal sebuah workflowSalin
name: CI
on:
  push:
    branches: [ main ]
  pull_request:               # jalan di setiap PR, inilah gate-nya
jobs:
  lint-test:
    runs-on: ubuntu-latest    # runner GitHub-hosted, bersih tiap run
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: '1.26'
          cache: true
      - run: go test ./...

Pisahkan pekerjaan murah, pekerjaan berat, dan pekerjaan yang menyentuh registry production.

Pipeline yang baik menaruh pemeriksaan termurah paling depan. Kalau format gagal, tidak ada gunanya membakar menit runner untuk integration test dan Docker build.

Kita susun lima job: lint, unit-test, integration-test, build-image, dan push-ecr. Job lint paling murah, jadi ia gate paling depan. Test bergantung pada lint lewat needs. Build image hanya jalan setelah semua test lulus. Push ke ECR adalah satu-satunya job yang menyentuh AWS, dan ia hanya jalan pada push ke main, bukan di pull request.

flowchart TD
  Trigger["Push ke main atau Pull Request"] --> Lint["lint: gofmt, go vet, golangci-lint"]
  Lint --> Unit["unit-test: go test -race ./..."]
  Lint --> Integ["integration-test: PostgreSQL service + migrate + go test"]
  Unit --> Build["build-image: docker build (tanpa push)"]
  Integ --> Build
  Build --> Branch{"Event push ke main?"}
  Branch -->|Tidak (PR)| Stop["Selesai setelah image berhasil dibuild"]
  Branch -->|Ya| ECR["push-ecr: OIDC ke AWS, push image ber-SHA ke ECR"]

Gambar 1. Pipeline dibuat berlapis agar error paling murah tertangkap paling awal, dan hanya main yang boleh push image.

Pemeriksaan cepat yang menjaga standar kode sebelum test yang lebih mahal jalan.

Quality gate adalah lapisan paling murah dan paling cepat gagal. Ia menangkap masalah gaya dan bug semantik yang lolos dari compiler.

gofmt memastikan format semua file Go konsisten. Di CI kita memakai gofmt -l ., bukan gofmt -w .. Flag -l hanya menampilkan daftar file yang belum terformat ke stdout tanpa mengubah apa pun, sehingga deterministik dan fail-fast. Idiom CI-nya: ambil output gofmt -l ., kalau tidak kosong berarti ada file belum rapi, lalu exit 1.

go vet mencari konstruksi mencurigakan yang lolos compiler, misalnya format Printf yang tidak cocok dengan argumen, atau lock yang ter-copy by value. Ia bukan bukti formal program benar, tetapi murah dan menangkap kelas bug yang nyata.

golangci-lint adalah meta-linter yang menjalankan banyak linter sekaligus (errcheck, staticcheck, ineffassign, dan lainnya) dalam satu action. Per versi terbaru, golangci-lint berada di seri v2 dan action-nya golangci/golangci-lint-action@v9. Sejak v4, action ini mewajibkan setup-go dipasang lebih dulu.

TerminalSalin
gofmt -l .
go vet ./...
golangci-lint run ./...

Di GitHub Actions, fail fast antar job dibuat dengan needs. Job test bergantung pada job lint, jadi kalau lint gagal job test otomatis dilewati. Ini lebih eksplisit dan lebih paralel daripada menumpuk semua langkah ke satu job panjang.

Potongan needs antar jobSalin
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - run: go vet ./...

  unit-test:
    needs: lint              # dilewati otomatis jika lint gagal
    runs-on: ubuntu-latest
    steps:
      - run: go test -race ./...

CI harus membuktikan logic benar, repository PostgreSQL benar, dan concurrency bebas dari race yang jelas.

Test di laptop membuktikan kode jalan di mesinmu. Test di CI membuktikan kode jalan di mesin bersih yang reprodusibel, persis seperti staging nanti.

Unit test menjalankan logic murni: kalkulasi total cart, penerapan voucher, validasi stok, transisi status order. Cepat, tanpa database. Integration test menjalankan repository pgx terhadap PostgreSQL nyata supaya query, migration, constraint, dan transaction benar-benar teruji, bukan hanya di-mock.

TerminalSalin
go test -race -count=1 ./...
TEST_DB_URL="postgres://skincare:skincare@localhost:5432/skincare_test?sslmode=disable" \
  go test -race -count=1 -tags=integration ./...

Untuk integration test, GitHub Actions menyediakan service container. Kita menjalankan postgres:17 sebagai service, memberinya healthcheck pg_isready, lalu memetakan port 5432 ke runner. Tanpa healthcheck, test bisa mulai sebelum Postgres siap menerima koneksi dan jadi flaky. Setelah database hidup, workflow menjalankan migration dulu, baru test dengan build tag integration.

Potongan job integration-testSalin
  integration-test:
    runs-on: ubuntu-latest
    needs: lint
    services:
      postgres:
        image: postgres:17
        env:
          POSTGRES_USER: skincare
          POSTGRES_PASSWORD: skincare
          POSTGRES_DB: skincare_test
        ports:
          - 5432:5432
        options: >-
          --health-cmd "pg_isready -U skincare -d skincare_test"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

sequenceDiagram
  participant R as Runner (ubuntu-latest)
  participant PG as Service postgres:17
  participant T as go test -tags=integration
  R->>PG: start container
  PG-->>R: health pg_isready (retry sampai PASS)
  R->>R: go run ./cmd/migrate up
  R->>T: jalankan test integration
  T->>PG: query lewat localhost:5432
  PG-->>T: hasil (constraint, transaction teruji)
  T-->>R: lulus atau gagal

Gambar 2. Service container PostgreSQL harus sehat dan ter-migrate sebelum integration test menyentuhnya.

CI juga harus membuktikan Dockerfile dari modul sebelumnya benar-benar bisa dibuild.

Banyak tim hanya menjalankan test Go, lalu baru sadar Dockerfile rusak saat deploy. Untuk backend Go ini mudah dicegah: build image di setiap pull request dan push.

Job build-image tidak perlu push. Ia cukup membuktikan docker build sukses, layer cache bekerja, dan binary masuk ke final image distroless. Kita pakai docker/setup-buildx-action@v3 untuk mengaktifkan Buildx, lalu docker/build-push-action@v7 dengan push: false. Cache layer GitHub (type=gha) membuat build berikutnya jauh lebih cepat.

Potongan job build-image (tanpa push)Salin
  build-image:
    runs-on: ubuntu-latest
    needs: [ unit-test, integration-test ]
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/build-push-action@v7
        with:
          context: .
          file: ./Dockerfile
          push: false
          tags: skincare-api:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

Setelah semua gate lulus, branch main mengirim image ke registry AWS tanpa menyimpan access key.

Amazon ECR adalah registry container terkelola AWS. Job push-ecr hanya jalan saat event push dan branch main, lalu mengunggah image ber-SHA ke sana.

Bagian paling penting di sini adalah cara autentikasi. Kita tidak menyimpan AWS_ACCESS_KEY_ID dan AWS_SECRET_ACCESS_KEY jangka panjang di GitHub Secrets. Sebagai gantinya, GitHub menukar JWT bawaan workflow dengan kredensial sementara dari AWS STS lewat AssumeRoleWithWebIdentity. Pola ini disebut OIDC.

Agar OIDC bekerja, job wajib punya permission id-token: write. Tanpa itu, configure-aws-credentials tidak bisa meminta token. Di sisi AWS, trust policy IAM role membatasi sub ke repo:org/repo:ref:refs/heads/main, jadi hanya branch main repo ini yang boleh AssumeRole. Jangan biarkan wildcard repo.

sequenceDiagram
  participant GHA as GitHub Actions (job push-ecr)
  participant STS as AWS STS
  participant ECR as Amazon ECR
  GHA->>GHA: minta OIDC token (id-token: write)
  GHA->>STS: AssumeRoleWithWebIdentity (token JWT)
  STS-->>GHA: kredensial sementara (auto-expire)
  GHA->>ECR: docker login (amazon-ecr-login)
  GHA->>ECR: push skincare-api:<github.sha>
  ECR-->>GHA: image tersimpan, traceable ke commit

Gambar 3. OIDC menukar JWT workflow dengan kredensial STS sementara, jadi tidak ada access key permanen yang perlu disimpan.

Satu file ci.yml yang siap ditaruh di root repository backend skincare.

File berikut menggabungkan semua yang sudah dibahas: lint, dua jenis test, build image, dan push ECR bersyarat. Taruh di .github/workflows/ci.yml.

.github/workflows/ci.ymlSalin
name: CI

on:
  push:
    branches: [ main ]
  pull_request:

permissions:
  contents: read

concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

env:
  GO_VERSION: "1.26"
  AWS_REGION: ap-southeast-1
  ECR_REPOSITORY: skincare-api

jobs:
  lint:
    name: Lint, format, dan vet
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-go@v5
        with:
          go-version: ${{ env.GO_VERSION }}
          cache: true

      - name: Cek gofmt (gagal jika ada file belum terformat)
        run: |
          unformatted="$(gofmt -l .)"
          if [ -n "$unformatted" ]; then
            echo "::error::File berikut belum gofmt:"
            echo "$unformatted"
            exit 1
          fi

      - name: go vet
        run: go vet ./...

      - name: golangci-lint
        uses: golangci/golangci-lint-action@v9
        with:
          version: v2.1

  unit-test:
    name: Unit test dengan race detector
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-go@v5
        with:
          go-version: ${{ env.GO_VERSION }}
          cache: true

      - name: Unit test
        run: go test -race -count=1 ./...

  integration-test:
    name: Integration test dengan PostgreSQL
    runs-on: ubuntu-latest
    needs: lint
    services:
      postgres:
        image: postgres:17
        env:
          POSTGRES_USER: skincare
          POSTGRES_PASSWORD: skincare
          POSTGRES_DB: skincare_test
        ports:
          - 5432:5432
        options: >-
          --health-cmd "pg_isready -U skincare -d skincare_test"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    env:
      DATABASE_URL: postgres://skincare:skincare@localhost:5432/skincare_test?sslmode=disable
      TEST_DB_URL: postgres://skincare:skincare@localhost:5432/skincare_test?sslmode=disable
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-go@v5
        with:
          go-version: ${{ env.GO_VERSION }}
          cache: true

      - name: Jalankan migration
        run: go run ./cmd/migrate up

      - name: Integration test
        run: go test -race -count=1 -tags=integration ./...

  build-image:
    name: Build Docker image
    runs-on: ubuntu-latest
    needs: [ unit-test, integration-test ]
    steps:
      - uses: actions/checkout@v4

      - uses: docker/setup-buildx-action@v3

      - name: Build image (tanpa push)
        uses: docker/build-push-action@v7
        with:
          context: .
          file: ./Dockerfile
          push: false
          tags: ${{ env.ECR_REPOSITORY }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  push-ecr:
    name: Push image ke Amazon ECR
    runs-on: ubuntu-latest
    needs: build-image
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ vars.AWS_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Login ke Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - uses: docker/setup-buildx-action@v3

      - name: Build dan push image
        uses: docker/build-push-action@v7
        with:
          context: .
          file: ./Dockerfile
          push: true
          tags: |
            ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ github.sha }}
            ${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

CI hanya informatif sampai branch protection memaksanya jadi syarat merge.

Pipeline hijau di pull request tidak ada artinya kalau orang masih bisa merge meski CI merah. Branch protection-lah yang mengubah CI dari informasi menjadi gate yang sesungguhnya.

Tanpa proteksi, status check CI hanya hiasan: developer bisa merge PR yang gagal test, atau push langsung ke main melewati pull request sama sekali. Branch protection menutup celah itu. Yang kita wajibkan minimal: status check lint, unit-test, dan integration-test harus PASS; branch harus up to date; PR butuh minimal satu review; force-push dilarang.

flowchart LR
  PR["Pull Request"] --> CI["CI: lint, test, build"]
  CI -->|merah| Block["Merge diblokir branch protection"]
  CI -->|hijau| Review["Review PR (min 1 approval)"]
  Review --> Merge["Merge ke main"]
  Merge --> Push["push-ecr: image ber-SHA ke ECR"]
  Push --> Stg["Staging deploy SHA itu"]
  Stg -->|verifikasi lulus| Prod["Promote SHA yang sama ke production"]

Gambar 4. Image identik yang sudah diuji dipromosikan dari staging ke production, jadi tidak ada drift antar environment.

Jalankan pipeline bertahap agar failure mudah dibaca dan diperbaiki.

Target hands-on ini: dari nol sampai pull request hijau yang membuild image, lalu push ke main yang mengirim image ke ECR.

TerminalSalin
mkdir -p .github/workflows
cp ci.yml .github/workflows/ci.yml

gofmt -l .
go vet ./...
go test -race -count=1 ./...
docker build -t skincare-api .

git checkout -b feature/ci-pipeline
git add .github/workflows/ci.yml
git commit -m "Tambah CI pipeline GitHub Actions"
git push origin feature/ci-pipeline

Sebagian besar masalah CI bukan karena Go sulit, tetapi karena batas local, runner, database, dan registry kurang jelas.

Kebiasaan kecil dari stack lama sering terbawa ke pipeline Go dan menimbulkan kegagalan yang membingungkan. Berikut yang paling sering muncul.

CI pipeline memberi backend online shop skincare pagar otomatis sebelum kode sampai ke staging dan production.

Modul ini menyatukan R8.C1 dan R8.C2 ke dalam alur kerja tim. Dockerfile sudah bisa membangun API. Docker Compose sudah menjalankan stack lokal. CI kini memastikan setiap perubahan melewati lint, test, build image, dan push registry yang aman sebelum staging menerima artifact baru.

Langkah berikutnya di Roadmap 8 adalah deployment: image ber-SHA dari ECR akan dijalankan oleh ECS Fargate di balik ALB, database production pindah ke RDS PostgreSQL, secret diambil dari AWS Secrets Manager (pola yang sudah kamu siapkan di Roadmap 7), worker memproses event payment dari SQS, dan observability lewat CloudWatch menutup loop produksinya. Pipeline yang baru kamu bangun inilah yang akan memberi makan image tepercaya ke semua tahap itu.