Mendorong kode ke repository adalah satu bagian dari perjalanan rilis. Diagram ini menghubungkan pekerjaan developer, pengujian, deployment, dan operasional. Catatan ini mengembangkan alur tersebut dengan praktik dari dokumentasi GitHub Actions dan Google SRE.
Apa yang Dimaksud CI/CD?
Continuous integration (CI) menggabungkan perubahan kode secara berkala dan memeriksanya melalui proses otomatis, seperti lint, pengujian, dan build. Masalah integrasi lebih mudah ditemukan ketika perubahan masih kecil.
Continuous delivery menjaga perubahan yang lolos pemeriksaan agar siap dirilis; keputusan deployment production dapat tetap dilakukan manusia. Pada continuous deployment, perubahan yang memenuhi seluruh kriteria pipeline diterapkan otomatis. Keduanya sering disingkat CD, sehingga kebijakan tim perlu dinyatakan dengan jelas.
1. Plan — Mendefinisikan Hasil yang Diharapkan
Kebutuhan dipecah menjadi pekerjaan dengan acceptance criteria yang dapat diperiksa. Contohnya, “artikel bisa dibuka lewat slug pendek di production” lebih mudah diverifikasi daripada “perbaiki routing”.
Jira dan sprint pada gambar adalah contoh pengelolaan pekerjaan. Tim kecil dapat memakai issue dan checklist selama hasil yang diharapkan serta batas perubahan tetap jelas.
2. Develop — Perubahan Kecil yang Dapat Ditinjau
Developer mengubah kode, melakukan pemeriksaan lokal, dan mengirim perubahan ke Git. Pull request membantu peninjau memahami masalah, solusi, dan bukti bahwa perilaku yang dibutuhkan sudah terpenuhi.
Dalam GitHub Actions, event seperti pembukaan pull request atau push dapat memicu workflow. Workflow berisi job dan step; urutan dependensinya menentukan pemeriksaan mana yang harus berhasil sebelum langkah berikutnya berjalan.
3. Build dan Package — Menghasilkan Versi yang Jelas
Pipeline menyiapkan dependency dan toolchain, menjalankan pemeriksaan, lalu menghasilkan aplikasi atau package yang akan diterapkan. Lockfile dan versi runtime membantu mengurangi perbedaan antara komputer developer dan CI.
Artifact perlu dapat ditelusuri ke commit dan konfigurasi build-nya. Ini membantu menjawab pertanyaan saat insiden: versi apa yang sedang berjalan, dan perubahan mana yang membedakannya dari versi sebelumnya?
Jenkins, SonarQube, dan Artifactory pada GIF merupakan contoh tool. Fungsi yang sama dapat dibagi antara GitHub Actions, registry container, atau platform deployment sesuai arsitektur proyek.
4. Test — Memeriksa Aplikasi Sebelum Rilis
Environment development, QA, dan UAT menyediakan tempat untuk memeriksa fungsi, integrasi, serta kesesuaian kebutuhan pengguna. Tidak semua proyek membutuhkan environment terpisah untuk setiap tahap; pilih pemisahan yang membantu mengendalikan risikonya.
Pengujian sebaiknya memeriksa hasil yang akan digunakan pengguna. Misalnya, jalankan server dari build production dan periksa isi halaman, bukan hanya keberhasilan kompilasi atau status HTTP.
5. Release — Mengatur Akses dan Cara Pemulihan
Deployment membawa versi yang sudah diperiksa ke environment tujuan. Pada GitHub Actions, environment dapat membatasi branch yang boleh deploy, mengatur reviewer, dan menyediakan secret khusus environment sesuai fitur yang tersedia.
Pisahkan kredensial development dan production. Tentukan siapa yang menangani kegagalan deployment dan bagaimana versi sebelumnya dipulihkan. Untuk perubahan database, pemulihan kode belum tentu memulihkan data; kompatibilitas perubahan schema juga perlu direncanakan.
6. Operate — Memastikan Aplikasi Tetap Berfungsi
Setelah rilis, pantau perilaku yang terlihat oleh pengguna dan kondisi internal aplikasi. Google SRE membahas empat sinyal utama: latency, traffic, errors, dan saturation.
Contohnya, deployment selesai tetapi latency meningkat atau halaman penting menampilkan not-found. Monitoring perlu membantu membedakan kondisi tersebut dari sekadar “proses server masih hidup”. Alert sebaiknya menunjukkan masalah yang membutuhkan tindakan, dengan penanggung jawab yang jelas.
Contoh Pipeline untuk Proyek Web Kecil
Pull request → pemeriksaan → build → preview → verifikasi → production → monitoringPada proyek yang sudah mendefinisikan script pemeriksaan dan build, tahap awalnya dapat berisi:
pnpm install --frozen-lockfile
pnpm test
pnpm buildPerintah itu belum mencakup deployment atau seluruh pengujian aplikasi. Isi
pnpm test mengikuti script proyek; periksa apakah yang berjalan lint, typecheck, unit test, atau kombinasi lainnya.Sebelum menyatakan rilis berhasil, pastikan versi yang benar terpasang, alur pengguna utama berjalan, dan monitoring tidak menunjukkan regresi. Detail proses dapat berkembang mengikuti kebutuhan aplikasi.
