# CI/CD dengan GitHub Actions: Dari Nol Hingga Produksi > Bangun pipeline CI/CD lengkap dengan GitHub Actions — otomasi pengujian, build Docker, dan deployment tanpa downtime dari commit pertama hingga produksi. URL: https://www.matthewswong.com/id/blog/ci-cd-pipeline-github-actions/ - Author: Matthews Wong (https://www.matthewswong.com/id/about/) - Published: 2024-07-15 - Updated: 2024-07-15 - Category: DevOps CI/CD dengan GitHub Actions telah menjadi standar de-facto untuk merilis software secara andal dan cepat. Baik Anda developer solo maupun bagian dari tim engineering yang berkembang, mengotomasi tahap pengujian, build, dan deployment menghilangkan langkah manual yang melelahkan antara sebuah commit dan rilis yang live. Dalam panduan ini kita akan membangun pipeline siap produksi dari nol — mencakup workflow, penerbitan Docker image, deployment via SSH, dan praktik keamanan terbaik. ## Memahami CI/CD dan GitHub Actions Continuous Integration (CI) adalah praktik menjalankan pengujian secara otomatis setiap kali kode di-push. Continuous Deployment (CD) melangkah lebih jauh dengan mengirimkan build yang lolos secara otomatis ke environment staging atau produksi. GitHub Actions mengimplementasikan keduanya langsung di dalam repository menggunakan file workflow YAML yang disimpan di bawah .github/workflows/. ### Anatomi File Workflow Setiap workflow GitHub Actions diawali dengan trigger (on:), mendefinisikan satu atau lebih job, dan setiap job berisi rangkaian langkah. Langkah-langkah dapat berupa perintah shell atau marketplace action yang dapat digunakan kembali yang diterbitkan oleh komunitas. Job berjalan di virtual machine yang disebut runner — GitHub menyediakan runner Ubuntu, Windows, dan macOS yang di-hosting secara gratis dalam kuota bulanan. ### Event dan Trigger Workflow dapat dipicu oleh puluhan event: push, pull_request, schedule (cron), workflow_dispatch (manual), atau repository_dispatch (webhook eksternal). Menggunakan filter branch seperti 'branches: [main]' memastikan job deployment produksi Anda hanya berjalan ketika kode masuk ke branch main, bukan branch fitur. > Simpan semua kredensial di GitHub Encrypted Secrets (Settings → Secrets and variables → Actions) dan jangan pernah meng-hardcode token atau password dalam file workflow. Secret secara otomatis disembunyikan di log. ## Membangun dan Push Docker Image Pipeline CI yang kuat membangun dan menandai Docker image pada setiap test run yang berhasil, kemudian mendorongnya ke container registry. Menggunakan docker/build-push-action bersama Docker Buildx memungkinkan fitur canggih seperti multi-platform build dan layer caching inline, yang secara drastis mengurangi waktu build pada run berikutnya. ### Workflow YAML: Test → Build → Deploy Workflow di bawah ini merangkai tiga job menggunakan kata kunci needs: untuk memastikan eksekusi berurutan. Test harus lulus sebelum image dibangun, dan image harus diterbitkan sebelum perintah SSH deployment berjalan. Ini memastikan kode yang rusak tidak pernah mencapai produksi. ### Mengoptimalkan Performa Build dengan Caching Cache langkah npm ci install menggunakan actions/cache atau opsi cache: bawaan pada actions/setup-node. Untuk Docker, masukkan cache-from: type=registry ke docker/build-push-action agar layer yang tidak berubah diambil dari registry daripada dibangun ulang. Pada cache yang sudah hangat, waktu build turun dari beberapa menit menjadi di bawah 30 detik. ## Strategi Deployment Tanpa Downtime Langkah deployment yang menghentikan container yang berjalan sebelum memulai yang baru menciptakan jendela gangguan singkat. Dua pola sederhana menghindari ini: menggunakan kebijakan rolling update start-first Docker, atau menjalankan container baru sementara di port berbeda sebelum mengalihkan aturan load balancer. ### Deployment Berbasis SSH dengan Health Check Marketplace action appleboy/ssh-action memungkinkan Anda menjalankan perintah shell pada server remote melalui SSH tanpa memasang agen apa pun. Setelah menarik dan memulai container baru, tambahkan loop health check yang mem-poll endpoint /health dengan timeout sebelum menyatakan deployment berhasil. > **Jangan Pernah Mengekspos Secret Produksi di Log Workflow** > Hindari menampilkan variabel environment atau mencetak output debug yang mungkin berisi secret. Gunakan kondisi 'if: failure()' untuk mengunggah artefak debug hanya ketika job gagal, menjaga log tetap bersih dalam run normal. Segera rotasi secret apa pun yang tidak sengaja tercatat di log. ## Penguatan Keamanan Pipeline Anda Pipeline yang menangani kredensial produksi adalah target bernilai tinggi. Kunci izin di level workflow dan job, pin action pihak ketiga ke commit SHA tertentu daripada tag yang dapat berubah, dan aktifkan required status checks agar branch main hanya dapat menerima kode melalui pull request yang telah direview. ### Mem-pin Versi Action Menggunakan 'actions/checkout@v4' mereferensikan tag yang dapat berubah. Seseorang dengan akses write ke repository tersebut dapat mengubah ke mana v4 mengarah. Mem-pin ke commit SHA penuh — 'actions/checkout@11bd719' — memastikan Anda selalu mendapatkan kode yang telah Anda review, menghilangkan risiko supply-chain. ### OIDC Token: Autentikasi Cloud Tanpa Kunci Statis Penyedia OIDC GitHub memungkinkan workflow Anda meminta JWT berumur pendek yang dipercaya langsung oleh penyedia cloud (AWS, GCP, Azure). Anda mengkonfigurasi trust policy di sisi cloud, lalu tidak ada secret statis yang tersimpan di repository Anda sama sekali — workflow menukar token OIDC dengan kredensial sementara saat runtime. ## Matrix Build dan Pengujian Paralel Strategi matrix GitHub Actions memungkinkan Anda menjalankan job yang sama di berbagai versi runtime, sistem operasi, atau variabel kustom secara paralel. Untuk proyek Node.js Anda mungkin menguji di Node 18, 20, dan 22 secara bersamaan, memotong total waktu CI hingga dua pertiga dibandingkan run berurutan. ### Menggunakan matrix: untuk Menguji Berbagai Versi Node.js Definisikan matrix dengan 'node-version: [18, 20, 22]' dan referensikan sebagai '$'{{ matrix.node-version }}''' di dalam langkah setup-node. GitHub secara otomatis memfanout job ke tiga runner paralel. Jika salah satu versi gagal, pemeriksaan keseluruhan ditandai gagal, memberi Anda sinyal tepat tentang kompatibilitas. > Gunakan 'continue-on-error: true' pada leg matrix individual ketika Anda ingin mengumpulkan data dari versi Node eksperimental tanpa memblokir merge. Tambahkan langkah ringkasan akhir yang membaca outcome matrix dan memposting tabel Markdown ke PR sebagai komentar menggunakan GitHub API. ## Source links - https://docs.github.com/en/actions - https://docs.docker.com/build/ci/github-actions/ - https://docs.github.com/en/actions/security-guides/encrypted-secrets - https://martinfowler.com/articles/continuousIntegration.html ## FAQ ### Bagaimana rantai tiga job (Test → Build → Deploy) mencegah kode rusak mencapai produksi? Workflow menggunakan kata kunci 'needs:' sehingga setiap job hanya dimulai setelah job sebelumnya berhasil. Test harus lulus sebelum Docker image dibangun, dan image harus diterbitkan ke registry sebelum perintah SSH deployment berjalan. Gerbang berurutan ini berarti test yang gagal otomatis memblokir build maupun deployment. ### Strategi caching apa yang direkomendasikan dalam artikel ini untuk mempercepat waktu build? Untuk dependensi Node.js, cache langkah 'npm ci' dengan 'actions/cache' atau opsi cache bawaan pada 'actions/setup-node'. Untuk Docker, gunakan 'cache-from: type=registry' pada 'docker/build-push-action' agar layer yang tidak berubah diambil dari registry daripada dibangun ulang. Pada cache yang sudah hangat, waktu build bisa turun dari beberapa menit menjadi di bawah 30 detik. ### Mengapa action pihak ketiga sebaiknya di-pin ke commit SHA penuh, bukan tag versi seperti @v4? Tag yang dapat berubah seperti '@v4' bisa diam-diam dialihkan oleh siapa saja yang memiliki akses write ke repository action tersebut, berpotensi menyuntikkan kode berbahaya ke dalam pipeline Anda. Mem-pin ke commit SHA penuh — misalnya 'actions/checkout@11bd719' — menjamin Anda selalu menjalankan tepat kode yang telah Anda review, menutup celah serangan supply-chain. ### Bagaimana autentikasi token OIDC menghilangkan kebutuhan menyimpan kredensial cloud sebagai repository secret? Penyedia OIDC bawaan GitHub menerbitkan JWT berumur pendek saat runtime, yang AWS, GCP, dan Azure dipercaya melalui trust policy di sisi cloud. Workflow menukar token tersebut dengan kredensial sementara secara langsung, sehingga tidak ada secret statis yang perlu disimpan di GitHub Encrypted Secrets. Ini menghilangkan risiko kebocoran atau rotasi manual kredensial berumur panjang. ### Bagaimana matrix build mengurangi total waktu CI saat menguji berbagai versi Node.js? Mendefinisikan 'node-version: [18, 20, 22]' dalam strategi matrix menyebabkan GitHub Actions memfanout job yang sama ke tiga runner paralel secara bersamaan. Karena ketiga versi berjalan sekaligus alih-alih berurutan, total waktu CI bisa dipotong hingga dua pertiga. Jika satu versi gagal, pemeriksaan keseluruhan ditandai gagal, memberikan sinyal kompatibilitas yang tepat. --- - HTML version: https://www.matthewswong.com/id/blog/ci-cd-pipeline-github-actions/ - English: https://www.matthewswong.com/en/blog/ci-cd-pipeline-github-actions/ - Site index for agents: https://www.matthewswong.com/llms.txt - Sitemap: https://www.matthewswong.com/sitemap.xml - API description (OpenAPI): https://www.matthewswong.com/openapi.json