Bagaimana cara menghindari ketidakstabilan yang disebabkan integrasi terus menerus di lingkungan pengujian?


19

Asumsikan Anda menggunakan proses integrasi berkelanjutan yang sering memperbarui beberapa lingkungan target, sehingga setiap kali ada perubahan "Anda" dapat menguji perubahan Anda segera. Itu bagian dari tujuan CI, bukan?

Tetapi, juga asumsikan bahwa Anda memiliki orang lain yang terlibat dalam siklus pengujian Anda, mis. Manajer atau pelanggan. Masuk akal untuk melibatkan orang lain dalam mencoba meninjau (menghancurkan?) Perubahan Anda yang akan datang, bukan?

Tetapi jika Anda terus menerus memberikan perubahan dalam lingkungan di mana orang-orang itu, dengan serius, mencoba mengujinya, maka beberapa masalah dapat muncul, seperti:

  • they mungkin membuang-buang waktu mereka dalam melaporkan masalah yang, pada saat mereka menyimpan laporan (mendalam), mereka bahkan tidak dapat mereproduksi masalah itu sendiri (mis. karena secara tidak sengaja Anda juga mengalami masalah yang sama, dan sudah memperbaikinya di lingkungan mereka).
  • you mungkin tidak dapat mereproduksi masalah yang mereka laporkan, karena lingkungan tempat mereka mengalami masalah, tidak lagi identik (Anda (!!!) mungkin telah overlay lingkungan mereka).

Jadi, apa yang dapat Anda lakukan (bagaimana mengkonfigurasi hal-hal?) Untuk menghindari situasi (frustasi) seperti itu?

Jawaban:


10

Saya akan memberikan pengalaman saya pada yang satu ini, sebagian besar karena ini menunjukkan mengapa beberapa jawaban tidak selalu berlaku.

Beberapa konteks untuk memulai:

  • Kami memiliki 7 lingkungan untuk menampung sekitar 80 aplikasi, kebanyakan dari mereka bergantung satu sama lain melalui layanan web atau tabel bersama pada db2-iSeries.
  • Baik atau buruk, iSeries adalah sistem referensi DB kami.
  • Poin terakhir ini membatalkan ide membawa aplikasi dengan dependensinya di lingkungan yang terisolasi karena memunculkan AS400 untuk masing-masing akan terlalu mahal dan kami tidak akan memiliki perangkat keras untuk menjalankannya.

Apa yang kami lakukan bukanlah Pengiriman Berkelanjutan otomatis yang lengkap, kami memiliki jadwal rilis untuk memunculkan banyak aplikasi yang koheren untuk operasi umum. Selain itu, setiap tim pengujian dapat memicu pelepasan di salah satu lingkungan T / A untuk aplikasi yang mereka uji dan dapat mengunci beberapa versi aplikasi untuk menghindari permintaan tim lain yang melanggar tes mereka.

Ketergantungan aplikasi diperiksa sebelum dirilis, sehingga sistem tidak akan merilis sesuatu jika aplikasi lain tidak dapat diperbarui atau tidak sesuai dengan ketergantungan yang diperlukan. Gagasan utamanya adalah untuk memungkinkan pembaruan ketika itu tidak akan berdampak pada seseorang, jika tidak ada tes yang direncanakan, itu harus mengalir dari lingkungan sebelumnya (dan kami bertujuan untuk menghapus rilis yang dijadwalkan di 5 lingkungan pertama pada jangka menengah sekarang kami memiliki memvalidasi sistem metode 'on demand' ini).

Versi singkatnya adalah memiliki sistem 'semaphore' di sekitar aplikasi di lingkungan, tim harus dapat mengunci aplikasi targetnya dengan dependensinya (dan dependensi transitif) untuk saat tes manual.
Implementasi semaphore ini sangat tergantung pada sistem otomasi Anda, jadi saya tidak akan mengembangkannya.

Tentu saja cara yang mudah adalah, seperti yang disebutkan lainnya, untuk menciptakan lingkungan yang segar untuk aplikasi dengan segala ketergantungannya untuk menghindari semaphore yang dijelaskan di atas.


Jawaban ini adalah variasi dari apa yang saya terbiasa (mainframe), di mana kita melakukan hal-hal semacam ini setidaknya selama 1,5 dekade (sebelum "DevOps" lahir). Saya bertanya-tanya apakah masuk akal untuk menambahkan jawaban saya sendiri di sini (untuk lebih memperluas jawaban ini, bagaimana kita melakukan ini dengan CMN / ZMF untuk misalnya "bank"), atau hanya membawanya ke pertanyaan baru (jawab sendiri). Bagaimana menurut anda? Juga, saya ingin tahu tentang hal metafora itu, layak pertanyaan baru (dengan merujuk pada jawaban ini)? PS: Anda keberatan kalau saya memperbaiki beberapa kesalahan ketik?
Pierre.Vriens

Tidak ada masalah untuk diedit :) Saya tetap membuatnya generik, Itu tidak banyak yang spesifik untuk IMHO org. Sekali lagi DevOps adalah perubahan organisasi, yang dapat membantu menyiapkan otomatisasi yang lebih baik dengan berbagi keprihatinan ... jadi saya menyebut ini semafor seperti dalam program, saya tidak berpikir itu layak pertanyaan tapi itu terserah Anda
Tensibai

Oke, edit selesai (seperti biasa: kembalikan / tingkatkan sesuai keinginan Anda). BTW, apakah Anda memiliki "s" di keyboard Anda?!?!?! Terlepas dari itu: hal-hal yang perlu dipikirkan selama akhir pekan: lihat pertanyaan meta terbaru saya ... Bon weekend! Saatnya berkebun di sini (pemangkasan ...)
Pierre.Vriens

8

Terdengar seperti Anda sedang berbicara tentang lingkungan tes yang terus-menerus kembali digunakan tanpa andal kembali diinisialisasi untuk setiap pelaksanaan tes. Ini membuat tes semacam itu tidak dapat diandalkan. Serupa, dari perspektif keandalan, dengan pengujian manual, jika Anda mau.

IMHO Anda tidak boleh menggunakan pengujian seperti itu di dalam tujuan kualifikasi CI / CD Anda karena itu akan secara efektif membatalkan proses kualifikasi Anda (setidaknya di area itu). Mengatakan bahwa perangkat lunak lolos tes X tanpa benar-benar menjalankan tes X untuk setiap versi perangkat lunak yang dikirim atau tanpa kepastian bahwa passhasil yang diperoleh tidak disengaja (karena kesalahan positif) akan mengikis tingkat kepercayaan pengujian Anda. Negatif palsu tidak merusak kredibilitas, tetapi mereka juga tidak diinginkan karena "kebisingan" yang mereka buat tidak perlu.

Tidak apa-apa untuk melakukan pengujian seperti itu di luar proses kualifikasi CI / CD Anda. Tetapi Anda akan memperlakukan hasil yang gagal dalam pengujian tersebut seperti bug yang ditemukan pelanggan: Anda harus mereproduksi masalah dengan andal agar dapat mengembangkan perbaikan untuk itu dan mengonfirmasi bahwa perbaikan tersebut berfungsi. Dan Anda tidak dapat benar-benar melakukannya jika pengujian tidak dapat diandalkan.

Jika Anda berencana untuk mengatasi masalah ini maka idealnya Anda pertama kali akan mengembangkan kasus pengujian otomatis dan andal untuk mereproduksi masalah tersebut. Yang akan Anda gunakan untuk mengembangkan perbaikan dan mengonfirmasi keefektifannya (hasil tes harus beralih dari FAIL ke PASS). Anda dapat (harus?) Juga meletakkan testcase ini di dalam proses kualifikasi CI / CD Anda untuk mencegah kemunculan kembali di masa mendatang, jika diinginkan - untuk meningkatkan tingkat kualitas rilis perangkat lunak Anda secara keseluruhan.


Ada banyak yang harus dicerna dalam jawaban Anda (saya tidak yakin saya sudah mendapatkannya sepenuhnya). Tetapi apa yang Anda tulis tentang " jalankan pengujian semacam itu di luar proses kualifikasi CI / CD Anda ": Saya berharap bahwa hasil akhir dari apa yang dihasilkan / dikirim disimpan di lingkungan QA dan prod Anda (melalui CD, baik otomatis atau manual). Tapi itu juga " nampaknya " bagi saya bahwa CI juga harus memberikan outputnya di sana, sementara "di luar" tampak seperti pemisahan atau duplikasi atau sesuatu, bukan?
Pierre.Vriens

The insidedan outsidereferensi relatif terhadap loop verifikasi CI. Pada dasarnya saya mempertanyakan alasan keberadaan lingkungan QA - sebagian besar tes yang dilakukan di sana harus dapat diandalkan dan akhirnya dieksekusi sebagai bagian dari verifikasi CI, terutama dalam konteks penyebaran berkelanjutan - karena Anda ingin menjalankannya pada setiap iterasi CI (berhasil setidaknya sampai titik itu).
Dan Cornilescu

7

Pendekatan yang biasa adalah menciptakan lingkungan yang berbeda:

DEV - ini adalah tempat di mana tim dev mengacaukan semuanya. Berikut adalah buat semua perubahan tala, menyebarkan versi baru dan sebagainya. Di sinilah tempat CI terintegrasi sepenuhnya.

PREPROD / QA - ini adalah tempat "bermain" QA / tes / tim validasi melakukan tes. Lingkungan ini biasanya membeku selama tes. Integrasi CI dengan lingkungan ini hanya untuk menyediakan versi baru dari produk, konfigurasi, dll.

PRODUKSI - apakah perlu dijelaskan :)?


ok, itu seharusnya membantu meningkatkan stabilitas, merci! Pertanyaan saya adalah tentang lingkungan "uji", jadi jelas "produksi" tidak boleh dianggap demikian. Meskipun mereka yang menggunakan "produksi" untuk pengujian, Anda tahu pepatah " Tes terbaik adalah mengaktifkannya dalam produksi, dan jika itu tidak berhasil, lakukan saja rollback / backout! "?
Pierre.Vriens

@ Pierre.Vriens, "bermain" di prod IMHO tidak bijaksana :) Pemisahan lingkungan seperti itu disengaja. Pada pekerjaan sebelumnya kami memiliki 5 lingkungan yang berbeda .... Layanan
pemilih

1
"Saya" setuju bahwa permainan seperti itu tidak bijaksana. Namun apa yang dapat "kamu" lakukan terhadap para koboi ('istilah' saya yang saya gunakan untuk juppies seperti itu) yang terus melakukan ini berulang-ulang, dan setiap kali mereka mendapat persetujuan dari manajer mereka untuk menyiasati (misalnya) aktivasi rilis bulanan , dengan perbaikan bug lain (mis. untuk perbaikan bug mereka dari hari sebelumnya ... yang memperkenalkan bug baru). Anda pikir itu tidak terjadi di dunia nyata? BTW: tentang "beku" dalam jawaban Anda, Anda pikir masuk akal untuk mengirim pertanyaan seperti "Apa contoh implementasi dari lingkungan beku?"
Pierre.Vriens

@ Pierre.Vriens, bagi saya masuk akal untuk mengirim pertanyaan seperti itu. Biasanya ini diatur oleh peraturan perusahaan, tetapi devops menciptakan lingkungan yang cukup dinamis dan ini bisa menjadi tantangan nyata :)
Romeo Ninov

1
Ini adalah pendekatan yang saya sukai, dengan cara itu memberikan lingkungan di mana para devs dapat segera menguji perubahan mereka dalam lingkungan yang terintegrasi, tetapi menjaga QA bersih sampai kode siap untuk diuji secara formal
Taegost

3

Jika Anda melakukan CI / CD, itu menyiratkan bahwa ada beberapa tes otomatis terjadi (CI) sebelum penyebaran (CD). Jika Anda menemukan banyak masalah di lingkungan pengujian Anda, itu berarti mereka tidak tertangkap oleh tes yang dijalankan sebelum penyebaran; ini menunjukkan pengujian otomatis tidak memadai. Jika pengembang mengalami masalah di mana cacat muncul di lingkungan pengujian, mereka perlu meningkatkan suite pengujian otomatis mereka untuk mencegah hal ini. Ini juga akan meningkatkan kualitas dan keandalan secara keseluruhan, hingga produksi.


3

Untuk menambah jawaban Romeo Ninov, secara internal di dalam lingkungan Anda perlu mencoba dan memisahkan aplikasi sebanyak mungkin. Ini adalah sebagian mengapa buruh pelabuhan telah begitu sukses untuk dev / test. Ini membuat Anda hampir berpura-pura tidak berbagi lingkungan sama sekali.

Pilihan lainnya adalah memiliki server yang sangat jelas tempat aplikasi dijalankan yang terpisah dari infrastruktur lainnya yang membentuk lingkungan Anda. Yaitu. Semua mesin manajemen lingkungan atau pemberdayaan berjalan di server yang terpisah dan berumur panjang. Kemudian Anda menghubungkan server baru berumur pendek berdasarkan gambar yang dikenal untuk menguji aplikasi dan, jika ada perubahan yang dilakukan pada gambar dasar, Anda perlu menerapkan perubahan itu di mana - mana untuk setiap komponen baru. Yang berarti menguji perubahan terhadap semuanya.

Jika tim appdev meminta perubahan yang merusak aplikasi orang lain, maka nasib buruk, mereka perlu secara internal membuat mitigasi dalam kode mereka dan menjaga persyaratan spesifik mereka terpisah dari penawaran lingkungan.


Sudut pandang / penambahan yang menarik, meskipun ada beberapa hal di dalamnya yang mungkin ingin Anda perbaiki / ulang: (1) "aplikasi" dalam konteks ini, apa maksud Anda (beberapa contoh?) (2) ada ide bagaimana ini bisa bekerja di (main bagus) lingkungan mainframe (3) apa itu "mitigant" dalam konteks ini di sini? PS: beri tahu saya kalau menurut Anda saya harus membuat pertanyaan baru untuk "barang" ini (peluru).
Pierre.Vriens
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.