Apa yang Sebenarnya Terjadi Saat Developer Mendorong Kode

Laporan bug masuk. Seorang pengguna tidak bisa menyelesaikan pembayaran karena layar konfirmasi membeku. Developer membuka kode, menemukan masalah, menulis perbaikan, dan mengujinya secara lokal. Semuanya berfungsi di mesin mereka. Mereka mendorong perubahan ke repositori bersama.

Dorongan itu hanyalah awal. Apa yang terjadi selanjutnya menentukan apakah perbaikan itu mencapai pengguna dalam hitungan menit, jam, atau hari. Ini juga menentukan seberapa banyak stres, kebingungan, dan pengerjaan ulang yang dialami tim selama proses tersebut.

Mari kita telusuri perjalanan lengkap dari satu perubahan, dari laptop developer hingga produksi. Kita akan melihat apa yang sebenarnya dilakukan setiap peran, dan mengapa serah terima di antara mereka lebih penting daripada yang disadari kebanyakan tim.

Developer: Dari Lokal ke Bersama

Developer mulai dengan melakukan commit kode mereka ke version control. Commit hanyalah cuplikan perubahan yang disimpan ke repositori bersama seperti Git. Namun, melakukan commit saja tidak berarti perubahan sudah siap. Developer kemudian membuka pull request atau merge request, meminta perubahan mereka digabungkan ke branch utama.

Pada titik ini, pemeriksaan otomatis mulai berjalan. Kode dikompilasi atau dibangun menjadi sesuatu yang dapat dijalankan. Unit test berjalan untuk memverifikasi fungsi individual. Integration test memeriksa apakah berbagai bagian aplikasi bekerja bersama. Pemindaian keamanan dasar mungkin juga berjalan. Semua ini terjadi tanpa ada yang menyentuh keyboard.

Jika ada tes yang gagal, developer mendapat notifikasi. Mereka memperbaiki masalah, melakukan commit lagi, dan siklus berulang. Jika semua tes lulus, kode siap untuk tahap selanjutnya.

Di sinilah banyak tim terjebak. Pipeline hijau tidak berarti perubahan aman. Itu hanya berarti pemeriksaan otomatis lulus. Seseorang masih perlu melihat perubahan dari perspektif manusia.

Diagram urutan berikut mengilustrasikan perjalanan lengkap perubahan kode dari push developer hingga produksi, menunjukkan interaksi kunci antara peran dan sistem.

QA: Pengujian di Luar Otomatisasi

Quality assurance tidak dimulai saat build sudah siap. QA engineer biasanya menyiapkan skenario pengujian saat fitur atau perbaikan masih direncanakan. Mereka memikirkan kasus tepi, input yang tidak biasa, kondisi jaringan lambat, dan interaksi dengan bagian lain dari sistem.

Ketika build lolos pemeriksaan otomatis, QA mengambilnya dan menyebarkannya ke lingkungan staging. Staging adalah salinan produksi yang tidak diakses oleh pengguna nyata. Di sinilah pengujian manual terjadi.

QA menjalankan skenario yang telah disiapkan. Apakah fitur baru berfungsi seperti yang diharapkan? Apakah merusak hal lain? Apakah alur pengguna terasa alami? Mereka juga menjelajahi jalur yang mungkin terlewatkan oleh tes otomatis. Apa yang terjadi jika seseorang memasukkan string yang sangat panjang di kolom teks? Bagaimana jika koneksi database lambat?

Jika QA menemukan masalah, mereka melaporkannya ke developer. Developer memperbaikinya, melakukan commit lagi, dan siklus berulang hingga QA menyetujui. Bolak-balik ini normal. Ini bukan tanda kegagalan. Ini adalah cara tim menangkap masalah yang tidak bisa diprediksi oleh tes otomatis.

Poin utamanya adalah QA tidak hanya menguji di akhir. Mereka memengaruhi apa yang dibangun sejak awal. Tim yang memperlakukan QA sebagai gerbang terakhir akan selalu menemukan masalah terlalu lambat.

DevOps: Membawa Perubahan ke Produksi dengan Aman

Setelah QA menyetujui build, build tersebut pindah ke deployment. Di sinilah DevOps mengambil alih. DevOps engineer bertanggung jawab untuk membawa build yang telah disetujui ke produksi tanpa merusak apa pun.

Dalam pengaturan sederhana, deployment mungkin manual. Seorang DevOps engineer masuk ke server, menarik build terbaru, dan menjalankan perintah untuk menukar versi lama dengan yang baru. Dalam pengaturan yang lebih matang, deployment bersifat otomatis. Cukup dengan satu tekan tombol, atau bahkan pemicu otomatis setelah persetujuan QA, seluruh proses ditangani.

Namun deployment bukanlah akhir. Setelah versi baru aktif, DevOps memantau sistem. Apakah tingkat kesalahan normal? Apakah waktu respons dapat diterima? Bisakah pengguna mengakses fitur baru? Jika ada yang terlihat salah, DevOps dapat melakukan roll back ke versi sebelumnya sementara developer dan QA menyelidiki.

Fase pemantauan ini sering diabaikan. Tim merayakan deployment yang sukses dan melanjutkan, hanya untuk menemukan berjam-jam kemudian bahwa bug halus memengaruhi pengguna. Praktik DevOps yang baik mencakup mengawasi sistem setidaknya untuk waktu singkat setelah setiap deployment.

Serah Terima Lebih Penting daripada Alat

Salah satu kesalahpahaman umum adalah bahwa developer, QA, dan DevOps bekerja dalam jalur perakitan yang ketat. Developer selesai, menyerahkan ke QA, QA selesai, menyerahkan ke DevOps. Kenyataannya, mereka berkomunikasi sepanjang proses.

Seorang developer mungkin bertanya ke DevOps tentang konfigurasi lingkungan staging. QA mungkin meminta developer menambahkan tes otomatis tertentu. DevOps mungkin memberi tahu developer bahwa deployment terakhir memakan waktu lebih lama dari yang diharapkan karena konfigurasi yang hilang. Semakin lancar percakapan ini mengalir, semakin cepat perubahan mencapai pengguna.

Alat seperti pipeline CI/CD, kerangka kerja pengujian otomatis, dan otomatisasi deployment membantu. Tapi mereka tidak menggantikan komunikasi. Tim yang berkomunikasi dengan baik dengan alat dasar akan mengungguli tim yang menggunakan alat canggih tetapi tidak berkomunikasi sama sekali.

Ketika Peran Lain Masuk

Seiring tim berkembang dan frekuensi deployment meningkat, dua peran lagi sering muncul: Site Reliability Engineers (SRE) dan Platform Engineers.

SRE fokus pada keandalan. Mereka menetapkan service level objectives, memantau kesehatan sistem, dan membangun otomatisasi untuk menangani insiden. Mereka biasanya menjadi diperlukan ketika sebuah tim melakukan deployment beberapa kali sehari dan perlu memastikan setiap deployment tidak menurunkan sistem.

Platform Engineer membangun alat internal dan infrastruktur yang digunakan tim lain. Mereka menciptakan platform swalayan sehingga developer dapat melakukan deployment tanpa menunggu DevOps. Mereka menjadi diperlukan ketika organisasi memiliki banyak tim dan infrastruktur menjadi terlalu kompleks untuk dikelola setiap tim secara mandiri.

Peran-peran ini tidak menggantikan developer, QA, atau DevOps. Mereka memperluas kemampuan tim untuk menangani kecepatan dan kompleksitas yang lebih tinggi.

Daftar Periksa Praktis untuk Alur Perubahan

Gunakan daftar periksa ini untuk mengevaluasi bagaimana tim Anda menangani perubahan dari commit hingga produksi:

• Apakah setiap commit memicu build dan tes otomatis?
• Apakah QA menyiapkan skenario pengujian sebelum build siap?
• Apakah ada lingkungan staging yang mencerminkan produksi?
• Dapatkah DevOps melakukan roll back deployment dalam hitungan menit?
• Apakah seseorang memantau sistem setidaknya selama 30 menit setelah deployment?
• Apakah ada saluran komunikasi yang jelas antara developer, QA, dan DevOps selama proses?

Jika salah satu dari ini hilang, di situlah gesekan akan muncul.

Apa Artinya Ini untuk Tim Anda

Perubahan yang bergerak dari kode ke produksi bukanlah proses teknis dengan interupsi manusia. Ini adalah proses manusia yang didukung oleh alat teknis. Kualitas komunikasi antar peran menentukan seberapa cepat dan seberapa aman perubahan mencapai pengguna. Otomatisasi membantu, tetapi tidak dapat menggantikan serah terima yang jelas, pemahaman bersama, dan kemauan untuk melibatkan orang yang tepat pada waktu yang tepat.

Lain kali tim Anda mendorong perubahan, perhatikan serah terimanya. Di situlah pekerjaan sebenarnya terjadi.