Proses atau alat apa yang memungkinkan Pemisahan Tugas ketika para insinyur menggunakan dan menjalankan kode?

18

Dalam lingkungan yang sangat diatur, seperti sektor Jasa Keuangan, Pemisahan Tugas merupakan mekanisme penting untuk menghindari tabrakan di antara individu dengan tanggung jawab pembangunan dan hak istimewa produksi.

Secara tradisional ini berarti bahwa Pengembang mengembangkan kode dan kemudian menyerahkannya ke Operasi namun dalam banyak Model Pengoperasian DevOps pemisahan antara Pengembangan dan Operasi, minimal, kabur:

Setelah menghabiskan berbulan-bulan menelusuri sampai ke akar penyebab mekanisme Pemisahan Tugas, tampaknya ini ada untuk memuaskan Sarbanes Oxley Bagian 404 : Penilaian Manajemen Pengendalian Internal:

(a) Diperlukan Aturan. Komisi akan menetapkan aturan yang mensyaratkan setiap laporan tahunan yang disyaratkan oleh bagian 13 (a) atau 15 (d) dari Undang-Undang Bursa Efek tahun 1934 untuk memuat laporan pengendalian internal, yang harus--

(1) menyatakan tanggung jawab manajemen untuk menetapkan dan memelihara struktur dan prosedur pengendalian internal yang memadai untuk pelaporan keuangan; dan

(2) berisi penilaian, pada akhir tahun fiskal terbaru dari penerbit, dari efektivitas struktur pengendalian internal dan prosedur penerbit untuk pelaporan keuangan.

(B) Evaluasi dan Pelaporan Kontrol Internal. Pada penilaian pengendalian internal yang disyaratkan oleh ayat (a), setiap kantor akuntan publik terdaftar yang menyiapkan atau menerbitkan laporan audit untuk penerbit harus membuktikan, dan melaporkan, penilaian yang dilakukan oleh manajemen penerbit. Pengesahan yang dibuat berdasarkan ayat ini harus dibuat sesuai dengan standar untuk pengikatan pengesahan yang dikeluarkan atau diadopsi oleh Dewan. Pengesahan semacam itu tidak akan menjadi subjek perjanjian terpisah.

Berdasarkan komentar, penting untuk memanggil beberapa asumsi yang saya buat:

  • Saya terutama mempertimbangkan layanan keuangan pasar massal, yaitu volume transaksi tinggi tetapi nilainya relatif rendah. Ini akan bertentangan dengan layanan keuangan komersial yang memiliki profil nilai transaksi yang berbeda.
  • Penawaran online lembaga keuangan akan terdiri dari banyak komponen yang memiliki pertimbangan risiko berbeda:
    • Pindahkan Uang - Memindahkan uang antar akun atau transfer antar akun dari pemilik yang berbeda. Satu operasi yang harus mempertimbangkan negara-negara Anti Pencucian Uang, Penipuan, dan Embargo untuk menyebutkan beberapa.
    • Akuisisi Pelanggan - Lebih sedikit "Berisiko" karena memiliki volume transaksi yang rendah dibandingkan dengan Uang Bergerak tetapi masih perlu dipertimbangkan.
    • Internet Banking - Meliputi berbagai layanan dengan berbagai tingkat risiko, Pindah Uang akan dianggap bagian dari ini.
  • Dapat dibayangkan suatu pendekatan yang berbeda dapat diambil untuk masing-masing tergantung pada risikonya, namun, demi menjaga kesederhanaannya, saya bekerja menuju solusi yang akan diterapkan pada beberapa operasi paling berisiko.

TL; DR : Merupakan tanggung jawab manajemen untuk memastikan bahwa kontrol internal yang memadai telah sesuai dengan peraturan Komisi Sekuritas dan Bursa .

Sarbanes Oxley 404 biasanya puas melalui penyelesaian Top-Down Risk Assessment, yang sebagian akan menilai risiko kolusi dan mengedepankan strategi mitigasi.

Dalam sebuah perusahaan yang menggunakan praktik dan budaya DevOps, di mana Pengembang secara rutin memiliki akses ke kontrol sumber dan produksi bagaimana Segregasi Tugas dapat dicapai, atau lebih umum bagaimana risiko kolusi dapat dikurangi.

sre financial-services operating-model Richard Slater
sumber
Gagasan utama di balik organisasi devosi adalah untuk membuat semua orang di Tim bertanggung jawab atas apa yang terjadi dalam produksi, tidak mungkin ada pemisahan tugas. Ini terutama berarti organisasi semacam ini tidak dapat benar-benar digunakan ketika ada kebutuhan peraturan untuk pemisahan ini.
Tensibai
@Tensbai I secara fundamental tidak setuju dengan pernyataan bahwa DevOps tidak kompatibel dengan Pemisahan Tugas. Undang-undang tidak bersifat menentukan tentang cara kontrol, dan regulator juga tidak memaksakan proses yang telah ditentukan pada bank dan jasa keuangan. Sebagian besar tergantung pada organisasi untuk mengidentifikasi apa yang pantas dan benar-benar transparan dengan para regulator dan auditor yang ditunjuk. Sebagai contoh, baik ING maupun Barclays telah mengadopsi praktik-praktik DevOps untuk memungkinkan mereka mempercepat kemampuan mereka dalam memberikan nilai kepada pelanggan mereka.
Richard Slater
Ya, devops pada subjek yang tidak terikat pemisahan peraturan, dan mereka mengambil keuntungan dari otomatisasi pada org berbasis silo tradisional untuk subjek yang dibatasi (yang sebenarnya sangat sedikit). Mereka hanya memiliki dua jenis organisasi tergantung pada jenis operasi yang akan dilakukan oleh perangkat lunak
Tensibai
Tidak ada yang namanya "Pemisahan Peraturan" undang-undang / undang-undang dan badan pengawas tidak memaksakan pemisahan pada lembaga keuangan, mereka memaksakan tanggung jawab manajemen untuk memiliki "Kontrol yang Tepat" untuk mengelola risiko keuangan. Dengan cara yang sama seperti Agile mengambil pengembangan perangkat lunak dari siklus panjang ke siklus kecil, DevOps mengambil operasi ke dalam siklus kecil, DevOps dalam Jasa Keuangan perlu menemukan cara untuk mengambil Segregasi Tugas ke dalam siklus kecil, dengan misalnya membuat saluran pipa CD yang memberlakukan "kontrol yang sesuai" seperti ulasan sejawat dan promosi berdasarkan persetujuan.
Richard Slater
1
@ Pierre. Virens ya pertanyaan besarnya ada di judul, saya sudah mencoba mengembangkannya dengan membuat beberapa asumsi. Peran cenderung menjadi bagian dari solusi seperti halnya hal-hal seperti Break-Glass dan Manajemen Akun Privileged. Peran dan Tanggung Jawab adalah konsep yang menarik di DevOps / Agile karena ketika Anda pernah memiliki Pengembang Java, Pengembang F / E, Desainer, PM, Build Engineer, Release Manager dan Ops Engineer - sekarang Anda memiliki sekelompok orang yang dapat memakai banyak topi - tim lintas fungsi terdiri dari "Insinyur" yang mungkin berspesialisasi tetapi pada akhirnya berbagi tanggung jawab,.
Richard Slater

Jawaban:

8

Pertanyaan Anda sepertinya tidak membuat asumsi tentang platform / OS tentang hal itu. Itulah sebabnya mengapa masuk akal untuk menambahkan jawaban tentang bagaimana hal ini biasanya dilakukan / ditangani dalam lingkungan mainframe, di mana "insinyur" (seperti dalam judul pertanyaan Anda) sebenarnya adalah sekelompok orang yang berpuluh-puluh (mungkin ratusan) orang terlibat. Jawaban saya didasarkan pada penggunaan produk SCM yang paling saya kenal (tidak yakin apakah perlu mengungkapkan nama produk).

1. Arsitektur

Berikut adalah hal-hal penting tentang bagaimana saya akan menjawab pertanyaan Anda:

  • Semua kode (dan artefak terkait seperti executable, dll) disimpan dalam file yang, bersama-sama adalah apa yang kita sebut struktur pustaka .
  • Untuk setiap lingkungan pada setiap sistem target (mungkin jarak jauh), ada server ("tugas yang dimulai" di mainframe berbicara), yang menangani SEMUA (ulangi: SEMUA) pembaruan untuk apa pun dalam struktur perpustakaan. Ada beberapa pengecualian (seperti petugas keamanan, atau tim manajemen ruang), tetapi selain itu, tidak ada (ulangi: tidak ada) yang memiliki otorisasi untuk menerapkan pembaruan ke file apa pun dalam struktur perpustakaan itu. Dengan kata lain: server mendapatkan otoritas pembaruan eksklusif untuk seluruh struktur perpustakaan . Perhatian: OPS-orang akan menjadi gila jika Anda masuk untuk membatasi akses mereka (pada awalnya mereka akan menolak ...), jadi pastikan Anda dilindungi oleh manajemen atas (CxO) untuk memaksakan aturan akses tersebut ...
  • Perangkat lunak yang sebenarnya mengubah saya terdiri dari satu komponen (perbaikan kode kecil di tengah malam ...), atau mungkin juga ratusan atau ribuan sumber, dapat dieksekusi, atau apa pun artefak lainnya (selama akhir pekan rilis). Untuk membuatnya mudah dikelola, hal-hal yang harus dipindahkan (kurang lebih) bersamaan, pada saat bersamaan, digabungkan menjadi satu dalam apa yang disebut paket perubahan perangkat lunak .

Dengan hal tersebut di atas, segala jenis pembaruan yang diterapkan oleh server ke struktur perpustakaan, hanya akan dimungkinkan melalui alur kerja yang terdefinisi dengan baik, yang kami sebut siklus hidup paket perubahan perangkat lunak (SDLC jika Anda mau). Untuk benar-benar menjalankan berbagai langkah dalam alur kerja itu, inilah yang diperlukan untuk mewujudkannya:

  • Hanya server yang akan menjalankan langkah-langkah yang diperlukan (dan sudah dikonfigurasikan).
  • Server hanya akan melakukan langkah tertentu (= memperbarui sesuatu di suatu tempat dalam struktur perpustakaan), setelah persetujuan yang diperlukan (dari manusia) dikumpulkan untuk melakukan langkah tersebut.
  • Persetujuan hanya dapat diberikan oleh pengguna yang memiliki peran yang memungkinkan mereka (= izin) untuk mengeluarkan persetujuan tersebut.

2. Peran dan izin

Server akan memastikan bahwa pengguna yang mencoba membuat sesuatu terjadi (seperti 'menyetujui sesuatu') hanya akan dapat melakukannya, jika izin pengguna sesuai. Bagian itu mudah. Tetapi Anda tidak ingin menggunakan sistem SCM untuk mengelola semua izin itu untuk semua pengguna yang terlibat, itulah yang termasuk dalam sistem keamanan Anda (bukan sistem SCM!), Sehingga Anda dapat menyesuaikan alur kerja Anda (dalam sistem SCM Anda) untuk pergi memeriksa izin tersebut kapan saja sesuai. Langkah-langkah di bawah ini memberikan beberapa detail lebih lanjut tentang itu.

Langkah 1: Konfigurasikan izin (dalam sistem keamanan)

  • Tetapkan entitas keamanan dalam sistem keamanan Anda, dengan nama yang didefinisikan dengan baik untuk entitas tersebut. Beberapa sampel (tambahkan sebanyak mungkin yang serupa dengan kebutuhan Anda sendiri):

    • PrmUnit, digunakan untuk mendapatkan izin untuk meminta Promosi untuk mengatakan Unit -testing.
    • PrmQA, Digunakan untuk mendapatkan izin untuk meminta Promosikan mengatakan Qa -Ujilah (mari kita menganggap ini adalah tingkat tertinggi dari pengujian).
    • PrdEnduser, digunakan oleh pengguna akhir yang terlibat dalam beberapa tingkat pengujian, untuk menunjukkan bahwa mereka puas dengan hasil yang dihasilkan oleh beberapa jenis pengujian. Dan karena itu, para pengguna akhir setuju dengan perubahan yang bergerak maju dalam struktur perpustakaan.
    • PrdRelmgnt, digunakan oleh manajer rilis untuk mengesahkan Aktivasi dalam produksi (= level terakhir / tertinggi dalam struktur perpustakaan).

  • Tentukan grup pengguna di sistem keamanan Anda. Beberapa sampel (tambahkan sebanyak mungkin yang serupa dengan kebutuhan Anda sendiri):

    • GrpDevs, yang (misalnya) sesuai dengan pengembang Anda (mungkin lebih dari hanya 1).
    • GrpEnduser, yang (misalnya) sesuai dengan pengguna akhir Anda (setidaknya 1, lebih disukai dengan pengguna yang lebih mirip).
    • GrpRelMgnt, yang (misalnya) sesuai dengan manajer rilis Anda (setidaknya 1, lebih disukai beberapa pengguna).

  • Berikan izin , juga menggunakan sistem keamanan Anda, untuk memungkinkan akses ke " entitas keamanan " yang dipilih untuk " grup pengguna " yang dipilih. Untuk melanjutkan contoh di atas, inilah yang tampaknya cocok (sesuaikan dengan kebutuhan Anda):

    • Grup GrpDevsmendapat akses ke entitas keamanan (hanya!) PrmUnit.
    • Grup GrpEndusermendapat akses ke entitas keamanan (hanya!) PrdEnduser.
    • Grup GrpRelMgntmendapat akses ke entitas keamanan (keduanya!) PrmQADan PrdRelmgnt.

Langkah 2: Konfigurasikan alur kerja (dalam sistem SCM)

Setelah izin dikonfigurasikan dalam sistem keamanan Anda (seperti pada Langkah 1), yang tersisa untuk dilakukan dalam sistem SCM Anda adalah mengonfigurasi bagaimana berbagai langkah dalam siklus hidup cocok dengan entitas keamanan terkait di sistem keamanan Anda. Artinya, hanya pengguna yang memiliki akses yang sesuai ke entitas keamanan yang diperlukan, diizinkan untuk meminta server untuk melakukan langkah yang sesuai dalam alur kerja.

Berikut adalah beberapa contoh bagaimana Anda mengkonfigurasi sistem SCM Anda untuk membuat keajaiban terjadi:

  • Jika pengguna memiliki akses ke PrmUnit, maka pengguna tersebut diperbolehkan untuk meminta Promosi ke Unit -testing. Jelas, pengguna dalam grup GrpDevsadalah pengguna yang diotorisasi untuk ini (catatan: tidak, misalnya, pengguna dalam grup GrpRelMgnt).
  • Jika pengguna memiliki akses ke PrmQA, maka pengguna tersebut diizinkan untuk meminta Promosi ke QA -testing. Jelas, pengguna dalam grup GrpRelMgntadalah pengguna yang diotorisasi untuk ini (catatan: tidak, misalnya, pengguna dalam grup GrpDevs, atau dalam grup GrpEnduser).
  • Jika pengguna memiliki akses ke PrdEnduser, maka pengguna tersebut diizinkan untuk mengotorisasi perubahan yang bergerak maju dalam struktur perpustakaan (yang biasanya merupakan prasyarat bagi pengguna dalam grup GrpRelMgntbahkan untuk dapat meninjau perubahan). Jelas, pengguna dalam grup GrpEnduseradalah (hanya) pengguna yang diotorisasi untuk ini.
  • Jika pengguna memiliki akses ke PrdRelmgnt, maka pengguna tersebut diizinkan untuk mengotorisasi Aktivasi dalam produksi (= level terakhir / tertinggi dalam struktur perpustakaan).

3. Harapkan yang tak terduga, dan bersiaplah untuk itu

Di atas hanyalah cetak biru, yang semoga membantu untuk memahami bagaimana pada akhirnya itu adalah server yang menangani pemisahan tugas ... asalkan Anda memiliki CxO yang melindungi Anda untuk menerapkan beberapa aturan akses yang tidak semua orang akan suka.

Untuk melengkapi gambar seperti yang dijelaskan di atas, server membuat jejak audit (logging) dari segala sesuatu yang terjadi di sistem. Sehingga pada suatu titik waktu, selalu mungkin untuk menjawab pertanyaan seperti

Apa yang terjadi kapan dan mengapa, dan pengguna resmi mana yang benar-benar menyetujuinya ... dimuka?

Tapi, mungkin bagian terberat adalah memiliki alat pelaporan yang memadai (dan tahu cara menggunakannya). Setidaknya untuk (dengan mudah) memenuhi permintaan dari auditor TI (pertanyaan mereka bisa sangat menantang). Tetapi juga untuk menunjuk ke catatan log yang relevan dalam sistem SCM Anda untuk menjawab semua jenis "Apa yang terjadi" - pertanyaan dalam situasi krisis di mana (bagian dari) produksi turun.

PS: Saya serahkan pada penilaian semua orang jika jawaban saya ya atau tidak sesuai dengan DevOps.

Pierre.Vriens
sumber
Kedengarannya seperti implementasi dasar dari penilaian risiko top-down, saya tidak mengerti bagaimana ini menjawab pertanyaan tentang bagaimana ini dapat diimplementasikan dengan cara devops di mana devs memiliki hak untuk memicu saklar deploy '. Apakah gagasan bahwa Anda tidak dapat melakukannya di organisasi devops?
Tensibai
@Tensibai "jika" devs akan memiliki auth (peran) dari (misalnya) persetujuan akhir untuk prod (yang biasanya TIDAK mereka miliki dalam organisasi semacam itu), maka server tersebut (tugas yang dimulai) akan memulai penyebaran. Dan sesuai dengan judul pertanyaan, saya pikir ini adalah "kemungkinan" jawaban. Namun, orang dapat mempertanyakan apakah ini yang akan kita sebut organisasi DevOps, tetapi saya tahu bahwa auditor benar-benar menyukai jenis pemisahan tugas yang dapat dikonfigurasi (misalnya: empat mata dan variasi itu). Mungkin Richard bisa membantu kita dengan sudut pandangnya tentang ini?
Pierre.Vriens
1
Saya setuju auditor benar-benar menyukainya, saya hanya merindukan bagaimana ini berhubungan / cocok dengan 'ledakan' akses, yang biasanya tidak disukai auditor ketika daftar berisi lebih dari 6 hingga 7 orang. Mengatakan itu tidak cocok adalah jawaban IMHO yang benar-benar valid.
Tensibai
1
Terima kasih telah memberikan begitu banyak waktu ke dalam jawaban. Saya sebenarnya berpikir untuk menerapkan aturan 3-orang, dalam hal itu, satu pengembang menulis kode, pengembang berbeda meninjau kode dan orang ketiga menekan tombol pelepas untuk menyebarkan kode. Pertimbangan lain adalah karena ini adalah bagian dari adopsi Agile / DevOps di seluruh perusahaan, tim pengembangan cukup kecil, dengan efek bersih dari kelompok kecil orang yang memiliki akses produksi ke irisan tipis produksi, ini tampaknya menguntungkan dari perspektif risiko .
Richard Slater
1
@ Pierre.Vriens Tidak dapat memilih dua kali, ekstensi hebat :)
Tensibai
5

Jawaban berdasarkan pada pengetahuan saya tentang peraturan "Kontrol internal" dalam bahasa Perancis, sejenis dengan peraturan SEC yang Anda tunjukkan, saya berasumsi bahwa menghubungkan di sini dengan teks hukum Prancis tidak akan benar-benar berguna dan saya tahu tidak ada terjemahan yang baik untuknya.

Dalam model 'Anda membangunnya, Anda menjalankannya' yang ideal, semua orang di tim akan bertanggung jawab atas perubahan tersebut. Penilaian risiko tidak dapat ditegakkan dengan pemisahan tugas dan satu-satunya cara saya tahu untuk tetap mematuhi peraturan adalah dengan melakukan audit siklus pendek secara berkala bersama dengan pelacakan tindakan yang tidak dapat diubah untuk kembali ke orang yang melakukan rilis .
Ini berarti semua log transaksi dan tindakan didorong ke area terbatas yang tidak dapat diakses oleh tim, perubahan dalam apa yang dicatat "harus" ditangkap oleh tes fungsional yang tidak dapat diakses oleh tim dan yang lebih buruk akan ditangkap oleh audit dan dilacak ke penulisnya.

Ini tidak berlaku untuk semua produk, pada saat penulisan di Perancis perusahaan mana pun yang diizinkan untuk mengeluarkan uang (terutama bank), harus memastikan setiap transaksi akan dicatat dan dengan demikian tidak dapat mengambil risiko kehilangan transaksi.
Di sisi lain, mereka tidak memiliki kewajiban hukum untuk melacak penawaran komersial atau evaluasi risiko ketika seseorang meminta pinjaman, dan dengan demikian produk yang menangani pemilihan pelanggan ini dan menghitung biaya yang akan ditawarkan lebih mudah untuk dimasukkan ke dalam pos. Model audit -release

Gagasan utama adalah bahwa model rilis harus disesuaikan sesuai dengan kewajiban penilaian risiko.

Sumber daya terkait adalah norma ISO27001 .

Tensibai
sumber
Jawaban yang menarik dan sangat relevan karena banyak bank Eropa memang beroperasi di Perancis. Apakah ada kemungkinan Anda dapat memperluas apa yang dimaksud dengan 'Uang Melepaskan', yaitu hanya mengeluarkan uang tunai dari ATM atau apakah itu termasuk transfer saldo. Dalam hal ini, menautkan ke undang-undang akan berharga karena memberikan petunjuk ke hukum yang relevan, terlepas dari bahasa mereka.
Richard Slater
@RichardSlater Singkatnya, setiap perusahaan yang bekerja dengan uang, bisa menjadi perusahaan investasi saja dan juga pialang pinjaman di sepanjang bank tradisional. Sebagian besar segala sesuatu yang memiliki dampak keuangan di suatu tempat sangat memprihatinkan (dari beberapa pengecualian yang dapat diberikan oleh otoritas dalam situasi yang tidak pasti). "Daftar" legal dalam bahasa Prancis ada di sini tetapi bahkan dalam bahasa Prancis tidak selalu jelas.
Tensibai
Saya membuat asumsi bahwa tautan ke standar ISO seharusnya benar-benar ISO27001: 2013
Richard Slater
@ Richard memang, sepertinya tautan Bahasa Prancis ke Bahasa Inggris belum diperbarui di Wikipedia. Saya akan memperbarui nanti (atau jika Anda mau, silakan mengedit)
Tensibai
terkait: Bagaimana saya bisa membujuk pengembang di tim saya untuk merangkul "Anda membangunnya, Anda menjalankannya"?
Dan Cornilescu
0

IMHO, Pengembang & Operasi dapat diwakili oleh tidak lebih dari dua repositori git untuk basis kode yang sama , masing-masing dengan model izin yang berbeda, sehingga tim tidak akan ikut campur dalam pekerjaan satu sama lain, sama sekali.

Sebut saja mereka Dev.mygithub.co & ops.mygithub.co , hanya sebagai contoh.

Idenya adalah, bahwa Pengembang bebas untuk membuat / bercabang / menggabungkan ke isi hati mereka - git menyediakan penelusuran penuh dan itulah yang penting di sini - sementara itu, pada saat-saat kerangka peraturan menyiratkan upaya peninjauan, Permintaan Tarik dapat diajukan, untuk penggabungan terjadi secara terkendali.

Dengan membawa konsep itu ke tingkat berikutnya, cabang pengembangan dapat diperbanyak menuju produksi Ops jarak jauh melalui tindakan Tarik Permintaan lainnya . Bagian terakhir itu harus terjadi oleh tangan dan mata operasi, karena mereka memiliki tanggung jawab untuk memeriksanya menjadi produksi dan mereka memilih tingkat tinjauan.

Skema semacam itu memungkinkan fleksibilitas tak terbatas, keterlacakan penuh, kemampuan untuk menangkap masalah sejak dini melalui berbagai proses, pemisahan kekhawatiran dan pengalaman pengguna yang sangat masuk akal dalam proses !

NB Model yang dijelaskan di atas dapat diikuti bahkan jika Ops & Dev tumpang tindih total!

fgeorgatos
sumber
1
Tentunya, kontrol yang sama ini dapat dicapai melalui permintaan tarik dan kait pasca-komitmen yang memastikan bahwa pengembang dapat melakukan dengan bebas, namun, menggabungkan komitmen hanya dapat dilakukan oleh sekelompok orang yang disetujui. Sama halnya dengan kait pascakomitmen yang sama dapat memastikan bahwa penulis komitmen yang menyusun permintaan tarikan tidak termasuk orang yang membuat permintaan tarikan.
Richard Slater
@RichardSlater: alasan Anda mungkin ingin memiliki dua repositori yang berbeda adalah bahwa Anda memiliki kebutuhan ganda untuk memungkinkan pengembang untuk menggabungkan - ketika mereka secara bebas bertukar kode dalam mode pengembang - serta memblokir sebagian besar pengembang dari penggabungan kode saat itu untuk menuju produksi (modulo SysOps, mis. yang disebut "kelompok orang yang disetujui").
fgeorgatos
Sekali lagi Anda dapat mencapainya dengan kait pasca-komitmen dan permintaan tarik, belum lagi GitHub Enterprise memungkinkan cabang yang dilindungi.
Richard Slater
0

lebih tinggi lebih mahal:

  • situs pengembang dan metode yang berbeda untuk melakukan pekerjaan dari satu ke yang lain
  • sistem & metode dev dan ops berbeda seperti di atas
  • repositori dev dan ops git / vcs yang berbeda & metode terkait
  • cabang dev dan ops git / vcs yang berbeda (dilindungi) & metode terkait

Bergantung pada apa yang Anda lakukan, beberapa solusi lebih baik daripada yang lain, misalnya jika Anda memiliki kebutuhan untuk melayani dua tim dengan peran yang berbeda di dalamnya dan masing-masing memiliki kepemilikan di dalam dan memberikan penelusuran penuh, Anda berada di atas tiga yang pertama.

Singkatnya, apa pun yang memberlakukan bahwa seorang pria atau wanita tidak bisa mengambil bola sendirian dan menjalankannya, dan ia melintasi batas eksplisit yang berbeda di antara para pengembang. Sekarang, tergantung pada tingkat risiko, batas itu mungkin ditegakkan atau tidak.

fgeorgatos
sumber