Mengapa Squeaky tidak menggunakan lingkungan staging

Masalah staging

• pre-live tidak sama dengan production
• antrean rilis terbentuk
• rilis menjadi terlalu besar
• kurangnya ownership terhadap perubahan
• membiarkan proses menggantikan tanggung jawab

Cara Squeaky melakukan shipping

• Hanya merge hal-hal yang siap live: perubahan diuji secara memadai di lingkungan pengembangan lokal
• Menggunakan strategi branching yang datar: saat fitur siap di-merge, lakukan rebase lalu testing. Jika muncul masalah, roll forward
• Fitur berisiko tinggi selalu menggunakan feature flag
• Deployment manual: terus dipantau setelah perubahan. Monitoring/logging/alarm diterapkan secara menyeluruh. Deployment blue/green

Kesimpulan

• Untuk CI/CD yang sesungguhnya, meninggalkan lingkungan staging dapat membentuk pola pikir berbeda dalam shipping software
• Jika tidak ada buffer sebelum perubahan live, kita harus yakin perubahan tersebut layak untuk production
• Harus memiliki ownership atas setiap perubahan yang kita buat dan memberi perhatian penuh
• Biaya dan kompleksitas infrastruktur berkurang, serta lifecycle pengembangan dapat disederhanakan dan dipercepat

[edunga1]

Mengingat rasa aman yang saya rasakan saat membangun lingkungan staging di dalam organisasi, saya agak sulit berempati dengan hal itu.
Meski begitu, saya bisa memahami kekurangan seperti deployment yang tertunda atau perubahan yang menumpuk.

Saya tetap merasa keberadaan lingkungan staging itu sendiri bermakna, karena setidaknya kita bisa memastikan bahwa kita dapat melakukan deployment ke lingkungan lain dan bahwa sifat dasar perangkat lunak yang bisa direplikasi benar-benar terpenuhi.

[bichi]

Hmm, saya tidak yakin apakah ini sesuatu yang harus bergantung pada orang dengan "ownership" / "perhatian" yang tidak sempurna. Setidaknya, bukankah sebagai programmer komputer, kita seharusnya menerima bantuan dari komputer yang bisa bekerja sempurna sesuai instruksi?

Dan jika konsepnya diperluas, staging = untuk persetujuan final (untuk pengecekan seperti apakah ini pada akhirnya sama dengan spesifikasi yang kita bicarakan, atau ketika data produk dimasukkan ternyata tampilannya lebih jelek dari yang diperkirakan, dan semacamnya) dev = untuk diskusi tentang orang seperti developer dan fitur (untuk demo)

begitulah kami menggunakannya.

[xguru]

Hmm.. saya rasa masalah seperti ini bergantung pada layanan seperti apa yang sedang dikembangkan.
Seberapa pun banyak pengujian dilakukan, masalah tetap bisa muncul, dan yang perlu dipertimbangkan adalah apakah pengguna bisa menerimanya.
Perangkat lunak seperti Facebook, yang meski kadang tidak berfungsi dengan benar orang akan menganggapnya wajar, bisa memakai pendekatan seperti ini,
namun untuk infrastruktur yang mission-critical atau layanan berbayar, saya rasa perlu melakukan segala upaya agar masalah tidak terjadi.