Rapat Akibat Deployment Lambat (2015)

Deployment Lambat Memicu Rapat

• Rekayasa perangkat lunak adalah latihan kemampuan berhubungan dengan manusia. Keterampilan lain yang digunakan dalam pengembangan perangkat lunak juga demikian.
• Keluhan insinyur bahwa "terlalu banyak rapat hingga tidak bisa melakukan deployment kode" dapat terjadi karena keterbatasan kapasitas deployment.
• Chuck Rossi mengamati bahwa jumlah perubahan yang dapat ditangani dalam satu deployment di Facebook bersifat tetap. Jika ingin lebih banyak perubahan, dibutuhkan lebih banyak deployment.
• Facebook meningkatkan kecepatan deployment dari mingguan menjadi harian, kemudian tiga kali sehari dalam 5 tahun terakhir, dan juga mempercepat siklus deployment aplikasi seluler dari 6 minggu menjadi 4 minggu, lalu 2 minggu.
• "Perubahan per deployment" adalah metrik yang tidak elastis; peningkatannya mungkin, tetapi memerlukan waktu. Jika jumlah perubahan melebihi ambang batas saat ini, maka jumlah perubahan perlu dikurangi.
• Peningkatan overhead organisasi memicu loop umpan balik positif: pengurangan beban kerja -> kenaikan tekanan -> kenaikan kesalahan -> penurunan perubahan per deployment -> kenaikan overhead -> pengurangan beban kerja.
• Untuk memproses lebih banyak perubahan, kapasitas deployment harus ditingkatkan. Caranya bisa dengan mempercepat siklus deployment atau menaikkan jumlah perubahan per deployment.
• Upaya untuk mengurangi overhead dapat akhirnya berakhir pada rapat. Ini menahan usaha untuk mendeploy terlalu banyak kode.

Software Design: Tidy First?

• Rekayasa perangkat lunak adalah latihan hubungan manusia. Meningkatkan kemampuan teknis adalah salah satu cara untuk memperbaiki hubungan.

[roxie]

Saya suka pendapat ini.

[GN⁺]

Komentar Hacker News

• Meskipun penting untuk mengurangi risiko deployment dengan meningkatkan pengujian dan karakteristik organisasi, ini bukan satu-satunya pendekatan

  • Lebih efektif jika jumlah perubahan per deployment dikurangi
  • Mengirim perubahan kecil lebih sering memungkinkan nilai terkirim lebih cepat dan menghasilkan kegagalan yang lebih kecil
  • Jika digabungkan dengan canary deployment dan rollout bertahap, deployment tidak lagi menjadi risiko besar
  • Pendekatan ini didukung oleh riset DORA, Accelerate, The Phoenix Project, dan The Goal

• Menjelaskan konsep “literasi perangkat lunak”

  • Berarti kemampuan perusahaan untuk beroperasi menggunakan kode
  • Perusahaan dianggap kurang literasi perangkat lunaknya jika tidak semua pengambil keputusan fokus pada kode
  • Perusahaan harus bisa beroperasi dengan pendekatan yang baru

• Memutuskan untuk memfokuskan pemulihan karena waktu pengujian di pipeline CI menjadi lama

  • Menyederhanakan pengujian dan memfokuskan pemulihan, lalu menggunakan canary sebagai strategi deployment
  • Pendekatan ini terasa sebagai pengalaman yang menyegarkan

• Organisasi dapat menghalangi peningkatan deployment

  • Berusaha melawan birokrasi hampir tidak mungkin di sebagian besar organisasi
  • Deployment yang lambat adalah masalah, tetapi bukan satu-satunya

• Pengujian meningkat karena rasa takut terhadap perubahan besar

  • Ada kecenderungan rapat menjadi tujuan
  • Diperlukan saran tentang bagaimana mendorong perubahan teknis dan non-teknis

• Pertanyaan tentang mengapa CloudFormation lambat

• Microservices memungkinkan skala frekuensi deployment secara horizontal

• Performa software, yaitu performa manusia, penting

  • Untuk iterasi cepat dan menekan risiko, otomatisasi pengujian yang cepat diperlukan

• Deployment cepat memicu rapat respons insiden