Perubahan Infrastruktur Butuh Code Review, Sama Seperti Kode Aplikasi

Kamu punya server yang berjalan di production. Seseorang di tim perlu membuka port baru untuk alat monitoring. Mereka login ke cloud console, cari security group, tambah aturan, lalu simpan. Tidak ada orang lain yang tahu perubahan ini terjadi. Tiga hari kemudian, tim keamanan menjalankan audit dan menemukan port terbuka yang seharusnya tidak ada. Tidak ada yang ingat siapa yang membukanya atau mengapa.

Skenario ini terjadi di tim yang memperlakukan perubahan infrastruktur berbeda dari perubahan kode aplikasi. Tim yang sama yang mewajibkan pull request, peer review, dan approval untuk perbaikan bug satu baris di aplikasi, akan membiarkan seseorang SSH ke server dan mengubah file konfigurasi secara langsung. Ketidakkonsistenan ini menciptakan risiko, kebingungan, dan firefighting yang tidak perlu.

Mengapa Perubahan Infrastruktur Layak Mendapatkan Ketelitian yang Sama

Ketika kamu menulis infrastruktur sebagai kode, kamu menyimpan konfigurasi server, aturan jaringan, pengaturan database, dan definisi deployment di Git. File-file ini menjelaskan secara persis bagaimana infrastruktur kamu seharusnya terlihat. Perubahan pada file-file ini bisa memiliki konsekuensi yang sama seriusnya dengan perubahan pada kode aplikasi.

Bayangkan apa yang terjadi ketika seseorang memodifikasi aturan firewall. Satu port yang salah konfigurasi bisa mengekspos data pelanggan ke internet. Ukuran instance database yang salah bisa menyebabkan degradasi performa atau lonjakan biaya yang tidak terduga. Pengaturan load balancer yang tidak tepat bisa membuat seluruh aplikasi offline. Ini bukan risiko hipotetis. Ini terjadi secara rutin di tim yang melewatkan proses review untuk perubahan infrastruktur.

Masalahnya bukan karena orang membuat kesalahan. Semua orang membuat kesalahan. Masalahnya adalah ketika perubahan infrastruktur terjadi tanpa review, kesalahan tidak akan terdeteksi sampai sesuatu rusak. Dan ketika sesuatu rusak, tidak ada catatan tentang apa yang berubah, siapa yang mengubahnya, atau mengapa.

Bagaimana Pull Request Bekerja untuk Infrastruktur

Jika infrastruktur kamu didefinisikan sebagai kode di Git, proses review bekerja persis seperti untuk kode aplikasi. Seseorang membuat branch, melakukan perubahan pada file infrastruktur, dan membuka pull request. Anggota tim lain meninjau perubahan, meninggalkan komentar, meminta perbaikan, atau menyetujui perubahan. Setelah disetujui, perubahan digabungkan ke branch utama, dan pipeline menerapkannya.

Proses ini bukan hal baru atau rumit. Ini adalah alur kerja yang sama yang telah digunakan tim pengembang selama bertahun-tahun. Satu-satunya perbedaan adalah apa yang sedang direview. Alih-alih meninjau logika aplikasi, kamu meninjau definisi konfigurasi.

Apa yang Harus Diperiksa Saat Review Infrastruktur

Saat kamu meninjau pull request infrastruktur, ada beberapa hal yang perlu diperiksa.

Pertama, apakah perubahan tersebut masuk akal untuk kebutuhan yang ada? Jika seseorang membuka port, apakah mereka benar-benar membutuhkan port itu? Apakah ada alternatif yang lebih aman? Apakah perubahan tersebut selaras dengan apa yang telah disepakati tim?

Kedua, apakah konfigurasinya benar? Periksa sintaks. Verifikasi bahwa nomor port, ukuran instance, dan blok CIDR jaringan sudah akurat. Cari aturan keamanan yang terlalu permisif. Aturan yang mengizinkan traffic dari 0.0.0.0/0 ke port 22 hampir selalu merupakan tanda bahaya.

Ketiga, apakah perubahan tersebut konsisten dengan lingkungan lain? Jika lingkungan staging menggunakan tipe instance tertentu atau ukuran database tertentu, lingkungan production seharusnya tidak tiba-tiba menggunakan sesuatu yang sama sekali berbeda tanpa alasan yang terdokumentasi. Ketidakkonsistenan antar lingkungan adalah sumber umum masalah deployment.

Keempat, apakah perubahan tersebut mengikuti konvensi penamaan dan standar tagging tim? Penamaan yang konsisten memudahkan untuk memahami untuk apa suatu resource dan siapa pemiliknya. Tag membantu dalam alokasi biaya dan manajemen resource.

Catatan Historis

Setiap pull request yang disetujui dan digabungkan menjadi catatan permanen tentang apa yang berubah, siapa yang mengubahnya, dan kapan. Jejak historis ini sangat berharga ketika terjadi masalah.

Bayangkan kamu terbangun dan menemukan bahwa aplikasi production tidak dapat diakses. Kamu memeriksa perubahan terbaru di repositori infrastruktur dan melihat pull request yang memodifikasi konfigurasi load balancer dua jam yang lalu. Kamu bisa langsung melihat apa yang berubah, mendiskusikannya dengan orang yang melakukan perubahan, dan memutuskan apakah akan rollback atau fix forward.

Tanpa catatan ini, kamu hanya akan menebak-nebak. Kamu akan bertanya ke seluruh tim, memeriksa log chat, dan melihat log aktivitas cloud console. Prosesnya lebih lama dan kurang dapat diandalkan. Riwayat pull request memberikan jawaban langsung.

Mengatasi Kekhawatiran tentang Kecepatan

Beberapa tim menolak review infrastruktur karena mereka pikir itu memperlambat segalanya. Mereka berargumen bahwa perubahan infrastruktur perlu terjadi dengan cepat, terutama selama insiden atau pembaruan mendesak.

Kenyataannya, waktu yang dihabiskan untuk review hampir selalu lebih sedikit daripada waktu yang dihabiskan untuk pemulihan dari perubahan yang tidak direview yang merusak production. Review lima menit bisa mencegah downtime dua jam. Matematikanya sederhana.

Untuk perubahan mendesak selama insiden, kamu bisa menyesuaikan prosesnya. Beberapa tim menggunakan model post-incident review di mana perubahan diterapkan terlebih dahulu untuk memulihkan layanan, dan pull request dibuat serta direview setelahnya. Kuncinya adalah review tetap dilakukan, dan perubahan tetap didokumentasikan. Prosesnya bisa melentur untuk keadaan darurat, tetapi tidak hilang.

Apa yang Terjadi Setelah Review

Setelah perubahan infrastruktur lolos review dan digabungkan, pekerjaan belum selesai. Pipeline perlu menunjukkan apa yang sebenarnya akan berubah sebelum menerapkannya. Ini adalah langkah plan. Pipeline membandingkan keadaan yang diinginkan (desired state) yang didefinisikan dalam kode dengan keadaan infrastruktur saat ini dan menunjukkan perbedaannya. Hanya setelah meninjau plan dan mengonfirmasi bahwa itu terlihat benar, pipeline melanjutkan untuk menerapkan perubahan.

Langkah plan ini sangat penting. Bahkan dengan code review yang teliti, plan bisa mengungkapkan efek yang tidak terduga. Perubahan yang terlihat benar dalam kode bisa menghasilkan plan yang menghapus dan membuat ulang resource, yang bisa menyebabkan downtime. Plan memberi kamu satu kesempatan terakhir untuk menangkap masalah sebelum mencapai production.

Daftar Periksa Praktis untuk Pull Request Infrastruktur

• Apakah perubahan sesuai dengan kebutuhan atau permintaan yang sebenarnya?
• Apakah semua nilai sudah benar (port, ukuran instance, rentang CIDR)?
• Apakah aturan keamanan sudah serestriktif mungkin sambil tetap mengizinkan traffic yang diperlukan?
• Apakah perubahan konsisten dengan lingkungan lain?
• Apakah mengikuti konvensi penamaan dan tagging?
• Apakah ada output plan yang menunjukkan apa yang akan berubah sebelum diterapkan?

Kesimpulan

Perubahan infrastruktur layak mendapatkan proses review yang sama seperti perubahan kode aplikasi. Konsekuensi dari perubahan infrastruktur yang buruk seringkali lebih parah dan lebih sulit didiagnosis daripada perubahan kode yang buruk. Pull request menyediakan cara terstruktur untuk menangkap kesalahan, menegakkan standar, dan memelihara catatan historis. Waktu yang kamu investasikan untuk meninjau perubahan infrastruktur adalah waktu yang tidak akan kamu habiskan untuk debugging outage production yang disebabkan oleh perubahan konfigurasi yang tidak direview. Perlakukan kode infrastruktur kamu dengan perhatian yang sama seperti kode aplikasi kamu, dan lingkungan production kamu akan berterima kasih.