Membangun CI/CD Pipeline dengan GitHub Actions dan AWS

CI/CD pipeline membuat setiap perubahan kode melewati jalur yang sama dari commit sampai production: di-build, dites, dikemas, lalu di-deploy. GitHub Actions memudahkan kita menulis jalur ini langsung di repository, dan AWS menyediakan tempat untuk menjalankan aplikasinya. Membuat pipeline yang sekadar jalan tidak sulit. Yang perlu dipikirkan adalah beberapa keputusan desain: apa yang di-build, bagaimana pipeline login ke AWS, siapa yang menyetujui rilis ke production, dan bagaimana membatalkan rilis yang bermasalah.

Tahapan Pipeline

Usahakan pengecekan di pull request selesai dalam beberapa menit. Kalau terlalu lama, developer cenderung menumpuk banyak perubahan dalam satu PR atau merge tanpa menunggu hasilnya. Test yang lebih lama bisa dijalankan setelah merge, asalkan kalau gagal, deployment berikutnya ikut tertahan.

Build Sekali, Deploy Artifact yang Sama

Build aplikasi sekali untuk setiap commit, lalu artifact yang sama persis itulah yang dipromosikan dari staging ke production. Kalau build diulang untuk setiap environment, yang jalan di production sebenarnya belum pernah dites, karena versi library, base image, atau build tool bisa saja berubah di antara dua build tersebut. Beri tag container image dengan commit SHA, jangan latest, supaya setiap versi yang sedang jalan bisa dilacak ke source code-nya dan bisa di-deploy ulang kapan saja.

Perbedaan antar environment cukup diatur lewat konfigurasi. Alamat database, feature flag, dan kredensial diambil saat aplikasi berjalan, dari environment variable atau secret store seperti AWS Secrets Manager dan Systems Manager Parameter Store.

Contoh yang sering terjadi: staging lolos semua test, lalu production gagal karena build ulang menarik versi library yang lebih baru. Dengan satu artifact untuk semua environment, masalah seperti ini tidak akan muncul.

Login ke AWS dengan OIDC, Bukan Access Key

Menyimpan AWS access key dan secret di GitHub Secrets adalah cara yang paling umum, sekaligus paling berisiko. Key-nya tidak pernah kedaluwarsa, hak aksesnya sering terlalu luas, dan kalau bocor bisa dipakai dari mana saja. GitHub Actions mendukung OpenID Connect (OIDC): workflow meminta token berumur pendek dari GitHub, lalu AWS menukarnya dengan kredensial sementara dari sebuah IAM role.

• Daftarkan GitHub sebagai OIDC identity provider di akun AWS, lalu buat satu IAM role untuk setiap environment.
• Batasi trust policy setiap role ke repository tertentu, dan ke branch atau GitHub environment tertentu. Dengan begitu workflow dari feature branch tidak bisa memakai role production.
• Beri role hanya hak akses yang dibutuhkan untuk deploy, misalnya push ke satu repository ECR dan update satu ECS service.
• Tambahkan permission id-token: write di workflow, pakai action aws-actions/configure-aws-credentials dengan role-to-assume, lalu hapus access key yang lama.

Approval Sebelum Deploy ke Production

Dengan GitHub environment, Anda bisa memasang aturan dan secret khusus untuk setiap target deployment. Buat environment production dengan required reviewers (tersedia di paket GitHub tertentu), sehingga deployment menunggu persetujuan dulu. Batasi juga branch yang boleh deploy ke sana. Nama environment ikut tercantum di token OIDC, jadi IAM role production bisa dibatasi hanya untuk job yang berjalan di environment tersebut.

Tambahkan concurrency group di job deployment supaya tidak ada dua rilis yang jalan bersamaan ke environment yang sama. Deployment yang tumpang tindih sering meninggalkan perubahan setengah jadi yang sulit dilacak.

Memilih Target Deployment di AWS

Untuk ECS, aktifkan deployment circuit breaker dengan opsi rollback. Kalau task baru gagal health check, ECS menghentikan deployment dan kembali ke task definition sebelumnya secara otomatis. Fitur ini hanya berguna kalau health check-nya benar-benar mengecek bahwa aplikasi bisa melayani request. Health check yang hanya mengecek apakah proses sudah jalan belum cukup.

Migrasi Database yang Aman

Saat rolling deployment, versi lama dan versi baru aplikasi berjalan bersamaan dan memakai database yang sama. Migrasi yang mengganti nama atau menghapus kolom akan langsung membuat versi lama error. Gunakan pola expand and contract: tambahkan struktur baru dulu dengan migrasi yang tetap kompatibel dengan versi lama, deploy kode yang memakainya, lalu hapus struktur lama di rilis berikutnya setelah tidak ada lagi yang memakainya.

• Jalankan migrasi sebagai langkah terpisah di pipeline, sebelum versi baru menerima trafik. Hindari menjalankan migrasi otomatis setiap kali aplikasi start.
• Pastikan setiap migrasi tetap kompatibel dengan versi yang sedang berjalan di production.
• Uji migrasi dengan data seukuran production. Perubahan yang selesai sekejap di tabel kecil bisa mengunci tabel besar selama beberapa menit.
• Pastikan ada backup terbaru sebelum menjalankan migrasi yang mengubah data.

Rollback Harus Mudah

Rollback sebaiknya cukup dengan men-deploy ulang artifact sebelumnya, tanpa revert kode lalu menunggu build baru. Karena setiap image diberi tag commit SHA, versi sebelumnya sudah tersedia dan sudah dites. Dokumentasikan cara men-deploy ulang versi tersebut, idealnya cukup satu perintah atau satu klik, dan coba lakukan sebelum benar-benar dibutuhkan saat insiden. Ditambah migrasi yang kompatibel ke belakang, kebanyakan rilis bermasalah bisa dipulihkan dalam beberapa menit.

Amankan Pipeline-nya Juga

• Kunci action pihak ketiga ke commit SHA lengkap. Tag seperti v4 bisa dipindahkan, sehingga action yang disusupi bisa mengubah pipeline Anda tanpa ketahuan.
• Atur permission default GITHUB_TOKEN menjadi read-only, lalu beri akses write hanya di job yang membutuhkannya.
• Jangan pernah membuka secret deployment untuk workflow yang dipicu pull request dari fork.
• Scan dependency dan container image di pipeline, dan gagalkan build untuk celah keamanan kritis yang sudah ada perbaikannya.
• Pakai cache dependency supaya build cepat, tapi jangan pernah menaruh secret atau hasil build yang berbeda per environment di cache.

Menerapkan CI/CD Secara Bertahap

1. 1Jalankan lint dan unit test di setiap pull request, dan jadikan syarat wajib sebelum merge.
2. 2Kemas aplikasi dalam container. Build satu image untuk setiap commit di branch utama, beri tag commit SHA, lalu push ke Amazon ECR.
3. 3Ganti access key AWS dengan role OIDC, satu untuk setiap environment, masing-masing dibatasi ke repository dan branch atau environment-nya.
4. 4Deploy otomatis ke staging, lalu buat environment production dengan approval wajib dan concurrency group.
5. 5Terapkan aturan migrasi, health check yang benar, dan rollback otomatis. Setelah itu, latih rollback manual setidaknya sekali.
6. 6Ukur frekuensi deployment, lead time, persentase deployment yang gagal, dan waktu pemulihan. Angka-angka ini membantu menentukan apa yang perlu diperbaiki berikutnya.