Apa yang Kita Bangun Bersama: Pemahaman Praktis tentang CI/CD

Semua dimulai dari satu pertanyaan sederhana: bagaimana cara membawa perubahan pada aplikasi, database, dan infrastruktur ke tempat yang benar-benar digunakan orang, tanpa merusak pengalaman mereka?

Pertanyaan itu ternyata lebih sulit dari yang terdengar. Setiap tim yang pernah saya dampingi merasakan ketegangan antara kecepatan pengiriman dan keamanan. Beberapa tim menyelesaikannya dengan seremonial yang rumit. Tim lain menyelesaikannya dengan skrip yang hanya dipahami satu orang. Kedua pendekatan itu tidak scalable, dan keduanya menciptakan kecemasan di setiap deployment.

Tulisan ini memetakan fondasi yang kita bangun bersama di buku ini. Bukan ringkasan bab, melainkan peta bagaimana semua bagian saling terhubung ketika Anda berhenti memperlakukan CI/CD sebagai alat dan mulai memperlakukannya sebagai sebuah kemampuan.

Mulai dari Deployment, Bukan Pipeline

Sebelum Anda bisa mengotomatisasi apa pun, Anda perlu memahami apa arti deployment sebenarnya. Deployment adalah tindakan menempatkan versi baru dari sesuatu ke lingkungan yang bisa diakses pengguna. Kedengarannya jelas, tapi implikasinya tidak sesederhana itu.

Jika Anda mendeploy versi aplikasi yang buruk, Anda bisa menggantinya sepenuhnya. Jika Anda mendeploy migrasi database yang buruk, datanya tetap ada, dan rollback menjadi lebih kompleks. Jika Anda mendeploy perubahan infrastruktur yang merusak jaringan, tidak ada yang berfungsi.

Ketiga hal ini—aplikasi, database, dan infrastruktur—tidak bisa diperlakukan sama. Masing-masing memiliki strategi deployment sendiri. Aplikasi cocok dengan blue-green deployment, di mana Anda mengalihkan traffic di antara dua lingkungan identik. Database membutuhkan migrasi bertahap, di mana perubahan diterapkan dalam langkah-langkah kecil yang reversibel. Infrastruktur diuntungkan dengan pendekatan immutable, di mana Anda mengganti seluruh lingkungan alih-alih menambal.

Diagram di bawah menunjukkan tiga jalur paralel dan strategi yang direkomendasikan:

flowchart TD subgraph Application A1[New Version] --> A2[Blue-Green Deploy] A2 --> A3[Switch Traffic] A3 --> A4[Rollback if needed] end subgraph Database D1[Change] --> D2[Gradual Migration] D2 --> D3[Small Reversible Steps] D3 --> D4[Rollback Scripts] end subgraph Infrastructure I1[Config Change] --> I2[Immutable Replace] I2 --> I3[Replace Entire Environment] I3 --> I4[No Patching] end A1 -.->|different strategies| D1 D1 -.->|different strategies| I1

Intinya bukan untuk menghafal strategi-strategi ini. Intinya adalah menyadari bahwa deployment bukanlah satu tindakan tunggal. Deployment adalah serangkaian keputusan tentang bagaimana memindahkan perubahan dengan aman, dan keputusan itu tergantung pada apa yang Anda pindahkan.

Pipeline sebagai Kontrak, Bukan Skrip

Setelah Anda memahami deployment, Anda bisa membangun pipeline. Tapi pipeline bukanlah skrip yang menjalankan perintah. Pipeline adalah kontrak bahwa setiap perubahan harus melewati pemeriksaan yang sama, dalam urutan yang sama, di lingkungan yang konsisten, sebelum mencapai production.

Perbedaan ini penting karena tim sering memperlakukan pipeline sebagai otomatisasi dari proses manual yang sudah ada. Jika proses manual memiliki celah, pipeline akan mengotomatisasi celah itu juga. Pipeline yang baik dimulai dari pertanyaan: apa yang harus benar tentang suatu perubahan sebelum mencapai pengguna?

Untuk perubahan aplikasi, jawabannya mungkin mencakup lolosnya unit test, integration test, dan security scan. Untuk perubahan database, mungkin mencakup verifikasi bahwa migrasi bersifat reversibel dan rollback script tersedia. Untuk perubahan infrastruktur, mungkin mencakup menjalankan validasi terhadap staging environment yang live.

Membangun pipeline untuk ketiga jenis perubahan secara simultan adalah tantangan sesungguhnya. Sebagian besar tim memulai dengan satu jenis dan menambahkan yang lain belakangan. Itu tidak masalah, selama Anda tahu mana yang belum ada dan alasannya.

Deploy Bukan Release

Salah satu perbedaan paling berguna dalam buku ini adalah pemisahan antara deploy dan release.

Deploy adalah menempatkan versi baru di server. Release adalah membuat versi itu benar-benar digunakan oleh pengguna. Ketika Anda memisahkan dua tindakan ini, Anda mendapatkan kendali atas risiko. Anda bisa mendeploy versi, mengujinya di production dengan pengguna internal, dan baru me-release-nya ke semua orang ketika Anda yakin.

Pemisahan inilah yang memungkinkan strategi seperti feature flags, canary releases, dan progressive delivery. Feature flags memungkinkan Anda mengaktifkan dan menonaktifkan fungsionalitas tanpa mendeploy ulang. Canary releases mengirim persentase kecil traffic ke versi baru terlebih dahulu. Progressive delivery meningkatkan persentase itu secara bertahap sambil memantau metrik.

Tak satu pun dari strategi ini membutuhkan alat tertentu. Mereka membutuhkan pola pikir yang memperlakukan deploy dan release sebagai keputusan terpisah, masing-masing dengan profil risikonya sendiri.

Platform Engineering sebagai Akselerator

Ketika Anda memiliki banyak tim yang mengirimkan perubahan melalui pipeline, Anda mulai melihat pola. Setiap tim membutuhkan hal dasar yang sama: cara untuk membangun, menguji, dan mendeploy perubahan mereka; lingkungan yang konsisten untuk menjalankan pengujian; dan akses self-service ke infrastruktur.

Platform engineering adalah praktik membangun kemampuan-kemampuan ini sebagai produk internal. Platform bukanlah proyek besar yang harus selesai sebelum digunakan siapa pun. Platform dimulai dari kebutuhan nyata yang dimiliki tim, menyelesaikannya dengan baik, lalu berkembang seiring munculnya kebutuhan baru.

Wawasan kunci di sini adalah bahwa platform engineering bukan tentang membangun abstraksi yang sempurna. Ini tentang mengurangi beban kognitif tim sehingga mereka bisa fokus memberikan nilai. Jika sebuah tim menghabiskan dua hari untuk menyiapkan pipeline, platform tidak berfungsi. Jika mereka bisa membuat layanan baru dengan satu pull request, platform berfungsi.

Governance sebagai Guardrails, Bukan Gates

Governance sering disalahpahami sebagai lapisan yang memperlambat segalanya. Dalam praktiknya, governance di CI/CD adalah tentang menetapkan batasan yang memungkinkan tim bergerak cepat tanpa merusak sesuatu.

Kebijakan review untuk perubahan production, audit trail otomatis, dan aturan deployment berbasis risiko semuanya memiliki tujuan yang sama: menciptakan jalur yang jelas bagi perubahan untuk diikuti, sehingga tim tidak perlu menebak apa yang diizinkan atau menunggu persetujuan manual setiap saat.

Perbedaan antara governance sebagai gate dan governance sebagai guardrail halus tapi penting. Gate memblokir perubahan sampai seseorang menyetujuinya. Guardrail mendefinisikan jalur aman dan membiarkan tim bergerak bebas di dalamnya. Yang pertama menciptakan bottleneck. Yang kedua menciptakan otonomi.

Checklist Praktis

Jika Anda membangun kemampuan CI/CD di organisasi Anda, berikut adalah checklist singkat untuk memandu keputusan Anda:

  • Dapatkah Anda mendeploy perubahan ke production tanpa langkah manual?
  • Dapatkah Anda melakukan rollback deployment dalam waktu kurang dari lima menit?
  • Apakah Anda tahu perbedaan antara strategi deploy dan strategi release Anda?
  • Apakah setiap perubahan melewati pemeriksaan yang sama, terlepas dari siapa yang membuatnya?
  • Dapatkah anggota tim baru mendeploy perubahan pertamanya di hari pertama tanpa meminta izin?
  • Apakah Anda memiliki cara untuk menguji migrasi database sebelum mencapai production?
  • Apakah infrastruktur Anda diperlakukan sebagai kode, bukan sebagai server snowflake?

Jika Anda menjawab tidak untuk salah satu dari ini, Anda tahu di mana harus fokus selanjutnya.

CI/CD Adalah Kemampuan yang Harus Dirawat

Pelajaran terpenting dari perjalanan ini adalah bahwa CI/CD bukanlah proyek yang selesai. Ini adalah kemampuan yang harus dirawat. Alat berubah. Tim bertambah. Kebutuhan bergeser. Praktik yang berhasil hari ini mungkin tidak berhasil tahun depan.

Yang tetap konstan adalah pemahaman bahwa mengirimkan perubahan dengan aman adalah keterampilan, bukan skrip. Ini dibangun dari keputusan kecil yang dibuat setiap hari: bagaimana Anda menyusun pengujian, bagaimana Anda menangani kegagalan, bagaimana Anda menyeimbangkan kecepatan dan keamanan. Keputusan-keputusan ini bertambah seiring waktu, dan menentukan apakah tim Anda mengirim dengan percaya diri atau dengan ketakutan.

Mulailah dengan satu perubahan. Buatlah aman. Lalu buatlah repeatable. Lalu buatlah cepat. Sisanya akan mengikuti.