Infrastruktur sebagai Kode: Cara Mengatasi Masalah dengan XP

Halo, Habr! Sebelumnya, saya mengeluh tentang kehidupan di Infrastruktur sebagai paradigma kode dan tidak menawarkan apa pun untuk menyelesaikan situasi ini. Hari ini saya kembali untuk memberi tahu Anda pendekatan dan praktik apa yang akan membantu untuk keluar dari jurang keputusasaan dan mendapatkan situasi di jalur yang benar.



Dalam artikel sebelumnya "Infrastruktur sebagai kode: kenalan pertama" saya membagikan kesan saya tentang bidang ini, mencoba untuk merefleksikan situasi saat ini di bidang ini, dan bahkan menyarankan bahwa praktik standar yang diketahui oleh semua pengembang dapat membantu. Tampaknya ada banyak keluhan tentang kehidupan, tetapi tidak ada proposal untuk keluar dari situasi ini.

Siapa kita, di mana kita berada dan masalah apa yang kita miliki

Kami sekarang berada di Sre Onboarding Team, yang terdiri dari enam programmer dan tiga insinyur infrastruktur. Kita semua mencoba menulis Infrastruktur sebagai kode (IaC). Kami melakukan ini karena, pada prinsipnya, kami dapat menulis kode dan dalam sejarah kami adalah pengembang tingkat "di atas rata-rata".

• Kami memiliki serangkaian keunggulan: latar belakang tertentu, pengetahuan praktik, kemampuan menulis kode, keinginan untuk mempelajari hal-hal baru.
• Dan ada bagian yang melorot, itu juga minus: kurangnya pengetahuan tentang material infrastruktur.

Kesimpulan dari artikel terakhir saya adalah ini: Saya mencoba menginspirasi optimisme (terutama dalam diri saya), saya ingin mengatakan bahwa kami akan mencoba pendekatan dan praktik yang kami ketahui untuk menghadapi kesulitan dan kesulitan yang ada di area ini.

Kami sekarang berjuang dengan masalah IaC ini:

• Ketidaksempurnaan alat, alat pengembangan kode.
• Penempatan yang lambat. Infrastruktur adalah bagian dari dunia nyata, dan bisa lambat.
• Kurangnya pendekatan dan praktik.
• Kami baru dan tidak tahu banyak.

Extreme Programming (XP) untuk penyelamatan

Semua pengembang akrab dengan pemrograman ekstrim (XP) dan praktik di baliknya. Banyak dari kita yang mengerjakan pendekatan ini, dan itu berhasil. Jadi mengapa tidak memanfaatkan prinsip dan praktik yang ada di sana untuk mengatasi kesulitan infrastruktur? Kami memutuskan untuk menerapkan pendekatan ini dan melihat apa yang terjadi.


Mari kita lihat beberapa praktik dari XP dan bagaimana mereka memengaruhi kecepatan dan kualitas umpan balik.

Prinsip loop umpan balik XP

Dalam pemahaman saya, umpan balik adalah jawaban untuk pertanyaan, apakah saya melakukan yang benar, apakah kita pergi ke sana? Di XP, ada skema kecil ilahi dalam hal ini: loop umpan balik waktu. Yang menarik adalah semakin rendah kita, semakin cepat kita bisa mendapatkan OS untuk menjawab pertanyaan yang diperlukan.



Ini adalah topik yang agak menarik untuk dibahas bahwa dalam industri IT kita dimungkinkan untuk mendapatkan OS dengan cepat. Bayangkan betapa menyakitkannya melakukan proyek selama setengah tahun dan baru kemudian mengetahui bahwa kesalahan telah dilakukan di awal. Ini terjadi dalam desain, dan dalam setiap konstruksi sistem yang kompleks.

Dalam kasus kami, IaC membantu kami memberikan umpan balik. Segera saya melakukan sedikit penyesuaian pada diagram di atas: kami tidak memiliki rencana rilis bulanan, tetapi terjadi beberapa kali sehari. Beberapa praktik terkait dengan siklus OS ini, yang akan kami periksa lebih terinci.

Penting: umpan balik dapat menjadi solusi untuk semua masalah yang disebutkan di atas. Bersama-sama dengan praktik XP, itu dapat menarik keputusasaan keluar dari jurang maut.

Cara keluar dari jurang keputusasaan: tiga latihan

Tes

Tes disebutkan dua kali dalam loop umpan balik XP. Bukan hanya itu saja. Mereka sangat penting untuk semua teknik pemrograman ekstrim.

Diasumsikan bahwa Anda memiliki tes Unit dan Penerimaan. Beberapa memberi Anda umpan balik dalam beberapa menit, yang lain dalam beberapa hari, karena mereka ditulis lebih lama, dan jarang berjalan.

Ada piramida tes klasik, yang menunjukkan bahwa harus ada lebih banyak tes.



Bagaimana skema ini berlaku bagi kami dalam proyek IaC? Sebenarnya ... tidak ada.

• Tes unit, terlepas dari kenyataan bahwa harus ada banyak, tidak bisa sangat banyak. Atau mereka secara tidak langsung menguji sesuatu. Bahkan, kita dapat mengatakan bahwa kita tidak menulisnya sama sekali. Tetapi di sini ada beberapa aplikasi untuk tes semacam itu, yang masih berhasil kami lakukan:
  
  
  1. Menguji kode di jsonnet. Ini, misalnya, adalah perakitan pipa kami di drone, yang cukup rumit. Kode jsonnet tercakup dengan baik oleh tes.
     Kami menggunakan kerangka pengujian Unit ini untuk Jsonnet .
  2. Tes untuk skrip yang dieksekusi ketika sumber daya dimulai. Script dengan Python, dan karenanya tes untuk mereka, dapat ditulis.
• Verifikasi konfigurasi dalam pengujian berpotensi dilakukan, tetapi kami tidak melakukannya. Anda juga dapat mengkonfigurasi verifikasi aturan konfigurasi sumber daya melalui tflint . Namun, hanya untuk terraform ada pemeriksaan yang terlalu mendasar, tetapi banyak skrip uji ditulis untuk AWS. Dan kami berada di Azure, jadi ini tidak cocok lagi.
• Tes integrasi komponen: tergantung pada bagaimana Anda mengklasifikasikannya dan di mana Anda menempatkannya. Tetapi mereka pada dasarnya bekerja.
  
  Seperti inilah tes integrasi.
  
  
  
  Ini adalah contoh ketika merakit gambar di Drone CI. Untuk mencapai mereka, Anda harus menunggu 30 menit untuk mengumpulkan gambar Packer, lalu menunggu 15 menit lagi untuk berlalu. Tetapi mereka!
  
  
  Algoritma Validasi Gambar

  1. Pertama, Packer harus menyiapkan gambar sepenuhnya.
  2. Di sebelah tes ada terraform dengan keadaan lokal, yang kami gunakan untuk menyebarkan gambar ini.
  3. Saat menggunakan, modul kecil digunakan berbaring di sebelahnya sehingga lebih mudah untuk bekerja dengan gambar.
  4. Ketika VM digunakan dari gambar, Anda dapat mulai memeriksa. Sebagian besar pemeriksaan dilakukan dengan mobil. Ini memeriksa bagaimana skrip bekerja saat startup, bagaimana daemon bekerja. Untuk melakukan ini, melalui ssh atau winrm, kita pergi ke mesin yang baru saja dinaikkan dan memeriksa status konfigurasi atau apakah layanan telah meningkat.

  
  
• Situasi serupa dengan tes integrasi dan dalam modul untuk terraform. Berikut ini adalah tabel singkat yang menjelaskan fitur-fitur tes tersebut.
  
  
  
  Umpan balik pipa di area 40 menit. Semuanya butuh waktu yang sangat lama. Ini dapat digunakan untuk regresi, tetapi untuk perkembangan baru umumnya tidak realistis. Jika Anda benar-benar mempersiapkan ini, siapkan skrip yang sedang berjalan, Anda dapat menguranginya menjadi 10 menit. Tapi ini masih bukan tes Unit, yang 100 buah dalam 5 detik.

Tidak adanya Unit-tes selama perakitan gambar atau modul terraform mendorong untuk beralih kerja ke layanan terpisah yang hanya dapat ditarik oleh REST, atau ke skrip Python.

Sebagai contoh, kami perlu membuatnya sehingga ketika mesin virtual mulai , itu terdaftar sendiri di layanan ScaleFT , dan ketika itu sendiri hancur, itu dihapus sendiri.

Karena ScaleFT adalah layanan, kami terpaksa bekerja dengannya melalui API. Ada tertulis pembungkus yang dapat Anda tarik dan katakan: "Masuk dan hapus ini, itu." Ini menyimpan semua pengaturan dan akses yang diperlukan.

Kami sudah dapat menulis tes normal untuk ini, karena tidak berbeda dari perangkat lunak biasa dengan cara apa pun: beberapa apiha menjadi basah, Anda mencabut, dan lihat apa yang terjadi.

Hasil pengujian: Pengujian unit, yang seharusnya memberikan OS dalam satu menit, tidak memberikannya. Dan jenis pengujian yang lebih tinggi dalam piramida memberikan efek, tetapi hanya sebagian dari masalah yang dibahas.

Memasangkan pemrograman

Tes tentu saja bagus. Anda dapat menulis banyak dari mereka, mereka dapat dari berbagai jenis. Mereka akan bekerja di level mereka dan memberi kami umpan balik. Tetapi masalah dengan tes Unit yang buruk, yang memberikan OS tercepat, tetap ada. Pada saat yang sama, ia terus menginginkan OS yang cepat, mudah dan menyenangkan untuk bekerja dengannya. Belum lagi kualitas solusinya. Untungnya, ada teknik untuk memberikan umpan balik yang lebih cepat daripada tes unit. Ini adalah pemrograman berpasangan.

Saat menulis kode, saya ingin mendapatkan umpan balik tentang kualitasnya secepat mungkin. Ya, Anda dapat menulis semuanya di cabang fitur (agar tidak membocorkan apa pun kepada siapa pun), buat permintaan tarik di github, tetapkan ke seseorang yang pendapatnya berat, dan tunggu jawaban.

Tapi Anda bisa menunggu lama. Semua orang sibuk, dan jawabannya, bahkan jika itu, mungkin bukan yang tertinggi dalam kualitas. Misalkan jawabannya datang segera, pengulas langsung memahami seluruh gagasan, tetapi jawabannya tetap terlambat, setelah fakta. Tetapi saya menginginkan sesuatu sebelumnya. Berikut ini adalah pemrograman pasangan dan ditujukan untuk ini - sehingga segera, pada saat penulisan.

Berikut ini adalah gaya pemrograman pasangan dan penerapannya dalam mengerjakan IaC:

1. Klasik, Berpengalaman + berpengalaman, pengatur waktu berubah. Dua peran - pengemudi dan navigator. Dua orang. Mereka bekerja pada satu kode dan mengubah peran setelah periode waktu tertentu yang telah ditentukan.

Pertimbangkan kompatibilitas masalah kami dengan gaya:

• Masalah: ketidaksempurnaan alat, alat untuk pengembangan kode.
  Dampak negatif: untuk berkembang lebih lama, kita melambat, laju / ritme kerja tersesat.
  Cara bertarung: kami menggunakan penyetelan lain, sebuah IDE umum dan masih belajar cara pintas.
• Masalah: Deployment yang lambat.
  Dampak negatif: menambah waktu untuk membuat bagian kode yang berfungsi. Kami rindu saat menunggu, tangan ditarik untuk melakukan sesuatu yang lain saat Anda menunggu.
  Cara bertarung: tidak diatasi.
• Masalah: kurangnya pendekatan dan praktik.
  Efek negatif: tidak ada pengetahuan tentang bagaimana berbuat baik, tetapi seberapa buruk. Perpanjang umpan balik.
  Cara berkelahi: pertukaran pendapat dan praktik dalam berpasangan hampir memecahkan masalah.

Masalah utama dengan menerapkan gaya ini ke IaC pada kecepatan yang tidak rata. Dalam pengembangan perangkat lunak tradisional, Anda memiliki gerakan yang sangat seragam. Anda dapat menghabiskan lima menit dan menulis N. Luangkan 10 menit dan menulis 2N, 15 menit - 3N. Di sini Anda dapat menghabiskan lima menit dan menulis N, dan kemudian menghabiskan 30 menit lagi dan menulis sepersepuluh dari N. Di sini Anda tidak tahu apa-apa, Anda memiliki lelucon, tolol. Uji coba membutuhkan waktu dan mengalihkan perhatian dari pemrograman itu sendiri.

Kesimpulan: dalam bentuknya yang murni tidak cocok untuk kita.

2. Ping-pong. Pendekatan ini mengasumsikan bahwa satu peserta sedang menulis tes dan yang lainnya sedang melakukan implementasi untuknya. Karena semuanya rumit dengan Tes-unit, dan Anda harus menulis tes integrasi yang panjang, seluruh kemudahan ping-pong hilang.

Saya dapat mengatakan bahwa kami mencoba pemisahan tanggung jawab untuk merancang skrip pengujian dan menerapkan kode untuk itu. Salah satu peserta membuat naskah, di bagian pekerjaan yang menjadi tanggung jawabnya, ia memiliki kata terakhir. Dan yang lainnya bertanggung jawab untuk implementasi. Itu bekerja dengan baik. Kualitas skenario dengan pendekatan ini meningkat.

Kesimpulan: sayangnya, langkah kerja tidak memungkinkan penggunaan ping-pong, seperti praktik pemrograman pasangan di IaC.

3. Gaya Kuat. Latihan yang sulit . Idenya adalah bahwa satu peserta menjadi navigator direktori, dan yang kedua mengambil peran driver pelaksana. Dalam hal ini, hak untuk membuat keputusan secara eksklusif dengan navigator. Pengemudi hanya mencetak dan kata dapat mempengaruhi apa yang terjadi. Peran tidak berubah untuk waktu yang lama.

Sangat cocok untuk pelatihan, tetapi membutuhkan keterampilan lunak yang kuat. Tentang ini, kita goyah. Tekniknya sulit. Dan intinya di sini bahkan bukan infrastruktur.

Kesimpulan: berpotensi diterapkan, kita tidak menyerah.

4. Mobbing, berkerumun dan semua gaya yang terkenal, tetapi tidak tercantum di sini tidak dianggap, karena tidak mencoba dan mengatakan tentang hal itu dalam konteks pekerjaan kita tidak akan berhasil.

Hasil umum tentang penggunaan pemrograman pasangan:

• Kami memiliki kecepatan kerja yang tidak merata, yang merobohkan.
• Kami mengalami soft skill yang kurang bagus. Dan area subjek tidak berkontribusi untuk mengatasi kekurangan kami ini.
• Tes panjang, masalah dengan alat membuat pengembangan pasangan kental.

5. Meskipun demikian, ada keberhasilan. Kami datang dengan metode konvergensi kami sendiri - divergensi. Saya akan menjelaskan secara singkat cara kerjanya.

Kami memiliki mitra reguler selama beberapa hari (kurang dari seminggu). Kami melakukan satu tugas bersama. Untuk sementara kami duduk bersama: yang satu menulis, yang kedua duduk dan menonton sebagai tim pendukung. Kemudian kami tidak setuju untuk sementara waktu, semua orang melakukan beberapa hal independen, lalu kami bertemu lagi, menyinkronkan dengan sangat cepat, melakukan sesuatu bersama dan sekali lagi menyimpang.

Perencanaan dan komunikasi

Blok terakhir dari praktik di mana masalah OS diselesaikan adalah organisasi pekerjaan dengan tugas itu sendiri. Ini juga termasuk pertukaran pengalaman, yang merupakan pekerjaan pasangan luar. Pertimbangkan tiga praktik:

1. Tugas melalui pohon tujuan. Kami mengorganisir manajemen umum proyek melalui pohon yang berjalan tanpa akhir ke masa depan. Secara teknis, memimpin dilakukan di Miro. Ada satu tugas - itu adalah tujuan menengah. Entah tujuan atau kelompok tugas yang lebih kecil darinya. Dari mereka adalah tugas itu sendiri. Semua tugas dibuat dan dilakukan di forum ini.



Skema ini juga memberikan umpan balik yang terjadi sekali sehari ketika kami menyinkronkan di rapat umum. Kehadiran di depan semua orang dari rencana bersama, sementara terstruktur dan benar-benar terbuka, memungkinkan setiap orang untuk mengikuti apa yang terjadi dan seberapa jauh kita telah maju.

Keuntungan dari penglihatan tugas:

• Kausalitas. Setiap tugas mengarah ke beberapa tujuan global. Tugas dikelompokkan ke dalam tujuan yang lebih kecil. Domain infrastruktur itu sendiri cukup teknis. Tidak selalu jelas apa dampak spesifik pada bisnis yang diberikan, misalnya, dengan menulis buku peringkat tentang migrasi ke nginx lain. Kehadiran kartu target terdekat membuat ini lebih jelas.
  
  Sebab-akibat adalah sifat penting dari tugas. Itu langsung menjawab pertanyaan: "Apakah saya melakukannya?"
• Paralelisme. Ada sembilan dari kita, dan mustahil untuk menyerang semua orang dengan satu tugas secara fisik. Tugas dari satu area juga mungkin tidak selalu cukup. Kami dipaksa untuk bekerja paralel antara kelompok kerja kecil. Pada saat yang sama, kelompok duduk di tugas mereka selama beberapa waktu, mereka dapat diperkuat oleh orang lain. Orang-orang kadang-kadang jatuh dari kelompok kerja ini. Seseorang pergi berlibur, seseorang membuat laporan untuk konferensi conf DevOps, seseorang menulis artikel tentang Habr. Mengetahui tujuan dan sasaran apa yang dapat dilakukan secara paralel menjadi sangat penting.

2. Penyaji reli pagi yang bisa berubah. Di stand-up, kami mendapat masalah seperti itu - orang melakukan banyak tugas secara paralel. Kadang-kadang tugas digabungkan secara longgar dan tidak ada pemahaman tentang siapa yang melakukan apa. Dan pendapat anggota tim lain sangat penting. Ini adalah informasi tambahan yang dapat mengubah arah penyelesaian masalah. Tentu saja, biasanya seseorang dipasangkan dengan Anda, tetapi konsultasi dan tip selalu tidak berlebihan.

Untuk memperbaiki situasi ini, kami menerapkan teknik "Mengubah pimpinan terkemuka". Sekarang mereka berputar pada daftar tertentu, dan ini memiliki efek. Ketika sampai pada Anda, Anda dipaksa untuk terjun dan memahami apa yang terjadi untuk melakukan rapat scrum dengan baik.



3. Demo internal. Bantuan dalam memecahkan masalah dari pemrograman pasangan, visualisasi pada pohon tugas, dan bantuan di rapat umum scrum di pagi hari adalah baik, tetapi tidak sempurna. Dalam pasangan Anda hanya dibatasi oleh pengetahuan Anda. Pohon tugas membantu Anda memahami siapa melakukan apa secara global. Dan tuan rumah dan kolega di pertemuan pagi tidak akan terjun jauh ke dalam masalah Anda. Mereka pasti bisa melewatkan sesuatu.

Solusinya ditemukan dalam menunjukkan pekerjaan yang dilakukan satu sama lain dan diskusi berikutnya. Kami berkumpul seminggu sekali selama satu jam dan menunjukkan perincian solusi untuk tugas-tugas yang telah kami lakukan selama seminggu terakhir.

Dalam proses demonstrasi, perlu untuk mengungkapkan rincian tugas dan pastikan untuk menunjukkan kerjanya.


Setelah bagian penuh waktu, selalu ada diskusi di utas. Di sinilah umpan balik yang diperlukan pada tugas kami muncul.


Akibatnya, survei dilakukan untuk mengidentifikasi manfaat dari apa yang terjadi. Ini sudah merupakan umpan balik tentang esensi pidato dan pentingnya tugas.

Kesimpulan panjang dan apa selanjutnya

Tampaknya nada artikel tersebut agak pesimistis. Ini tidak benar. Dua tingkat umpan balik akar rumput, yaitu tes dan pemrograman pasangan, bekerja. Tidak sesempurna dalam perkembangan tradisional, tetapi ada efek positif dari ini.

Tes, dalam bentuk saat ini, hanya menyediakan sebagian cakupan kode. Banyak fungsi konfigurasi yang tidak diuji. Pengaruhnya terhadap kerja langsung ketika menulis kode rendah. Namun, ada efek dari tes integrasi, dan mereka yang memungkinkan untuk melakukan refactoring tanpa rasa takut. Ini pencapaian yang luar biasa. Juga, dengan transfer fokus ke pengembangan dalam bahasa tingkat tinggi (kami memiliki python, go), masalahnya hilang. Tetapi ada banyak pemeriksaan pada "lem" dan tidak perlu integrasi umum yang cukup.

Bekerja berpasangan lebih tergantung pada orang tertentu. Ada faktor tugas dan soft skill kita. Ternyata sangat baik dengan seseorang, lebih buruk dengan seseorang. Pasti ada manfaatnya. Jelas bahwa bahkan dengan ketaatan yang tidak memadai terhadap aturan kerja berpasangan, fakta pelaksanaan tugas bersama secara positif mempengaruhi kualitas hasilnya. Secara pribadi, lebih mudah dan lebih menyenangkan bagi saya untuk bekerja bersama.

Cara tingkat lebih tinggi untuk mempengaruhi OS - perencanaan dan bekerja dengan tugas-tugas justru memberikan efek: pertukaran pengetahuan berkualitas tinggi dan peningkatan kualitas pengembangan.

Kesimpulan pendek dalam satu baris

• Praktik XP bekerja di IaC, tetapi dengan efisiensi yang lebih rendah.
• Perkuat apa yang berhasil.
• Rancang mekanisme dan praktik kompensasi Anda sendiri.