Strategi promosi ketergantungan: dibungkam atau diatur?

Kami memiliki banyak aplikasi dan layanan web (beberapa produk yang menghadap publik, beberapa internal dan bagian dari "backend" pribadi) yang saling bergantung satu sama lain. Masing-masing komponen ini memiliki 4 lingkungan (kelompok server / node yang melayani tujuan tertentu):

• Non-produksi
  • DEV- Lingkungan pengembangan terintegrasi di mana CI membangun perubahan push; berguna bagi insinyur untuk memecahkan bug yang sulit ditemukan yang tidak dapat direproduksi secara lokal
  • QA - Lingkungan QA / Pengujian yang terisolasi
  • DEMO - Lingkungan UAT yang stabil untuk pemangku kepentingan bisnis
• Produksi
  • LIVE - Lingkungan hidup / produksi kami

Promosi kode berlaku: LOCAL(mesin pengembang) => DEV=> QA=> DEMO=> LIVE.

Katakanlah kita memiliki aplikasi bernama myappyang didukung oleh layanan web RESTful yang disebut myws, yang itu sendiri didukung oleh DB yang disebut mydb.

Saat ini, kami memiliki apa yang saya sebut promosi " mengatur " di antara dependensi ini: myapp-devpoin myws-devyang digunakan mydb-dev. Demikian pula, myapp-qapoin myws-qayang digunakan mydb-qa. Sama untuk DEMOdan LIVE.

Masalahnya adalah kapan saja saya membuat perubahan, katakanlah myapp, ini mengharuskan saya untuk melakukan perubahan mywsdan mydbjuga. Tetapi karena masing-masing DEVlingkungan menunjuk ke lingkungan ketergantungannya DEV, itu berarti saya harus menjadwalkan dan meluncurkan semua perubahan ini secara bersamaan. Selain itu, jika satu bangunan menjadi tidak stabil / rusak, sering kali komponen downstream lainnya turun; misalnya jika pengembang merusak sesuatu saat mengubah mydb-dev, the myws-devdanmyapp-dev cluster biasanya juga menjadi tidak stabil.

Untuk mengatasi ini, saya menyusun proposal untuk apa yang saya sebut strategi promosi " siled ": semua dependensi antar-komponen ikuti panduan ini:

• Ketergantungan hulu tergantung pada DEMOlingkungan untuk dependensi hilir mereka, untuk semua lingkungan non-produksi mereka ( DEV, QAdanDEMO ); dan
• Ketergantungan hulu tergantung pada LIVElingkungan untuk ketergantungan hilir untuk lingkungan produksi mereka

Menggunakan konvensi ini, myapp-devakan menunjukkan myws-demo, yang akan digunakan mydb-demo. Demikian pula, myapp-qajuga akan menunjuk ke myws-demodan mydb-demo.

Keuntungan di sini yang dapat saya temukan adalah membangun stabilisasi : sangat kecil kemungkinannya bahwa DEMOlingkungan untuk komponen tertentu akan menjadi tidak stabil, karena kode tidak dapat membuatnya DEMOtanpa pengujian yang ketat baik pada DEVdan QA.

Satu-satunya kelemahan saya dapat menemukan metode ini adalah bahwa, jika DEMOtidak pecah untuk komponen tertentu, semua lingkungan non-produksi untuk semua dependensi hulu tiba-tiba akan rusak. Tetapi saya akan membantah bahwa ini harus terjadi sangat jarang karena pengujian dilakukan pada DEVdanQA .

Ini harus menjadi masalah yang telah dipecahkan oleh banyak pengembang (jauh lebih pintar dan berpengalaman dari saya), dan saya tidak akan terkejut jika masalah ini dan solusinya sudah memiliki nama untuk mereka (selain apa yang saya sebut diatur / didiamkan). Jadi saya bertanya: Apakah manfaat dari strategi promosi yang dibungkam lebih besar daripada kontra, dan apa kontra yang mungkin saya hadapi di sini?

Jika saya membaca posting Anda dengan benar, sepertinya proposal ini tidak benar-benar menyelesaikan salah satu masalah yang dituduhkan.

kapan saja saya melakukan perubahan, katakanlah, aplikasi saya, ini mengharuskan saya untuk membuat perubahan ke myws dan mydb juga. Tetapi karena setiap lingkungan DEV menunjuk ke lingkungan DEV dependensinya, itu berarti saya harus menjadwalkan dan meluncurkan semua perubahan ini secara bersamaan.

"Strategi promosi siled" sepertinya hanya akan memperburuk ini. Jika myapp v2, myws v2 dan mydb v2 hanya pada DEV, dan myapp v2 bergantung pada mydb v2 untuk tidak crash, maka ketika saya mencoba menjalankan myapp v2 pada DEV saya akan menekan mydb v1 DEMO dan crash. Anda pada dasarnya akan dipaksa untuk terus-menerus menimpa silo, atau menggunakan mydb v2 sampai ke prod sebelum Anda bahkan dapat mulai bekerja di myapp v2. Lebih penting lagi, Anda tidak akan pernah menguji mydb v2 pada DEV, jadi jika rusak Anda bahkan tidak mengetahuinya sampai rusak pada DEMO, dan kemudian Anda kembali ke titik awal.

Sampai batas tertentu, masalah yang Anda uraikan tidak dapat dihindari tidak peduli bagaimana alur kerja Anda diatur, tetapi hal itu dapat diminimalkan. Triknya adalah untuk memastikan bahwa antarmuka antara mydb dan myws (dan antarmuka antara myws dan myapp) didefinisikan secara ketat, dan mengharuskan semua pembaruan pada antarmuka itu agar kompatibel sepenuhnya ke belakang . Di pekerjaan saya, kami memiliki skema XML yang mendefinisikan antarmuka antara aplikasi dan layanan kami, dan banyak dari alat internal kami tidak akan membiarkan kami membuat pembaruan yang tidak kompatibel dengan skema tersebut.

Selain itu, jika satu bangunan menjadi tidak stabil / rusak, sering kali komponen downstream lainnya turun; misalnya jika pengembang merusak sesuatu ketika mengubah mydb-dev, myws-dev dan myapp-dev cluster biasanya juga menjadi tidak stabil.

Bagi saya ini terdengar seperti masalah serius, tetapi bukan masalah penyebaran. Basis data yang rusak tentu akan mencegah layanan dan aplikasi tidak berfungsi dengan baik, tetapi seharusnya tidak menjadi "tidak stabil". Mereka seharusnya mengembalikan beberapa pesan kesalahan, sehingga siapa pun yang menjalankan myapp di dev melihat "Maaf, basis data kami mengalami masalah hari ini" bukannya hanya macet.

Jika masalahnya adalah database yang rusak menyebabkan masalah ini sama sekali, maka yang dapat Anda lakukan adalah menyiapkan beberapa sistem "siloing sementara" yang memungkinkan Anda mengatakan "mydb DEV rusak sekarang, silakan rutekan semua kueri DEV myws ke mydb DEMO untuk saat ini". Tapi ini seharusnya hanya menjadi cara untuk melakukan perbaikan sementara sampai mydb DEV bekerja normal kembali. Jika semuanya "siled" seperti itu secara default, maka Anda kembali pada masalah yang saya jelaskan di atas karena tidak ada yang pernah berjalan melawan mydb DEV sama sekali.

Saya merasa sepertinya saya salah mengerti proposal Anda, tapi semoga jawaban ini setidaknya menjelaskan apa yang disalahpahami dan cara terbaik untuk mengulanginya.