Wie viel Datenbankzugriff sollten Entwickler haben? [geschlossen]

Daher habe ich als Entwickler an vielen verschiedenen Arbeitsplätzen gearbeitet, und mein Zugriff auf die Datenbank war unterschiedlich. Ich habe normalerweise keinen produktiven Datenbankzugriff.

Die meiste Zeit habe ich Zugriff auf die Testdatenbank, aber es variiert. Manchmal kann ich Datenbanken und Daten nach Belieben ändern, aber normalerweise gibt es andere Vorkehrungen. Gerne darf ich nur lesend auf die Daten zugreifen.

Ich habe an einem Ort gearbeitet, an dem ein DBA-Team die Datenbanken verwalten würde. Wir konnten überhaupt keine Änderungen vornehmen, es sei denn, wir haben ein Formular mit dem SQL-Skript eingereicht, damit sie "inspizieren" können. Sie hatten normalerweise nicht viel mit dem Projekt selbst zu tun, so dass es die meiste Zeit nur darum ging, F5 zu drücken.

Ehrlich gesagt kann ich verstehen, warum Prod gesperrt werden muss, aber ich bevorzuge so viel Datenbankzugriff in den Entwicklungs- und Testumgebungen. Ich denke, die meisten Entwickler sind einigermaßen in der Lage, sich in einer Datenbank zurechtzufinden. Aber ich würde gerne Meinungen hören? Wie viel Datenbankzugriff sollten Entwickler haben? Kann man uns trauen, dort oben nichts zu zerbrechen?

Entwickler benötigen Lesezugriff auf alle Datenbanken, einschließlich prod. Manchmal liegt das Problem darin, dass die Daten auf Prod nicht den Erwartungen entsprechen und die Daten, die das Problem verursachen, angezeigt werden müssen, da sie nicht auf dev reproduziert werden können.

Entwickler sollten keine Schreibrechte für Produktionsdaten oder Rechte zum Erstellen von Objekten haben. Es sollte nichts passieren, was nicht Teil einer offiziellen Veröffentlichung ist. Allzu oft tun die Leute eine schnelle Lösung für Produkte, die entweder nicht funktionieren, was dazu führt, dass Produkte noch mehr durcheinander geraten oder funktionieren, aber sie vergessen, den Code auf den Dev / QA / Staging-Servern abzulegen, und noch schlimmer in der Quelle Kontroll-Repository und der Code wird etwa einen Monat später in der nächsten offiziellen Version überschrieben.

Ich bevorzuge Entwickler mit vollständigen Datenbank-QA-Rechten, da sie durch die Bereitstellung auf einem anderen Server feststellen können, ob Lücken in ihrem Bereitstellungsprozess bestehen. (Hoppla, ich habe diese Tabelle entsprechend geändert. Hoppla, ich habe diese Änderung vergessen Verwenden der GUI und nicht in einem Skript in der Quellcodeverwaltung (wie etwaige strukturelle Änderungen an der Datenbank erfolgen müssen).

Wenn Sie einen neuen Client vom Typ Enterprise haben, der über einen eigenen Satz von Servern verfügt, können die Berechtigungen vor der Inbetriebnahme gesenkt werden. Das liegt daran, dass so viel passieren muss und die wenigen Leute, die es schaffen können, einen Rückstand bekommen und sich manchmal sogar eine Auszeit nehmen müssen. Insbesondere die Personen, die Daten von einem anderen System importieren, werden möglicherweise aufgefordert, diese vor dem Start auf einen Stachel zu setzen, wenn der Datenladevorgang längere Zeit in Anspruch nimmt. Bei diesen Personen handelt es sich in der Regel um Datenspezialisten, und es gibt ein höheres Maß an Komfort, ihnen vorübergehenden Zugriff auf Produkte zu gewähren, als dies bei durchschnittlichen Anwendungsentwicklern der Fall ist. Dies ist kein Luxus, den Sie haben, wenn Sie zu einem bereits aktiven Produktionsserver gehen.

Eines der wichtigsten Dinge bei der Einschränkung der Produktionsrechte für die Datenbank ist, dass die Entwickler sicherstellen müssen, dass ihre Arbeit in einer Form vorliegt, die von einer anderen Person bereitgestellt werden kann. Dies führt tendenziell zu einer Verbesserung der Qualität der Arbeit, da sie nicht sofort versuchen, Korrekturen vorzunehmen, weil sie etwas vergessen haben oder etwas nicht funktioniert haben, weil sie es auf einem anderen Produkt als auf einem Entwickler gemacht haben, wenn sie sich nur auf das Gedächtnis verlassen. Sie verlieren auch das "Ups, ich habe versehentlich die gesamte Benutzertabelle gelöscht, weil ich vergessen habe, eine Where-Klausel hervorzuheben", wenn Produktbereitstellungen ausschließlich Skripts verwenden, die als Ganzes ausgeführt werden, und nicht einen Befehl auf einmal, wie es für Entwickler typisch ist Dinge auf Stoß laufen lassen. Ein Team mit eingeschränkten Rechten für Produktdatenbanken speichert wahrscheinlich auch Datenbankänderungen in der Quellcodeverwaltung.

Nun, es ist wirklich eine Frage von "Vampiren (Programmierer) gegen Werwölfe (Sysadmins)", wie Jeff Atwood es hier formuliert hat .

In der Regel (das bedeutet, dass es den Luxus gibt, eine vollständige Umgebung einzurichten) hat der Entwickler Zugriff auf:

• Produktionsserver
  • Keine (SA / PM wird für die Schemaeinrichtung angewendet, Endbenutzer wird Init-Daten bereitstellen)
• UAT-Server
  • Keine (SA / PM wird für das Einrichten des Schemas und das Seeding der Beispieldaten angewendet.)
• Test / QS-Server
  • Normalerweise sendet der Entwickler ein Schema-Setup-Skript an das QA-Team und QA erstellt die Tabellen
  • Entwickler haben uneingeschränkten Zugriff auf Datenbanken, können diese jedoch nur selten ändern
  • Entwickler können QA-Kollegen dabei unterstützen, Daten zu säen, zu patchen oder zu löschen
• Entwicklungsserver / localhost
  • Voller Zugriff

Der Hauptgrund, warum Entwickler Produktionsserver nicht berühren sollten, ist: Wenn etwas schief geht, ist das Operationsteam verantwortlich, nicht jedoch die Entwickler.

Das absolute Minimum, das Sie benötigen, um die Arbeit zu erledigen.

Wenn alle Entwickler vollen DB-Zugriff haben, ist die Wahrscheinlichkeit, dass jemand wütend (oder betrunken, oder extrem müde oder ...) wird und schwerwiegenden Schaden anrichtet, viel höher, als wenn er nur aus einer Datenbank lesen kann.

Wenn Ihre Arbeit meist ohne DB-Schreibzugriff erledigt werden kann (und damit meine ich meistens ein paar Änderungswünsche pro Woche), dann brauchen Sie wirklich keinen Schreibzugriff.

Es gibt 2 konkurrierende Wünsche in allen Arbeitsumgebungen.

• Der Wunsch, Menschen Zugang zu ermöglichen, damit sie Probleme selbst lösen können. Dadurch können sie schnell und selbstständig arbeiten.
• Der Wunsch, den Zugriff zu beschränken und zu kontrollieren, um Schäden, Ausfallzeiten oder Datenverlust (absichtlich oder auf andere Weise) zu verhindern.

Ein Teil dessen, was das Gleichgewicht bestimmt (oder sollte), ist die Erwartungshaltung der Entwickler. In jedem Job, den ich hatte, hatten Entwickler Zugriff auf alles, was sie erwartet hatten, um sich einzuschränken. Greifen Sie nur auf das System zu, wenn Sie wissen, was Sie tun. Das bedeutete, dass Sie sowohl vom Entwickler- als auch vom Sysadmin-Standpunkt aus wussten, was Sie taten. Wenn Sie sich in beiden Bereichen nicht sicher waren, hatten Sie kein Geschäft, auf die Systeme zuzugreifen, ohne dass jemand Sie beaufsichtigte.

Zusammenfassend lässt sich sagen, dass Sie keinen Zugriff auf ein anderes System haben sollten, als auf leicht wiederherstellbare Entwicklungssysteme . Wenn Sie es wissen, sollten Sie nicht auf ein anderes System zugreifen als auf Ihre leicht wiederherstellbaren Entwicklungssysteme .

Entwickler sollten vollen Zugriff auf Entwicklerdatenbanken haben (im Idealfall sollten sie einen lokalen Server betreiben, aber das ist nicht immer möglich). Sie sollten Zugriff auf die Build- / QA-Datenbank haben, aber nur auf die Daten (müssen die Erlaubnis einholen / ein Ticket einreichen, um die Struktur zu ändern). Entwickler sollten niemals gelegentlichen Zugriff auf die Produktionsdatenbank haben (es sei denn, es handelt sich um ein kleines Unternehmen / Projekt, und Entwickler leisten auch Produktionsunterstützung).

Ich denke, der Schlüssel liegt in der Verantwortung der Entwickler. In einer großen Organisation mit vielen Entwicklern haben sie wahrscheinlich nur Zugriff auf die Entwicklung mit Lesezugriff auf QA / Test.

Es sollten jedoch Mitarbeiter im Entwicklungsteam vorhanden sein, die uneingeschränkten Zugriff auf alle Umgebungen haben. In der Regel ist dies die Person, die für die Vornahme von Korrekturen usw. verantwortlich ist. Dies ist zwar etwas riskant, es handelt sich jedoch um einen Kompromiss zwischen dem Vertrauen, das Sie dem Entwickler entgegenbringen, der Geschwindigkeit, mit der Sie das Problem beheben möchten, und den Risiken, die mit dem Durcheinander des Systems oder der Offenlegung von Informationen im System verbunden sind .

Ich habe in einem großen IT-Geschäft gearbeitet und wir hatten für die meisten Menschen Lesezugriff auf die Produktion. Ich als leitender Entwickler hatte auch Berechtigungen für die Produktionsdatenbank. Ich musste immer noch die gleichen Richtlinien wie die Systemadministratoren und Datenbankadministratoren in Bezug auf Prozess und Papierkram befolgen, aber ich konnte bei Bedarf auch eine dringende Lösung finden.

Es gibt ein verwandtes Problem, das die meisten von uns vergessen - wir sind möglicherweise nicht die einzigen, die die Datenbank nutzen! Wir neigen dazu, dies für selbstverständlich zu halten, sollten es aber nicht. Selbst auf kleinen Websites können die Geschäftsleute Tools von Drittanbietern für ihre Berichte in der Datenbank ausführen. Auf Unternehmenswebsites gibt es fast immer mehrere Benutzer der Datenbanktabellen, und Ihre "kleine" Änderung führt möglicherweise zu Fehlern bei den Anwendungen und umgekehrt.

Das muss also die erste Frage sein. Das zweite muss das verfügbare Personal sein - ich habe an Standorten gearbeitet, an denen Sysadmins ihren Rasen schützten, die aber wirklich nicht so gut waren. (Das ist wahrscheinlich der Grund, warum sie so territorial sind - sie wussten, dass sie viel Hitze bekommen würden, wenn sich jemand umschaut.) Manchmal muss man mehr Zugang haben, als man möchte.

Aber in einer idealen Welt stimme ich den Aussagen anderer zu. Ich möchte keinen Zugriff auf Live-Daten, da ich ehrlich gesagt keine Verantwortung übernehmen möchte. Denken Sie darüber nach - wenn ich operativen Zugriff habe und es eine Lücke gibt, muss ich viel Zeit darauf verwenden, zu beweisen, dass ich nichts damit zu tun habe. Ich muss möglicherweise nachweisen, dass ich die Daten aus persönlichen Gründen usw. nicht überprüft habe. Viele Websites nehmen den Datenschutz sehr ernst, insbesondere. Regierungsseiten.

Ich möchte nicht einmal Schreib- / Administratorzugriff auf das System der Testgruppe. Wenn ich auf dem Produktionssystem etwas nicht machen kann, dann möchte ich es auf den Testsystemen nicht können. Lesezugriff ist die Ausnahme, da es notwendig ist, um herauszufinden, was los ist.

Individuelle und abteilungsbezogene Entwicklungssysteme sind eine andere Geschichte. Aber auch hier ist es in der Praxis in der Regel am besten, alle Datenbankänderungen durch eine Einzelperson auszuführen, anstatt dass jeder sein eigenes Ding macht.

Ich stimme der Antwort voll und ganz zu und sage "so wenig Rechte wie möglich für Entwickler von Produktdatenbanken". Aber um ehrlich zu sein, wer kann Entwicklern den Zugriff auf die Datenbank verweigern, wenn sie es wollen? Mit genügend Willen (sei es kriminell oder endgültig) bekommen sie den nötigen Zugang.

Wer kann sie davon abhalten, einen einfachen SQL-Editor in die Anwendung einzufügen? Auf diese Weise können sie die Datenbank mit den Rechten der Anwendung verwenden. In den meisten Fällen ist dies alles, was benötigt wird. Wenn die Datenbank sicher konfiguriert ist, verfügen sie möglicherweise nicht über die Berechtigung zum Erstellen oder Löschen von Objekten, haben jedoch mindestens Lese- und Schreibzugriff auf die Daten.

Ich weine schon hier die ops Leute. Aber seien Sie ehrlich: Sie haben keine vollständige Kontrolle über die in der Produktion bereitgestellte Anwendung, es sei denn, Sie schreiben sie selbst (und denken auch dann nicht an Bibliotheken). Und für alle Entwickler, wie Erin bereits sagte, sind Sie auch für die Produktionsumgebung verantwortlich, nicht nur für die Mitarbeiter des Unternehmens. Nutzen Sie Ihre Privilegien also mit Bedacht.