Apa implementasi yang mungkin (atau contoh) dari prinsip empat mata?

Michael Grünewald baru-baru ini memposting komentar ini :

Metode yang sangat penting yang tidak Anda sebutkan adalah "prinsip empat mata" yang digunakan dalam keuangan - baik sebagai kewajiban regulasi atau sebagai penjaga aman. Dalam industri perangkat lunak ini diimplementasikan dalam berbagai cara, seperti ulasan kode tetapi juga dapat digunakan untuk memvalidasi perintah yang mempengaruhi sistem live.

Koreksi saya jika saya salah, tetapi saya diajari bahwa "prinsip empat mata" adalah tentang sesuatu yang "disetujui untuk terjadi", setelah setidaknya 2 manusia (dan / atau proses otomatis) memberikan berkah mereka sebelumnya. Atau untuk menggunakan kata-kata (yang sedikit dikoreksi) tentang " aturan dua orang" dari Wikipedia :

Aturan dua orang adalah mekanisme kontrol yang dirancang untuk mencapai tingkat keamanan yang tinggi untuk bahan atau operasi yang sangat penting. Di bawah aturan ini, semua akses dan tindakan memerlukan kehadiran dua orang yang berwenang setiap saat.

Kewajiban pengaturan, cukup yakin, di luar topik di sini, tetapi dalam konteks "perlindungan aman", apa saja implementasi konseptual yang mungkin dari prinsip empat mata ini, yang mungkin dapat diterapkan pada platform / OS / perangkat keras apa pun yang digunakan?

configuration four-eyes

— Pierre.Vriens
sumber

Jawaban:

Salah satu implementasi pada kode adalah model Pull Request (PR) yang dipopulerkan oleh GitHub.

Alasan utama di balik adalah bahwa hanya satu set kecil pemelihara produk akan diizinkan untuk menggabungkan kode ke cabang rilis. Setiap fitur baru / perbaikan bug akan terjadi pada cabang baru dan setelah selesai akan didefinisikan sebagai permintaan tarik.

Hal ini memungkinkan untuk menguji penggabungan dari kode rilis aktual (master) dengan kode dalam PR dengan cara otomatis (Travis menjadi yang paling populer untuk proyek publik sebenarnya) dan memberikan umpan balik pertama pada kualitas kode. Travis CI (misalnya) dapat berjalan pada hasil dari master aktual dengan kode dari permintaan tarik digabung ke dalamnya, sehingga akan gagal jika penggabungan tidak mungkin, atau jika perintah yang ditentukan dalam travisci.yml mengembalikan jalan keluar nol nol kode

Setelah tes otomatis lulus, untuk prinsip 4 mata, masih diperlukan sejumlah orang yang dapat dikonfigurasi untuk meninjau dan menyetujui perubahan sebelum digabungkan jelas setidaknya 1 orang (yang bukan penulis PR) untuk menegakkan 4 mata meninjau perubahan.

Ada beragam opsi untuk digabung secara otomatis setelah kuorum pengulas terpenuhi atau masih membutuhkan penggabungan manual oleh pengelola.

Izin untuk meninjau dan menggabungkan dapat dipisahkan yang membantu memberi lebih banyak orang hak untuk "memberikan suara" pada status penggabungan sambil menjaga kemungkinan untuk membatasi siapa yang sebenarnya dapat melakukan penggabungan.

— Tensibai
sumber

Silakan periksa hasil edit kecil dari jawaban Anda (kesalahan ketik). Jika Anda tidak menyukainya, cukup kembalikan atau edit kembali, ok? Juga, saya belum memikirkan PRs ini, jadi saya pikir pasti bisa diterapkan. Saya akan menandai jawaban ini sebagai diterima (saya "belajar" sesuatu darinya, hal-hal dalam jawaban saya sendiri tentu saja saya tahu sendiri). Meskipun saya tidak menjamin di masa depan saya mungkin berubah pikiran (tidak dapat diterima) jika jawaban yang lebih baik diposting. Tentang: "Ini memungkinkan untuk menguji penggabungan dari kode rilis aktual (master) dengan kode dalam PR dengan cara otomatis", saya tidak mengerti, haruskah saya mengirim pertanyaan baru?

— Pierre.Vriens

@pierre Anda bebas untuk berubah pikiran sesering yang Anda inginkan :) Untuk pengujian kode yang diusulkan, Travis CI (untuk contoh) dapat berjalan pada hasil dari master sebenarnya dengan kode permintaan tarik digabung ke dalamnya, sehingga akan gagal jika penggabungan tidak mungkin, atau jika perintah yang didefinisikan dalam travisci.yml mengembalikan kode keluar bukan nol. FWIW, googling terdengar pendekatan IMHO terbaik, subjeknya besar

— Tensibai

@pierre dan untuk pengeditan, hanya satu poin, prinsip 4 mata adalah memiliki 1 orang lagi untuk ditinjau, itu berarti 2 orang memang melihat perubahan (penulis tidak memeriksanya), maka singular pada variabel jumlah orang ( karena bisa jadi hanya satu, dan dalam bahasa Prancis mungkin hanya satu yang tunggal: p). Saya tidak lancar berbahasa Inggris seperti yang saya inginkan, tapi saya pikir poin pertama valid (2 pembaca, 2 memang melihatnya menjadikannya review tunggal), untuk yang kedua saya mungkin bias :)

— Tensibai

aha, itulah yang Anda maksud, sekarang saya mengerti (dan mengambil kebebasan untuk menyalin / menempelkan klarifikasi tambahan ke jawaban Anda). BTW: ex sebuah mple (di EN), tidak ex e mple (seperti dalam FR) ...

— Pierre.Vriens

@ Pierre.Vriens menyalahkan yang benar dengan dua bahasa :)

— Tensibai

Ulasan Kode

Ini adalah tentang memiliki setidaknya 1 orang lain melihat kode yang ditulis oleh seseorang, misalnya untuk mengevaluasi jika memenuhi beberapa kriteria yang telah ditentukan seperti:

Standar pengkodean (lekukan, dll).
Dokumentasi sebaris.
Pemeliharaan kode.
Menangani kesalahan.
Kelengkapan (misalnya if/then/elseatau case/whenkonstruksi mencakup semua kasus yang mungkin).

Persetujuan untuk memperbarui beberapa lingkungan target

Ini adalah tentang memiliki setidaknya 2 konfirmasi dari beberapa orang dan / atau sistem otomatis sebelum diizinkan untuk memperbarui beberapa lingkungan target (yang mungkin hidup, atau mungkin sesuatu seperti beberapa file master / pustaka baseline). Beberapa contoh adalah:

Hanya satu set peringatan terbatas yang diizinkan ketika mengubah komponen sumber (bangunan) menjadi komponen yang dapat dieksekusi.
Beberapa set tes otomatis harus diselesaikan tanpa masalah.
Beberapa manusia pasti telah menunjukkan persetujuan mereka sebelumnya (dan tanpa itu, segala upaya untuk memperbarui lingkungan target akan secara otomatis gagal).

— Pierre.Vriens
sumber

Ini adalah strategi / pola yang dapat saya pikirkan:

Pemisahan Tugas

DevOps, setidak-tidaknya menurut saya, tidak berarti mewujudkan dev dan ops dalam satu orang. Jadi masih mungkin untuk memisahkan tugas sehingga yang menulis kode (dev) bukan yang mengeksekusinya (ops).

Sebagai contoh, jika pernyataan SQL akan dijalankan pada lingkungan hidup, satu menulis SQL dan yang lain mengeksekusinya. Apa yang disyaratkan ini adalah kebutuhan yang mengeksekusi juga memiliki pemahaman tentang SQL dan tidak hanya mengeksekusi.

Sebarkan pemicu

Meskipun ada manfaat untuk terus digunakan. Tim dalam industri yang lebih teregulasi dapat menunjuk pihak lain (terpisah) untuk memicu penyebaran alih-alih penempatan secara otomatis. Daftar periksa, pengujian otomatis, checksum adalah pemeriksaan yang memungkinkan sebelum memicu penyebaran.

Setelah dipicu, otomasi dapat melanjutkan untuk melaksanakan penyebaran.

Pemrograman Pasangan

Secara pribadi saya belum mengutip teknik ini sebagai metode untuk auditor untuk memenuhi prinsip check and balance. Tapi secara potensial saya pikir itu bisa menjadi strategi.

MFA

Saya mungkin sedikit meregang dengan yang satu ini, tetapi ada kemungkinan bahwa karena alasan tertentu Anda tidak ingin masuk secara sepihak ke dalam suatu sistem, seseorang dapat memegang kata sandi dan orang lain memegang token atau perangkat untuk satu kode waktu. Sehingga, 2 orang harus hadir untuk menilai sistem.

— kenchew
sumber

Merci untuk variasi menarik ini! Belum pernah mendengar "Pair programming" itu sebelumnya, yang benar-benar tampak seperti variasi bermain piano dengan "4 tangan"!

— Pierre.Vriens

Baru-baru ini saya mewawancarai sebuah perusahaan yang melakukan pemrograman pasangan paling intensif yang pernah saya lihat. Mereka memiliki pengaturan "pod" dengan dua mesin, masing-masing dengan satu monitor khusus dan satu monitor bersama. SEMUA pengembangan dilakukan berpasangan. Ini bukan untuk semua orang, tetapi menurut semua laporan itu bekerja dengan baik untuk mereka.

— Dave Swersky