Bagaimana menerapkan lingkungan uji beku?


8

Berikut adalah kutipan sebagian dari jawaban untuk pertanyaan tentang " Bagaimana cara menghindari ketidakstabilan yang disebabkan oleh integrasi berkelanjutan di lingkungan pengujian? ":

Lingkungan ini biasanya membeku selama tes.

Pertanyaan saya: apa contoh implementasi dari lingkungan beku? Yaitu apa yang dapat Anda lakukan untuk menegakkan secara teknis bahwa tidak seorang pun (kecuali jika diizinkan oleh pengguna yang berwenang seperti manajer rilis) akan dapat mengubah apa pun dalam lingkungan beku tersebut.

Klarifikasi :

  • Saya tidak berbicara tentang apa (saya pikir) disebut "periode beku" selama (misalnya) pemrosesan akhir tahun di bank. Itu adalah tentang tidak diizinkan untuk menerapkan perubahan (ulangi apa pun) pada lingkungan produksi, untuk mengurangi risiko perubahan / perbaikan baru yang diperkenalkan yang dapat berdampak pada pemrosesan akhir tahun.

  • Asumsikan bahwa pengguna yang diizinkan untuk menyetujui / menerapkan perubahan (seperti manajer rilis dalam contoh saya), hanya akan melakukannya dalam kasus luar biasa. Seperti di mana selama pengujian masalah keparahan tinggi ditemukan, yang menunda perbaikan untuk rilis berikutnya bukanlah suatu pilihan (karena itu akan berproduksi berisiko jika rilis tersebut akan diaktifkan tanpa perbaikan tersebut).

  • Ini bisa saja tentang menangguhkan pembaruan otomatis apa pun selama pengujian. Intinya adalah: hindari orang lain memutakhirkan Aplikasi A ke versi Y sementara tim lain masih menguji aplikasi B dalam versi X yang bergantung pada aplikasi A. Ini bisa berarti memiliki penjaga untuk menghindari tim uji untuk memerlukan pembaruan pada ketergantungan di bawah uji.

Jawaban:


3

Jawaban saya dalam konteks pertanyaan adalah lingkungan pengujian yang sangat mahal (seperti mainframe atau peralatan telekomunikasi yang sangat besar, misalnya) yang diharapkan untuk dibagikan oleh banyak pengguna untuk beberapa pengujian, bahkan secara bersamaan.

Dalam banyak kasus, peralatan tersebut memiliki sistem manajemen perangkat lunak yang bertanggung jawab untuk, antara lain, mengendalikan perangkat lunak (tidak) instalasi / peningkatan / penurunan versi / dll. Yang seharusnya memiliki mekanisme untuk memblokir operasi semacam itu (yang akan, jika saya memahami pertanyaan dengan benar, setara dengan membekukan lingkungan) berdasarkan beberapa kebijakan yang lebih atau kurang dapat diprogram.

Dalam kasus seperti itu, kebijakan khusus dapat dikembangkan tepat untuk mendukung jadwal pembekuan yang diinginkan yang diperlukan untuk lingkungan pengujian. Idealnya otomatis, menerima pemicu pembekuan / pencairan dari sumber eksternal yang bisa berupa pembungkus pelaksanaan pengujian atau sistem CI. Dan mungkin dengan penggantian yang dipicu manusia, jika dianggap perlu.

Tentu saja, fitur sistem manajemen perangkat lunak seperti itu akan sangat membantu ketika menguji komponen peralatan lainnya, tetapi mungkin tidak untuk pengujian sistem manajemen perangkat lunak itu sendiri.


Jawaban ini sangat tepat tentang apa yang saya gunakan (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 memperluas jawaban ini, bagaimana kita melakukan ini dengan CMN / ZMF untuk misalnya "bank"), atau hanya membawanya ke pertanyaan baru (jawab sendiri). Bagaimana menurut anda?
Pierre.Vriens

Mungkin yang terpisah akan lebih baik - sebagian besar pendapat saya karena saya tidak mengalami lingkungan seperti itu secara langsung, saya hanya membahasnya sekarang dan kemudian dengan teman-teman yang melakukannya.
Dan Cornilescu

4

TeamCity memiliki fitur membangun Sumber Daya Bersama yang memungkinkan Anda untuk menentukan sumber daya yang bergantung pada beberapa Definisi Pembuatan. Definisi Build dapat memerlukan Kunci Baca atau Kunci Tulis, Anda juga dapat menentukan apakah kunci ini eksklusif atau memungkinkan tingkat paralelisme.

Jika kami membuat asumsi berikut tentang lingkungan bersama bernama PreProd :

  • Ada Sumber Daya Bersama yang disebut "PreProd".
  • Semua definisi bangunan, seperti penyebaran, yang membuat perubahan apa pun pada lingkungan itu, mengambil Kunci Tulis eksklusif pada "PreProd".
  • Semua definisi build, seperti tes non-restriktif, yang melakukan operasi read-only di lingkungan mengambil Lock Baca non-eksklusif pada "PreProd".
  • TeamCity adalah satu-satunya proses yang dapat melakukan apa pun di PreProd, meskipun mungkin melalui alat lain.

Karena itu, yang berikut ini benar:

  • Ketika penyebaran terjadi maka tidak ada lagi yang bisa menggunakan PreProd, mereka akan antri.
  • Ketika tes sedang berjalan, penyebaran apa pun akan mengantri sampai tes selesai.

Anda dapat menggunakan mekanisme serupa dengan Jenkins menggunakan plugin Pengecualian . Bahkan, Anda dapat membangun fungsionalitas ini ke dalam proses apa pun menggunakan penguncian atau semafor - misalnya Apache ZooKeeper atau HashiCorp Consul .


Deskripsi yang baik tentang implementasi 'standar' dari apa yang saya masukkan ke dalam ide 'penjaga' :)
Tensibai

merci, ada tautan untuk membagikan / menambah TeamCity sendiri, untuk mempelajari lebih lanjut tentang itu?
Pierre.Vriens

1
Absolument, saya telah menambahkan hyperlink ke TeamCity dan Jenkins dalam jawabannya, saya pribadi dapat merekomendasikan kursus TeamCity di Udemy .
Richard Slater

merci untuk pembaruan tambahan! PS: mengapa juga tidak menyertakan tautan kursus dalam jawaban Anda, misalnya melalui PS di bagian akhir? Dengan begitu, jika suatu hari seorang moderator datang dan mulai menghapus komentar, itu bukan risiko tersesat (itu terjadi pada saya cukup banyak di beberapa situs SE lainnya).
Pierre.Vriens

Saya berhati-hati tentang memposting tautan ke konten komersial sebagai jawaban di situs SE pada umumnya. Saya ingin membantu karena saya merekomendasikan kursus ini, bagaimanapun, karena ini adalah satu-satunya kursus yang saya ambil, itu pendapat saya sendiri.
Richard Slater

0

Ini kedengarannya seperti pola anti bagi saya. Saya percaya semua orang atau tidak seorang pun harus memiliki akses ke semua lingkungan.

Jika pengguna merongrong proses maka saya akan melihat serius proses untuk mencoba dan memastikan itu tidak menghalangi orang.

Menerapkan mekanisme otomatis yang memberlakukan negara tertentu juga berguna untuk mendorong orang untuk melakukan hal-hal dengan cara yang benar. Ini bisa melalui Manajemen Config atau menghancurkan instance yang tidak dapat diubah jika seseorang SSH melakukannya


Silakan periksa "note" ke-2 yang saya tambahkan. Apakah membantu Anda mempertimbangkan kembali paragraf pertama Anda? Selain itu, saya tidak mengerti bagaimana bagian sisa dari jawaban Anda benar-benar menjawab bagian "bagaimana" dari pertanyaan saya. Mungkin ada sesuatu yang tidak saya mengerti di dalamnya, jadi bisakah Anda membantu saya untuk lebih memahami jawaban Anda? PS: Jangan khawatir, saya jarang mengecilkan jawaban (jika ya, saya meninggalkan komentar ....).
Pierre.Vriens

Anda memiliki masalah meta.stackexchange.com/questions/66377/what-is-the-xy-problem Anda . Saya tidak menjawab bagaimana menerapkan solusi Anda. Saya menjawab bagaimana saya akan memecahkan masalah Anda
Robo

@Robo Saya tidak setuju, pertanyaan tentang bagaimana masuk akal, tanpa subversi atau apa pun. Ini bisa saja menangguhkan pembaruan otomatis apa pun selama pengujian. Anda melihatnya sebagai tindakan manual, intinya adalah: hindari orang lain memutakhirkan Aplikasi A ke versi Y sementara tim lain masih menguji aplikasi B dalam versi X yang mengandalkan aplikasi A. Ini berarti memiliki penjaga untuk menghindari tim uji membutuhkan pembaruan tentang ketergantungan yang sedang diuji.
Tensibai

Itu tidak jelas dari pertanyaan Anda. Dalam hal ini Anda memerlukan semacam kunci.
Robo

Harap dicatat bahwa saya baru saja mengintegrasikan (sebagian besar) komentar @Tensibai sebagai klarifikasi tambahan (bullet terakhir). Semoga "itu" membantunya memperjelas pertanyaan saya . Mungkin Anda (Robo) ingin juga meninjau jawaban Anda sesuai klarifikasi tambahan itu? PS: merci Tensibai ...
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.