Geliştiriciler ne kadar veritabanı erişimine sahip olmalıdır? [kapalı]


16

Bu yüzden bir çok farklı işyerinde geliştirici olarak çalıştım ve veritabanına erişim seviyem değişti. Genelde üretim db erişimim yok.

Çoğu zaman test veritabanına erişimim var, ancak değişkenlik gösteriyor. Bazen veritabanı ve verileri istediğim gibi yapabilir ve değiştirebilirim, ancak genellikle başka düzenlemeler de vardır. Sanki verilere sadece okuma erişimim olabilir.

Bir DBA ekibinin veritabanlarını yöneteceği tek bir yerde çalıştım, "incelemek" için sql betiği içeren bir form göndermedikçe hiçbir değişiklik yapamadık. Genellikle projenin kendisi ile pek bir ilgileri yoktu, bu yüzden çoğu zaman sadece F5'e basmaktı.

Dürüst olmak gerekirse, prod'un neden kilitlenmesi gerektiğini anlayabiliyorum, ancak geliştirici ve test ortamlarında veritabanı erişimine sahip olmayı tercih ediyorum. Çoğu geliştiricilerin bir veritabanı etrafında yollarını bilme makul yetenekli olduğunu düşünüyorum. Ama fikirlerini duymak isterim? Geliştiriciler ne kadar veritabanı erişimine sahip olmalıdır? Orada hiçbir şey kırmamaya güvenilebilir miyiz?


6
Muhtemelen " Geliştiricilerin ne kadar üretim veritabanı erişimine sahip olması gerekir?"
Mayank

@Mayank Kafasına çiviyi vurdun. Her zaman yeni konseptlerle 'oynamak' için bir test sunucusu bulunmalıdır. Üretim sunucusu yalnızca gözden geçirilmiş / test edilmiş / kanıtlanmış sürümleri görmelidir. Aynı şey web siteleri için söyleyebilirim (çoğu web geliştiricisi bir tane kullanmasa bile).
Evan Plaice

@Mayank - Evet, üretim veritabanlarına erişimi duymak istiyorum, ancak DEV, INT, TEST, PREPROD vb.Gibi farklı ortamlarda da erişim hakkında görüşler duymak istiyorum
RoboShop

1
Yinelenen olarak işaretlenmiş olmasına rağmen, ilgili soru programcılar.stackexchange.com/ questions/ 246618/… aslında bunun ilginç bir uzantısıdır.
Eamon Nerbonne

Yanıtlar:


16

Geliştiricilerin prod dahil tüm veritabanlarına Okuma erişimi gerekir. Bazen sorun, Prod'daki veriler bekledikleri gibi değildir ve soruna neden olan verileri dev üzerinde üretemedikleri için görmeleri gerekir.

Geliştiricilerin üretim verileri yazma hakları veya nesne oluşturma hakları olmamalıdır. Resmi bir sürümün parçası olmadığını hiçbir şey kanıtlamayacaktır. Çoğu zaman, insanlar prod'un daha fazla mucking olmasına veya çalışmasına neden olan prod üzerinde hızlı bir düzeltme yaparlar, ancak kodu dev / QA / Staging sunucularına ve daha da kötüsü kaynağa koymayı unuturlar. bir sonraki resmi sürümde yaklaşık bir ay sonra kodun üzerine yazılır.

Devs tam veritabanı QA haklarına sahip olmasını tercih ediyorum çünkü başka bir sunucuya konuşlandırma, dağıtım süreçlerinde herhangi bir boşluk olup olmadığını görmelerine yardımcı oluyor. GUI kullanarak ve kaynak denetimindeki bir komut dosyasında değil, veritabanı yapısal değişikliklerinin böyle olması gerekir).

Kendi sunucu kümesine sahip olacak yeni bir Enterprise tipi istemciniz varsa, yayınlanmadan önce izinler azaltılabilir. Bunun nedeni çok fazla ihtiyaç olması ve bunu prod'da gerçekleştirebilen birkaç kişinin geri alınması ve bazen de zaman ayırması gerektiğidir. Özellikle başka bir sistemden veri içe aktaran kişiler, eğer veri yükü uzun zaman alacaksa, lansmandan önce bunları prod olarak koymakla görevlendirilebilirler. Bu insanlar veri uzmanı olma eğilimindedir ve prod'a ortalama uygulama geliştiricisinden geçici olarak erişmelerine izin veren daha yüksek bir konfor seviyesi vardır. Bu zaten canlı bir prodüksiyon sunucusuna gittiğinizde sahip olduğunuz lüks değil.

Veritabanındaki üretim haklarının sınırlandırılmasıyla ilgili en kritik şeylerden biri, geliştiricilerin çalışmalarının başka biri tarafından dağıtılabilecek bir biçimde olmasını sağlaması gerektiğidir. Bu, işin kalitesini artırma eğilimindedir çünkü bir şeyi unuttukları ya da bir şeyin işe yaramadığı için, sadece belleğe güvenirken deve'den farklı bir şekilde yaptıkları için anında düzeltmeye çalışmazlar. Ayrıca prod dağıtımları tamamen devs tipik bir komut değil bir seferde bir bütün olarak çalıştırılan komut dosyaları kullanırken kazaları tüm kullanıcı tablosunu yanlışlıkla sildim, çünkü nerede bir yan tümce türünü vurgulamayı unuttum eşyalarını çalıştırmak Ürün veritabanları için sınırlı haklara sahip bir ekibin, veritabanı değişikliklerini de kaynak kontrolünde depolaması daha olasıdır.


1
Kaynak kontrolü altına almayı unutma hakkındaki yorum için +1. Erişim haklarına bakılmaksızın ve farklı ortamlara geçişi kimin yaptığına bakılmaksızın, tüm yapıların kaynak kontrol kodundan oluşturulmasını sağlamak için mümkün olduğunca otomatik olmalıdır. Kod veya veritabanı ile uğraşmak için sunucuya kendiniz uzaktan erişim gerektiren herhangi bir işlemi mümkün olduğunca sınırlandırmak için elinizden geleni yapmalısınız.
RoboShop

8
"Geliştiriciler prod dahil tüm veritabanlarına Okuma erişimine ihtiyaç duyarlar" hayır, önceki işimde hiç olmaz. Ürün verileri, gizli olan müşteri mali kayıtlarını ve işlemlerini içerir.
ohho

3
@ohho, bu geçerli bir istisnadır, ancak geliştirmede hemen yeniden oluşturamayacağınız bir sorunu gidermek gerçekten zor olmalıdır.
HLGEM

7

Peki, Jeff Atwood'un buraya koyduğu gibi gerçekten "Vampirler (Programcılar) ve Kurtadamlar (Sysadmins)" sorusu .


Git Takım Edward Sanırım.
Joel Etherton

2
@Joel Etherton, filmi görmemiş olanlarımız için hangisi Edward Takımı?
CaffGeek

1
Eğer ki Onun iyi @Chad aslında o "Alacakaranlık" bok görmedim. En azından benim gibi görmemiş gibi davranmana gerek yok. ;)
Mayank

@Chad: Filmleri de görmedim, ancak Edward vampir. Burger King reklamları ve bir süre önce sürekli bombardıman nedeniyle bazı aptal "Alacakaranlık bulaşmış bok satın almak" kampanyası nedeniyle biliyorum. Soy un programador.
Joel Etherton

oh, görmedim iyi olduğunu biliyorum. Ve asla yapmayacağım.
CaffGeek

7

Genellikle (bu, tam bir ortam kurmanın lüksü olduğu anlamına gelir), geliştiricinin şunlara erişimi vardır:

  • Üretim sunucusu
    • Hiçbiri (Şema kurulumu için SA / PM uygulanacak, son kullanıcı init verileri sağlayacaktır)
  • UAT sunucusu
    • Yok (SA / PM, şema kurulumu ve örnek veri ekimi için uygulanacaktır)
  • Test / KG sunucusu
    • Genellikle geliştirici KG ekibine şema kurulum komut dosyası gönderir ve KG tabloları oluşturur
    • Geliştiricilerin veritabanlarına tam erişimi var, ancak nadiren değiştiriyorlar
    • Geliştiriciler KG meslektaşlarına bazı verileri ekme / düzeltme / silme konusunda yardımcı olabilir
  • Geliştirme sunucusu / localhost
    • Tam erişim

Geliştiricilerin üretim sunucularına dokunmamalarının ana nedeni şudur: Bir şey ters gittiğinde, operasyon ekibi sorumludur, ancak geliştiriciler değildir.


2
Geliştiriciler, sisteme dokunmasalar bile her zaman sorumludurlar ve bunu düzeltmeye başlayanlardır.
Erin

2
Düzeltme, veritabanındaki bir değişiklikse, düzeltmeyi üretmek geliştirme ekibinin sorumluluğundadır ve onu uygulamak için operasyon ekibinin sorumluluğundadır. Ayrıca, akıl sağlığı nedeniyle, geliştiricilerin KG ortamını hiçbir şekilde (veri veya yapı) değiştirmelerine izin vermem. Bu ortamda yapılacak herhangi bir değişiklik Üretim ortamı kadar kontrol altında olmalıdır.
Soronthar

2
Operasyon ekibiniz varsa ...
Marcie

Üretim sunucularında salt okunur erişim isteyebilirim. Hata bulmayı çok daha kolay hale getirir.
Carra

@Carra: Üretim sunucuları yasal olarak düzenlenmiş verilere sahip olabileceğinden, bunun düzenleyici sorunları olabilir (örneğin, ABD'deki bir tıbbi sistem HIPAA ile uyumlu olmalıdır). Hiç kimsenin, canlı gizli verilere erişimimi kısıtlamaya çalıştığı bir yerde bulunmadım, ama muhtemelen varlar.
David Thornley

2

İşi yapmak için gereken minimum.

Tüm geliştiricilere tam DB erişimi verilirse, birisine kızma (veya sarhoş veya aşırı yorgun veya ...) olma ve ciddi hasar verme şansı, sadece bir veritabanından okuyabiliyorsa çok daha yüksektir.

İşiniz çoğunlukla DB yazma erişimi olmadan yapılabilirse (Ve çoğunlukla haftada en az birkaç değişiklik isteğini kastediyorum), o zaman gerçekten yazma erişimine ihtiyacınız yoktur.


2

Tüm çalışma ortamlarında birbiriyle rekabet eden 2 arzu vardır.

  • İnsanlara sorunları kendi başlarına çözebilmeleri için erişim verme arzusu. Bu onların hızlı ve self servis olmalarını sağlar.
  • Hasarı, kesinti süresini veya veri kaybını (kasıtlı veya başka şekilde) önlemek için erişimi sınırlama ve kontrol etme isteği.

Dengeyi oluşturan (veya yine de olması gereken) şekli şekillendiren kısım, geliştiriciler için belirlenen beklentidir. Geliştiricilerin kendilerini sınırlamaları beklentisinin her şeye erişebildiği her işimde. Sisteme yalnızca ne yaptığınızı biliyorsanız erişin. Bu, hem geliştirici hem de sysadmin açısından ne yaptığınızı bildiğiniz anlamına geliyordu. Her iki alanda da emin değilseniz, sizi şaperon yapan biri olmadan sistemlere erişme işiniz yoktu.

Eğer bilmiyorsanız özetlemek gerekirse, kolayca yeniden oluşturulabilir dev sistemleri dışında herhangi bir sisteme erişmemelisiniz . Eğer biliyorsanız, kolayca yeniden oluşturulabilen geliştirici sistemleriniz dışında herhangi bir sisteme erişmemeniz gerekir .


2

Geliştiricilerin geliştirici veritabanlarına tam erişimi olmalıdır (ideal olarak yerel bir sunucu çalıştırmalıdırlar, ancak bu her zaman mümkün değildir). Yapım / KG veritabanına erişebilmeleri gerekir, ancak sadece verilere erişmeleri gerekir (yapıyı değiştirmek için izin almaları / bilet göndermeleri gerekir). Geliştiriciler asla üretim veritabanına rahat erişememelidir (küçük bir şirket / proje olmadıkça ve geliştiriciler de üretim desteği yapmadıkça).


1

Bence buradaki anahtar, geliştiricilerin sahip olduğu sorumluluk seviyesidir. Çok sayıda geliştiriciye sahip büyük bir kuruluşta, büyük olasılıkla yalnızca KG / Test'e salt okunur erişimle gelişime erişebileceklerdir.

Ancak, geliştirme ekibinde tüm ortamlara tam erişimi olan insanlar olmalıdır. Bu genellikle düzeltmeler yapmaktan sorumlu olan kişidir. .

Büyük bir BT mağazasında çalıştım ve çoğu insan için üretime okuma erişimimiz oldu. Baş geliştirici olarak üretim veritabanına da izin verdim. Süreç ve evrak işlemleri açısından sistem yöneticileri ve DBA'lar ile aynı yönergeleri takip etmek zorunda kaldım, ancak gerekirse acil bir düzeltme yapabilirim.


0

Çoğumuzun unuttuğu bir sorun var - veritabanını kullanan tek kişi biz olmayabiliriz! Biz bunu bunu kabul etme eğilimindeyiz ama almamalıyız. Küçük siteler bile, iş adamlarının raporları için veritabanına üçüncü taraf araçları çalıştırmasını sağlayabilir. Kurumsal sitelerde neredeyse her zaman veritabanı tablolarının birden fazla kullanıcısı olur ve 'küçük' değişiklikleriniz uygulamalarını bozabilir veya tersi de geçerlidir.

Yani bu ilk soru olmalı. İkinci mevcut personel olmalı - kendi çim koruyucu ama gerçekten iyi değildi sysadmins vardı sitelerde çalıştım. (Muhtemelen bu kadar karasal olmalarının nedeni budur - birisi etrafına bakarsa çok fazla ısı yakalayacaklarını biliyorlardı.) Bazen istediğinizden daha fazla erişiminiz olması gerekir.

Ama ideal bir dünyada, diğer insanların verdikleri noktalara katılıyorum. Canlı verilere erişmek istemiyorum çünkü açıkçası sorumluluk istemiyorum. Bir düşünün - operasyonel erişimim varsa ve bir ihlal varsa, bununla ilgili bir şeyim olmadığını kanıtlamak için çok zaman harcamak zorunda kalacağım. Verileri kişisel nedenlerle, vb. İçin paramparça etmediğimi göstermek zorunda kalabilirim. hükümet siteleri.

Test grubunun sistemine yazma / yönetici erişimi bile istemiyorum. Eğer üretim sisteminde bir şey yapamazsam, o zaman bunu test sistemlerinde yapmak istemiyorum. Neler olup bittiğini anlamaya yardımcı olması gerektiğinden, okuma erişimi bir istisnadır.

Hem bireysel hem de departman geliştirme sistemleri farklı bir hikaye. Ancak burada bile, pratikte, tüm veritabanı değişikliklerini herkesin kendi işini yapması yerine bir nokta kişiden çalıştırmak en iyisidir.


0

"Ürün veritabanlarındaki geliştiriciler için mümkün olan en az ayrıcalık" diyerek tüm cevaplara tamamen katılıyorum. Ama dürüst olmak gerekirse, geliştiricileri almak isterse veritabanına erişimi inkar edebilir. Yeterli irade ile (suçlu olsun ya da olmasın) gerekli erişimi alacaklar.

Basit bir SQL editörünü uygulamaya koymaktan kim onları geri alabilir? Bu şekilde veritabanını uygulamanın ayrıcalıklarıyla kullanabilirler. Çoğu durumda tüm gereken budur. Veritabanı güvenli bir şekilde yapılandırıldığında, nesne oluşturma veya silme ayrıcalığına sahip olmayabilirler, ancak en azından verilere okuma ve yazma erişimi vardır.

Ben zaten burada ops insanlar ağlıyor. Ancak kendinize karşı dürüst olun, kendiniz yazmadıkça (ve o zaman bile kütüphaneleri düşünmeyin) üretimde kullanılan uygulamanın tam kontrolünde değilsiniz. Ve tüm geliştiricilere, Erin'in dediği gibi, sadece ops insanlarından değil, üretim ortamından da sorumlusunuz. Bu yüzden ayrıcalıklarınızı akıllıca kullanın.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.