Pelatihan Tertulis DevOps
Mengapa Perlu Menetapkan Tinjauan Berkelanjutan untuk Menjaga Mutu?
Organisasi Anda sangat bergantung pada tinjauan, audit, inspeksi, dan persetujuan menjelang penerapan ke produksi. Inspeksi biasanya dilakukan orang yang paling jauh hanya terlibat secara tidak langsung. Lebih buruk lagi, mereka terkadang salah memahami pekerjaan Anda dan harus diberi penjelasan tepat sebelum kode diterapkan.
Masalah Mekanisme Pengendalian Eksternal
Di banyak organisasi, membangun pengendalian lebih mudah daripada membangun kepercayaan. Karena itu, tambahan pertanyaan dalam formulir perubahan, tambahan lapisan persetujuan, dan tambahan waktu untuk memahami serta menyetujui perubahan adalah masalah umum pengendalian eksternal.
Lingkungan yang mengandalkan perintah dan kontrol serta minim kepercayaan akan terus menghadapi insiden yang berulang. Lingkaran masalah muncul karena pekerjaan dan masalah tidak terlihat jelas, dan pekerjaan dilakukan dalam batch besar agar penerapan yang sulit tidak sering terjadi. Pengiriman yang lambat mengurangi daya saing dalam memasuki pasar. Umpan balik yang lambat, terlambat, dan tidak bisa ditindaklanjuti membuat tim tidak bisa belajar dari kesalahan.
Organisasi DevOps yang kompeten tahu bahwa orang yang paling dekat dengan pekerjaan dan masalahnya adalah yang paling memahaminya. Pengendalian dan persetujuan eksternal tambahan tidak memberi nilai tambah. Ini menunjukkan tantangan besar bagi manajemen dan pemimpin saat ini: membangun budaya saling percaya, dengan pekerjaan yang transparan serta sikap saling menghargai dan saling percaya dalam keseharian.
Kurangi ketergantungan pada inspeksi berkala dan jadikan tinjauan sejawat bagian dari pekerjaan harian. Dorong pengembang, teknisi operasi, serta pakar penjaminan mutu dan keamanan informasi untuk terus berkolaborasi dan meninjau pekerjaan satu sama lain agar penerapan aman.
Koordinasi Pekerjaan yang Kompleks tanpa Pengendalian Eksternal
Pekerjaan sudah rumit jika dilakukan satu tim dan dapat menjadi lebih rumit ketika beberapa tim mengerjakan komponen berbeda dari sistem yang sama. Berikut beberapa langkah yang membantu:
- Dewan perubahan yang beranggotakan pakar bidang terkait, bukan hanya manajer, dapat membantu mengidentifikasi dependensi di antara berbagai tim sebelum perubahan dilakukan.
- Arsitektur dengan keterkaitan longgar berbasis SOA dan layanan mikro mengurangi dependensi dan upaya komunikasi.
- Perwakilan teknis tim DevOps sebaiknya menentukan dependensi serta urutan pengembangan dan penerapan.
- Berkomunikasi terus-menerus di platform obrolan bersama untuk menyelaraskan perubahan serta memahami dan memeriksa pemahaman pihak lain.
- Perubahan yang berdampak lebih besar dan lebih berisiko, seperti migrasi atau perubahan infrastruktur, memerlukan latihan di lingkungan pengujian dan langkah teknis seperti mekanisme failover dan pembatalan perubahan penuh.
Organisasi DevOps Berkinerja Tinggi Lebih Mengandalkan Tinjauan Sejawat daripada Persetujuan Eksternal
Banyak organisasi DevOps terkemuka, termasuk Amazon, Netflix, Etsy, dan GitHub, menggunakan proses tinjauan dan penerapan melalui “Pull Request”. Berikut cara kerjanya:
- Pengembang membuat cabang terpisah dari trunk. Cabang tidak seharusnya bertahan lebih dari beberapa hari kerja dan harus memiliki nama yang jelas, seperti “login-screen-v2”. Pengembang bekerja di cabang tersebut pada komputer lokal dan secara berkala memasukkan perubahan ke kontrol versi.
- Ketika merasa cabang siap digabungkan ke trunk, pengembang membuka pull request untuk meminta tinjauan.
- Setelah mendapat masukan dan persetujuan anggota tim DevOps lain, pengembang menggabungkan kode ke trunk, lalu menerapkannya ke produksi.
Untuk perubahan penting, seperti skema basis data atau perubahan yang dapat memengaruhi keamanan informasi, pengembang dapat mengirimkan pull request tambahan kepada pakar lain seperti administrator basis data atau spesialis keamanan informasi.
Gunakan batch kecil saat meninjau kode. Jika tidak, tinjauan lebih lama dan membebani peninjau. Semakin besar perubahan, risikonya meningkat secara eksponensial dan tinjauan menjadi kurang andal. Jika perubahan terlalu besar dan sulit dipahami, minta pengembang membaginya menjadi bagian yang lebih kecil dan mudah dipahami.
Setiap anggota tim DevOps, apa pun senioritas dan pengalamannya, harus meminta orang lain meninjau perubahannya. Semua orang harus memantau aliran commit agar potensi konflik cepat ditemukan dan diselesaikan sebelum menimbulkan masalah lebih besar di pipeline atau, lebih buruk, saat penerapan ke produksi.
Pemrograman berpasangan, baik sendiri maupun bersama pengembangan berbasis pengujian (TDD), memungkinkan tim melakukan tinjauan sejawat saat kode ditulis. Dalam gabungan tersebut, satu orang menulis kode dan satu orang menulis pengujian otomatis. Dengan ukuran tim dan persyaratan proyek yang sama, pemrograman berpasangan terbukti membutuhkan waktu 15% lebih lama tetapi mengurangi kesalahan kode sebesar 85%. Karena itu, praktik ini layak dipertimbangkan.
Pertimbangkan pula peninjauan langsung saat rekan bekerja, pemberitahuan otomatis mengenai commit, dan alat untuk membantu peninjauan serta meningkatkan mutu kode.
KESIMPULAN
Jadikan setiap tim bertanggung jawab atas mutu hasil kerjanya. Bangun budaya yang menghargai tinjauan kode bermutu dan berkelanjutan sama seperti penulisan kode bermutu.
