Berapa banyak akses database yang harus dimiliki pengembang? [Tutup]

Jadi saya telah bekerja di banyak tempat kerja yang berbeda sebagai pengembang dan tingkat akses saya ke database sangat bervariasi. Saya biasanya tidak memiliki akses db produksi.

Sebagian besar waktu saya memiliki akses ke database pengujian, tetapi bervariasi. Terkadang saya bisa melakukan dan mengubah database dan data sesuka saya, tetapi biasanya ada pengaturan lain. Seperti saya mungkin hanya memiliki akses baca ke data.

Saya bekerja di satu tempat di mana tim DBA akan mengelola database, kami tidak bisa membuat perubahan sama sekali kecuali kami mengirimkan formulir dengan skrip sql untuk mereka "periksa". Mereka biasanya tidak banyak berhubungan dengan proyek itu sendiri sehingga sebagian besar waktu, itu hanya untuk menekan F5.

Jujur, saya bisa mengerti mengapa prod perlu dikunci tetapi saya lebih memilih untuk memiliki akses basis data yang banyak di dev dan lingkungan pengujian. Saya pikir sebagian besar pengembang cukup mampu mengetahui jalan mereka di sekitar database. Tapi saya ingin mendengar pendapat? Berapa banyak akses database yang harus dimiliki pengembang? Bisakah kita dipercaya untuk tidak merusak apa pun di sana?

Devs perlu Baca akses ke semua database termasuk prod. Terkadang masalahnya adalah data pada Prod bukan yang mereka harapkan dan mereka perlu melihat data yang menyebabkan masalah karena mereka tidak dapat mereproduksinya pada dev.

Pengembang seharusnya tidak memiliki hak menulis data produksi atau hak untuk membuat objek. Seharusnya tidak ada yang bisa mendorong yang bukan bagian dari rilis resmi. Terlalu sering, orang melakukan perbaikan cepat pada prod yang tidak berfungsi, menyebabkan prod menjadi lebih kotor atau bekerja tetapi mereka lupa untuk memasukkan kode ke server dev / QA / Staging dan bahkan lebih buruk lagi ke sumbernya. kontrol repositori dan kode akan ditimpa sekitar sebulan kemudian dalam rilis resmi berikutnya.

Saya lebih suka devs memiliki hak penuh database QA karena menggunakan ke server lain membantu mereka melihat apakah ada celah dalam proses penyebaran mereka (oops lupa bahwa saya mengubah tabel itu untuk melakukan hal itu dan itu dan oops saya lupa bahwa saya melakukan perubahan itu menggunakan GUI dan tidak dalam skrip dalam kontrol sumber yang merupakan bagaimana setiap perubahan struktur database perlu terjadi).

Saat Anda memiliki klien tipe Perusahaan baru yang akan memiliki set server sendiri, izin dapat diredakan sebelum ditayangkan. Ini karena begitu banyak yang perlu terjadi dan beberapa orang yang dapat mewujudkannya pada prod mendapatkan backlog dan kadang-kadang bahkan perlu mengambil cuti. Khususnya orang-orang yang mengimpor data dari sistem lain, mungkin ditugaskan untuk memasukkannya ke prod sebelum diluncurkan jika dataload akan memakan waktu lama. Orang-orang ini cenderung menjadi spesialis data dan ada tingkat kenyamanan yang lebih tinggi dengan memungkinkan mereka akses sementara ke prod daripada pengembang aplikasi rata-rata. Ini bukan kemewahan yang Anda miliki ketika pergi ke server produksi yang sudah hidup.

Salah satu hal yang paling penting tentang membatasi hak produksi ke database adalah bahwa para dev kemudian perlu memastikan pekerjaan mereka dalam bentuk yang dapat digunakan oleh orang lain. Ini cenderung meningkatkan kualitas pekerjaan karena mereka tidak berusaha melakukan perbaikan dengan cepat karena mereka melupakan sesuatu atau sesuatu yang tidak berhasil karena mereka melakukannya secara berbeda pada prod daripada deve ketika mengandalkan memori saja. Anda juga kehilangan "oops, saya menghapus seluruh tabel pengguna secara tidak sengaja karena saya lupa untuk menyorot jenis klausa" ketika kecelakaan penyebaran prod adalah murni menggunakan skrip yang dijalankan secara keseluruhan, bukan satu perintah pada satu waktu seperti yang khas ketika dev menjalankan segala sesuatunya pada prod. Sebuah tim dengan hak terbatas untuk mendorong basis data juga cenderung menyimpan perubahan basis data dalam kontrol sumber.

Yah itu benar-benar pertanyaan "Vampir (Pemrogram) versus Manusia Serigala (Sysadmin)" seperti yang dikatakan Jeff Atwood di sini .

Biasanya (itu berarti ada kemewahan untuk mengatur lingkungan penuh), akses pengembang ke:

• Server produksi
  • Tidak ada (SA / PM akan berlaku untuk pengaturan skema, pengguna akhir akan memberikan data init)
• Server UAT
  • Tidak ada (SA / PM akan berlaku untuk pengaturan skema dan pengambilan sampel data)
• Pengujian / server QA
  • Biasanya pengembang akan mengirim skrip pengaturan skema ke tim QA dan QA membuat tabel
  • Pengembang memiliki akses penuh ke database tetapi jarang mengubahnya
  • Pengembang dapat membantu kolega QA untuk seed / patch / menghapus beberapa data
• Server pengembangan / localhost
  • Akses penuh

Alasan utama di balik mengapa pengembang tidak boleh menyentuh server produksi adalah: ketika ada masalah, tim operasi bertanggung jawab, tetapi bukan pengembang.

Minimum absolut yang Anda butuhkan untuk menyelesaikan pekerjaan.

Jika semua pengembang diberikan akses DB penuh, kemungkinan seseorang menjadi marah (atau mabuk, atau sangat lelah atau ...) dan melakukan kerusakan serius jauh lebih tinggi maka jika mereka hanya bisa membaca dari database.

Jika pekerjaan Anda sebagian besar dapat dilakukan tanpa akses tulis DB (Dan sebagian besar yang saya maksud adalah paling banyak beberapa permintaan perubahan seminggu), maka Anda benar-benar tidak perlu akses tulis.

Ada 2 keinginan yang saling bersaing di semua lingkungan kerja.

• Keinginan memberi orang akses sehingga mereka bisa menyelesaikan masalah sendiri. Ini memungkinkan mereka untuk cepat dan mandiri.
• Keinginan untuk membatasi dan mengontrol akses untuk mencegah kerusakan, waktu henti atau kehilangan data (disengaja atau tidak).

Bagian dari apa yang membentuk keseimbangan yang tercapai (atau seharusnya tetap) adalah harapan yang ditetapkan untuk pengembang. Dalam setiap pekerjaan yang saya miliki di mana pengembang memiliki akses ke semua harapan adalah bagi mereka untuk membatasi diri. Hanya akses sistem jika Anda tahu apa yang Anda lakukan. Itu berarti Anda tahu apa yang Anda lakukan dari sudut pandang pengembang dan sysadmin. Jika Anda tidak yakin di kedua area tersebut, Anda tidak memiliki bisnis untuk mengakses sistem tanpa seseorang yang melakukannya untuk mendampingi Anda.

Singkatnya jika Anda tidak tahu, Anda seharusnya tidak memiliki akses ke sistem apa pun selain sistem dev yang mudah dibangun kembali . Jika Anda tahu, daripada Anda tahu Anda tidak boleh mengakses sistem apa pun kecuali sistem dev yang mudah dibangun kembali .

Pengembang harus memiliki akses penuh ke database dev (idealnya mereka harus menjalankan server lokal, tetapi itu tidak selalu mungkin). Mereka harus memiliki akses ke database build / QA, tetapi hanya untuk data (harus mendapatkan izin / mengirimkan tiket untuk mengubah struktur). Pengembang tidak boleh memiliki akses biasa ke basis data produksi (kecuali jika itu adalah perusahaan / proyek kecil dan pengembang juga melakukan dukungan produksi).

Saya pikir kuncinya di sini adalah tingkat tanggung jawab yang dimiliki pengembang. Dalam organisasi besar dengan banyak pengembang, mereka kemungkinan hanya akan memiliki akses ke pengembangan dengan akses hanya baca ke QA / Test.

Namun, harus ada orang-orang di tim pengembangan dengan akses penuh ke semua lingkungan. Ini biasanya adalah orang yang bertanggung jawab untuk melakukan perbaikan, dll. Meskipun ini agak berisiko, ini merupakan kompromi antara seberapa besar Anda mempercayai pengembang, seberapa cepat Anda menginginkan sesuatu diperbaiki, dan risiko yang terlibat dalam mengacaukan sistem atau pengungkapan informasi dalam sistem .

Saya bekerja di sebuah toko IT besar dan kami memang memiliki akses baca untuk produksi bagi kebanyakan orang. Saya sebagai pengembang utama juga memiliki izin ke basis data produksi. Saya masih harus mengikuti pedoman yang sama dengan sysadmin dan DBA dalam hal proses dan dokumen, tetapi saya juga bisa membuat perbaikan segera jika diperlukan.

Ada masalah terkait yang sebagian besar dari kita lupa - kita mungkin bukan satu-satunya orang yang menggunakan database! Kita cenderung menerima begitu saja tetapi tidak seharusnya. Bahkan situs kecil mungkin memiliki pelaku bisnis yang menjalankan alat pihak ketiga terhadap database untuk laporan mereka. Situs perusahaan hampir selalu memiliki banyak pengguna tabel database dan perubahan 'kecil' Anda dapat merusak aplikasi mereka dan sebaliknya.

Jadi ini harus menjadi pertanyaan pertama. Yang kedua harus menjadi staf yang tersedia - Saya telah bekerja di situs yang memiliki sysadmin yang melindungi wilayah mereka tetapi benar-benar tidak begitu baik. (Mungkin itulah sebabnya mereka begitu teritorial - mereka tahu mereka akan terkena banyak panas jika seseorang melihat sekeliling.) Kadang-kadang Anda harus memiliki lebih banyak akses daripada yang Anda inginkan.

Tetapi di dunia yang ideal saya setuju dengan poin yang dibuat oleh orang lain. Saya tidak ingin akses ke data langsung karena, terus terang, saya tidak ingin tanggung jawab. Pikirkan tentang hal itu - jika saya memiliki akses operasional dan ada pelanggaran maka saya harus menghabiskan banyak waktu untuk membuktikan bahwa saya tidak ada hubungannya dengan itu. Saya mungkin harus menunjukkan bahwa saya belum mengambil data untuk alasan pribadi, dll. Banyak situs sangat serius menjaga privasi, khususnya. situs pemerintah.

Saya bahkan tidak ingin akses tulis / admin ke sistem grup uji. Jika saya tidak dapat melakukan sesuatu pada sistem produksi maka saya tidak ingin dapat melakukannya pada sistem pengujian. Akses baca adalah pengecualian karena ini penting untuk membantu mengetahui apa yang terjadi.

Sistem pengembangan, baik individu maupun departemen, adalah cerita yang berbeda. Tetapi bahkan di sini, dalam praktiknya, biasanya yang terbaik adalah menjalankan semua perubahan basis data melalui orang yang ditunjuk alih-alih meminta setiap orang melakukan hal mereka sendiri.

Saya sepenuhnya setuju dengan semua jawaban, dengan mengatakan "hak istimewa sesedikit mungkin untuk pengembang pada basis data prod". Tapi jujur, siapa yang bisa menolak akses pengembang ke database jika mereka ingin mendapatkannya. Dengan kehendak yang cukup (baik itu kejahatan atau untuk kebaikan) mereka akan mendapatkan akses yang dibutuhkan.

Siapa yang dapat menahan mereka dari menempatkan editor SQL sederhana ke dalam aplikasi? Dengan cara ini mereka dapat menggunakan database dengan hak istimewa aplikasi. Dalam kebanyakan kasus ini adalah semua yang diperlukan. Ketika database dikonfigurasi dengan aman, mereka mungkin tidak memiliki hak istimewa untuk membuat atau menghapus objek, tetapi mereka setidaknya memiliki akses baca dan tulis ke data.

Saya sudah di sini ops orang menangis. Tapi jujur ​​pada diri sendiri, Anda tidak sepenuhnya mengendalikan aplikasi yang digunakan dalam produksi, kecuali jika Anda menulisnya sendiri (dan bahkan kemudian, pikirkan tentang perpustakaan). Dan untuk semua pengembang, seperti yang sudah dikatakan Erin, Anda juga bertanggung jawab atas lingkungan produksi, tidak hanya orang-orang ops. Jadi gunakan hak istimewa Anda dengan bijak.