Hari 2: CI/CD Pipeline Auto Build & Test di GitHub

Kenapa CI/CD Itu Penting Banget?

Bayangin nulis kode, push ke GitHub, terus lupa nge-test. Beberapa hari kemudian baru sadar ada yang rusak. Repot kan? Nah, CI/CD itu nge-fix masalah ini. Setiap kali push kode, pipeline otomatis jalanin build dan test. Kalo ada yang rusak, langsung ketahuan.

Hari kedua challenge 60 hari DevSecOps itu fokusnya ke sini: bikin pipeline CI/CD dasar pake GitHub Actions buat SecureBank API yang kemarin udah dibikin.

Apa yang Dibikin Hari Ini

Satu file YAML di .github/workflows/ci.yml yang bikin GitHub otomatis jalanin build dan test setiap ada push atau pull request ke repo.

Workflow GitHub Actions

Pipeline-nya gampang aja sih — cuma satu job dengan beberapa step:

1. Checkout code — ambil kode dari repo
2. Setup Go 1.26 — install Go di runner Ubuntu
3. Build — go build -v ./... buat mastiin kode bisa di-compile
4. Test — go test -v -race -coverprofile=coverage.out ./... buat mastiin semua test lulus
5. Upload Coverage — simpen coverage report sebagai artifact yang bisa di-download

Semua step jalan di dalam folder securebank-api/ karena proyeknya ada di subdirektori, bukan di root repo.

Trigger Pipeline

Pipeline jalan otomatis di dua kondisi:

• Push ke branch main atau develop
• Pull request ke branch main

Jadi setiap kali ada perubahan kode, langsung ke-cek. Ga perlu manual lagi.

Yang Agak Ribet dan Solusinya

Proyek di Subdirektori

Tutorial referensi dari silabus ngasumsiin proyek ada di root repo. Tapi di kasus ini, securebank-api ada di dalam folder chalange-devsecops/securebank-api/. Solusinya? Pake working-directory: securebank-api di setiap step.

GitHub Actions cuma baca .github/workflows/ dari root repo, jadi file workflow-nya harus ditaruh di root, bukan di dalam folder proyeknya.

Versi Go

Tutorial referensi pake Go 1.22, tapi lokal udah pake 1.26. Jadi disesuaikan aja — baik di go.mod maupun di workflow, semuanya pake 1.26. Penting biar lokal dan CI konsisten.

Upload Artifact Meski Test Gagal

Step upload coverage dibikin if: always() biar tetep ke-upload meski step test gagal. Kenapa? Kalo test gagal, justru itu momen yang paling butuh coverage report buat debugging.

Lesson Learned

1. CI/CD bukan cuma buat deployment. Banyak yang mikir CI/CD itu cuma Deploy Otomatis ke Server. Padahal step pertama yang paling penting itu nge-build dan nge-test otomatis. Setiap push di-cek, setiap PR di-verifikasi. Ini ngehindarin bug yang ga sengaja masuk ke main branch.

2. working-directory itu penyelamat buat monorepo. Waktu proyek ada di subdirektori, semua command di workflow bakal gagal kalo ga diset working-directory. Ini sesuatu yang sering bikin bingung orang yang baru mulai pake GitHub Actions.

3. if: always() itu best practice buat artifact upload. Tanpa ini, kalo test gagal, coverage report ga ikut ke-upload — padahal itulah yang paling dibutuhkan waktu debugging. Satu baris kecil, dampaknya besar.

4. Label job yang jelas itu membantu. Nama job Build & Test (Go 1.26) langsung ngasih info versi Go yang dipake. Pas pipeline-nya nambah jadi banyak job (nanti di hari-hari berikutnya), label yang jelas bikin gampang baca di GitHub Actions UI.

Kesimpulan

Hari ini cuma satu file YAML, tapi dampaknya besar. Sekarang setiap push ke repo otomatis di-build dan di-test. Kalo ada yang rusak, GitHub langsung kasih tahu lewat merahnya pipeline.

Ini baru awal CI/CD. Di hari-hari berikutnya, pipeline ini bakal nambah job baru: secret scanning (Hari 3), SCA (Hari 5), SAST (Hari 8), dan masih banyak lagi. Satu pipeline, nambah layer keamanan terus.

Besok lanjut ke Hari 3: Secret Scanning pake Gitleaks — nyari kredensial yang bocor di dalam kode.

Kodenya bisa dilihat di repo: github.com/stayrelevantid/chalange-devsecops