Welche Prozesse oder Tools ermöglichen die Aufgabentrennung, wenn Ingenieure Code bereitstellen und ausführen?

18

In stark regulierten Umgebungen wie dem Finanzdienstleistungssektor ist die Aufgabentrennung ein wesentlicher Mechanismus zur Vermeidung von Kollisionen zwischen Personen mit Entwicklungsverantwortung und Produktionsprivilegien.

Traditionell bedeutete dies, dass Entwickler Code entwickeln und dann an Operations übergeben. In vielen DevOps-Betriebsmodellen ist die Trennung zwischen Entwicklung und Operations jedoch zumindest verschwommen:

Nach monatelangen Recherchen zu den Ursachen eines Segregation-of-Duties-Mechanismus scheint es vorwiegend zu bestehen, um Sarbanes Oxley Section 404 : Bewertung des Managements der internen Kontrollen zu erfüllen :

(a) Erforderliche Regeln. Die Kommission schreibt Regeln vor, nach denen jeder gemäß Abschnitt 13 (a) oder 15 (d) des Securities Exchange Act von 1934 vorgeschriebene Jahresbericht einen internen Kontrollbericht enthalten muss, der

(1) die Verantwortung des Managements für die Einrichtung und Aufrechterhaltung einer angemessenen internen Kontrollstruktur und angemessener Verfahren für die Finanzberichterstattung angeben; und

(2) zum Ende des letzten Geschäftsjahres des Emittenten eine Beurteilung der Wirksamkeit der internen Kontrollstruktur und der Verfahren des Emittenten für die Finanzberichterstattung enthalten.

(b) Evaluierung und Berichterstattung der internen Kontrolle. Jede registrierte Wirtschaftsprüfungsgesellschaft, die den Prüfungsbericht für den Emittenten erstellt oder herausgibt, muss die von der Geschäftsführung des Emittenten vorgenommene Beurteilung der internen Kontrolle nach Buchstabe a bestätigen und darüber Bericht erstatten. Eine nach diesem Unterabschnitt ausgestellte Bescheinigung muss gemäß den vom Board herausgegebenen oder angenommenen Standards für Bescheinigungsaufträge ausgestellt werden. Eine solche Bescheinigung ist nicht Gegenstand eines gesonderten Auftrags.

Ausgehend von den Kommentaren ist es wichtig, einige Annahmen hervorzuheben, die ich mache:

  • Ich denke hauptsächlich an Finanzdienstleistungen für den Massenmarkt, dh das Transaktionsvolumen ist hoch, aber relativ niedrig. Dies wäre im Gegensatz zu kommerziellen Finanzdienstleistungen, die ein anderes Transaktionswertprofil aufweisen.
  • Das Online-Angebot eines Finanzinstituts besteht aus vielen Komponenten, die unterschiedliche Risikohinweise enthalten:
    • Geld verschieben - Verschieben von Geld zwischen Konten oder Überweisungen zwischen Konten verschiedener Eigentümer. Eine Operation, die sich mit der Bekämpfung von Geldwäsche, Betrugsbekämpfung und Embargoländern befasst, um nur einige zu nennen.
    • Kundenakquise - Weniger "riskant", da das Transaktionsvolumen im Vergleich zu Move Money gering ist, aber noch berücksichtigt werden muss.
    • Internet-Banking - Umfasst eine breite Palette von Diensten mit unterschiedlichem Risiko, wird Move Money als Teil davon betrachtet.
  • Es ist vorstellbar, dass je nach Risiko ein anderer Ansatz gewählt wird. Um dies jedoch einfach zu halten, arbeite ich an einer Lösung, die für einige der riskantesten Vorgänge gilt.

TL; DR : Es liegt in der Verantwortung des Managements sicherzustellen, dass angemessene interne Kontrollen vorhanden sind, die den Vorschriften der Securities and Exchange Commission entsprechen .

Sarbanes Oxley 404 ist in der Regel durch die Durchführung einer Top-Down-Risikobewertung zufrieden, in der zum Teil das Risiko von Kollusionen bewertet und Strategien zur Schadensminderung vorgeschlagen werden.

In einem Unternehmen, das DevOps-Praxis und -Kultur einsetzt und in dem Entwickler routinemäßig sowohl auf die Quellcodeverwaltung als auch auf die Produktion zugreifen können, wie kann eine Aufgabentrennung erreicht werden, oder allgemeiner, wie kann das Risiko einer Kollusion verringert werden.

sre financial-services operating-model Richard Slater
quelle
Die Hauptidee einer Devop-Organisation ist es, jeden im Team zur Rechenschaft zu ziehen, was in der Produktion passiert. Es kann keine Aufgabentrennung geben. Dies bedeutet hauptsächlich, dass diese Art von Organisation nicht wirklich verwendet werden kann, wenn regulatorische Anforderungen für diese Trennung bestehen.
Tensibai
@Tensbai Ich bin grundsätzlich nicht einverstanden mit der Behauptung, dass DevOps nicht mit der Aufgabentrennung vereinbar ist. Die Gesetze schreiben weder die Art der Kontrollen vor, noch schreiben die Aufsichtsbehörden den Banken und Finanzdienstleistern einen vordefinierten Prozess vor. Es ist weitgehend Sache der Organisation, zu ermitteln, was angemessen ist, und für die Aufsichtsbehörden und ihre bestellten Prüfer völlig transparent zu sein. Als Beispiel haben sowohl ING als auch Barclays DevOps-Praktiken übernommen, um die Fähigkeit zu beschleunigen, ihren Kunden einen Mehrwert zu liefern.
Richard Slater
Ja, Entwickler von Themen, die nicht an die Trennung von Vorschriften gebunden sind, und sie nutzten die Automatisierung einer traditionellen silobasierten Organisation für eingeschränkte Themen (die in der Tat nur sehr wenige sind). Sie haben nur zwei Arten von Organisationen, je nachdem, welche Art von Operationen die Software
ausführen
Es gibt keine "aufsichtsrechtliche Trennung". Die Statuten / Gesetze und Aufsichtsbehörden schreiben Finanzinstituten keine Trennung vor. Sie legen die Managementverantwortung fest, über "angemessene Kontrollen" zum Management von Finanzrisiken zu verfügen. So wie Agile die Software-Entwicklung von langen zu kleinen Zyklen übernommen hat, muss DevOps die Abläufe in kleine Zyklen unterteilen, und DevOps in Financial Services muss einen Weg finden, die Aufgabentrennung in kleine Zyklen zu unterteilen, indem beispielsweise eine CD-Pipeline erstellt wird, die dies ermöglicht erzwingt "angemessene Kontrollen" wie Peer-Review und genehmigungsbasierte Werbung.
Richard Slater
1
@ Pierre.Vriens ja die breite frage steht im titel, ich habe versucht sie durch einige annahmen zu erweitern. Rollen sind wahrscheinlich Teil der Lösung, ebenso wie Break-Glass und Privileged Account Management. Rollen und Verantwortlichkeiten sind in DevOps / Agile ein interessantes Konzept, da Sie früher einen Java-Entwickler, einen F / E-Entwickler, einen Designer, einen PM, einen Build Engineer, einen Release Manager und einen Ops Engineer hatten - jetzt haben Sie eine Gruppe von Leuten, die das können Tragen Sie mehrere Hüte - funktionsübergreifende Teams, die sich aus "Ingenieuren" zusammensetzen, die sich zwar spezialisieren, aber letztendlich die Verantwortung teilen.
Richard Slater

Antworten:

8

Ihre Frage scheint keine Vermutung über die Plattform / das Betriebssystem zu machen, um die es geht. Aus diesem Grund kann es sinnvoll sein, eine Antwort darüber hinzuzufügen, wie dies normalerweise in einer Mainframe-Umgebung getan / angegangen wird, in der die "Ingenieure" (wie in Ihrem Fragentitel) tatsächlich Gruppen von Menschen sind, die Dutzende (möglicherweise Hunderte) von Menschen sind beteiligt. Meine Antwort basiert auf der Verwendung des SCM-Produkts, mit dem ich am besten vertraut bin (ich bin nicht sicher, ob es zur Offenlegung des Produktnamens erforderlich ist).

1. Architektur

Hier sind die Highlights, wie ich Ihre Frage beantworten würde:

  • Sämtlicher Code (und verwandte Artefakte wie ausführbare Dateien usw.) werden in Dateien gespeichert, die wir zusammen die Bibliotheksstruktur nennen .
  • Für jede Umgebung auf jedem (möglicherweise entfernten) Zielsystem gibt es einen Server (eine "gestartete Task" in Mainframe-Sprache), der für ALLE (repeat: ALL) Aktualisierungen in der Bibliotheksstruktur sorgt. Es gibt einige Ausnahmen (wie Sicherheitspersonal oder Space-Management-Team), aber abgesehen davon hat niemand (wiederholen: niemand) die Berechtigung, Aktualisierungen auf Dateien in dieser Bibliotheksstruktur anzuwenden. Mit anderen Worten: Der Server erhält die exklusive Aktualisierungsberechtigung für die gesamte Bibliotheksstruktur . Achtung: OPS-Leute werden verrückt, wenn Sie hereinkommen, um ihren Zugang zu beschränken (zuerst werden sie Widerstand leisten ...). Stellen Sie also sicher, dass Sie vom oberen Management (CxO) gedeckt sind, um diese Zugangsregeln durchzusetzen ...
  • Die eigentlichen Software-Änderungen bestehen aus einer einzelnen Komponente (einem winzigen Code-Fix mitten in der Nacht ...), oder es kann sich auch um Hunderte oder Tausende von Quellen, ausführbaren Dateien oder sonstigen Artefakten handeln (während eines Veröffentlichungswochenendes). Um sie handhabbar zu machen, werden Dinge, die gleichzeitig (mehr oder weniger) zusammen verschoben werden sollen, in einem sogenannten Software-Änderungspaket gebündelt .

Mit dem oben Gesagten ist jede Art von Aktualisierung, die vom Server auf die Bibliotheksstruktur angewendet werden soll, nur über einen genau definierten Workflow möglich, den wir den Lebenszyklus eines Software-Änderungspakets (SDLC, wenn Sie es vorziehen) nennen. Um die verschiedenen Schritte in diesem Workflow tatsächlich auszuführen, ist Folgendes erforderlich:

  • Nur der Server führt die erforderlichen (und vorkonfigurierten) Schritte aus.
  • Der Server wird nur einen bestimmten Schritt ausführen (= irgendwo in der Bibliotheksstruktur etwas aktualisieren), nachdem die erforderlichen Genehmigungen (von Menschen) gesammelt wurden, um einen solchen Schritt auszuführen.
  • Die Genehmigungen können nur von Benutzern erteilt werden, die eine Rolle haben , mit der sie (= Berechtigung) solche Genehmigungen erteilen können.

2. Rollen und Berechtigungen

Der Server stellt sicher, dass der Benutzer, der versucht, etwas zu tun (z. B. "etwas zu genehmigen"), dies nur tun kann, wenn die Berechtigungen des Benutzers angemessen sind. Dieser Teil ist einfach. Sie möchten jedoch nicht das SCM-System verwenden, um alle diese Berechtigungen für alle beteiligten Benutzer zu verwalten. Dies gehört zu Ihrem Sicherheitssystem (nicht zum SCM-System!), Sodass Sie Ihren Workflow (in Ihrem SCM-System) anpassen können. Überprüfen Sie diese Berechtigungen, wann immer dies angebracht ist. Die folgenden Schritte enthalten einige weitere Details dazu.

Schritt 1: Konfigurieren Sie die Berechtigungen (im Sicherheitssystem)

  • Definieren Sie Sicherheitseinheiten in Ihrem Sicherheitssystem, mit gut für diese Unternehmen definierten Namen. Einige Beispiele (fügen Sie so viele ähnliche hinzu, wie Sie möchten):

    • PrmUnit, Verwendet für die Erlaubnis bekommen ein zu beantragen Förderung sagen Einheit -Testen.
    • PrmQA, Für das Erhalten Genehmigung ein beantragen Förderung sagen Qa -Testen (nehmen wir an , das die höchste Stufe der Prüfung ist).
    • PrdEnduserwird von Endbenutzern verwendet, die an bestimmten Teststufen beteiligt sind, um anzuzeigen, dass sie mit den Ergebnissen zufrieden sind, die bei bestimmten Tests erzielt wurden. Aus diesem Grund stimmen diese Endbenutzer der voranschreitenden Änderung in der Bibliotheksstruktur zu.
    • PrdRelmgnt, wird von Release-Managern verwendet, um eine Aktivierung in der Produktion zu autorisieren (= die letzte / höchste Ebene in der Bibliotheksstruktur).

  • Definieren Sie Benutzergruppen in Ihrem Sicherheitssystem. Einige Beispiele (fügen Sie so viele ähnliche hinzu, wie Sie möchten):

    • GrpDevs, was (sagen wir) Ihren Entwicklern entspricht (wahrscheinlich mehr als nur 1).
    • GrpEnduser, die (sagen wir) Ihren Endbenutzern entspricht (mindestens 1, vorzugsweise mit ähnlicheren Benutzern).
    • GrpRelMgnt, was (sagen wir) Ihren Release-Managern entspricht (mindestens 1, vorzugsweise ein paar mehr Benutzer).

  • Gewähren Sie Berechtigungen , auch unter Verwendung Ihres Sicherheitssystems, um ausgewählten " Sicherheitsentitäten " Zugriff auf ausgewählte " Benutzergruppen " zu gewähren . Um mit dem obigen Beispiel fortzufahren, ist Folgendes angebracht (passen Sie es an Ihre eigenen Bedürfnisse an):

    • Gruppe GrpDevserhält Zugriff auf (nur!) Sicherheitseinheit PrmUnit.
    • Gruppe GrpEndusererhält Zugriff auf (nur!) Sicherheitseinheit PrdEnduser.
    • Gruppe GrpRelMgnterhält Zugriff auf (beide!) Sicherheitseinheit PrmQAund PrdRelmgnt.

Schritt 2: Konfigurieren Sie den Workflow (im SCM-System)

Nachdem die Berechtigungen in Ihrem Sicherheitssystem konfiguriert wurden (wie in Schritt 1), müssen Sie in Ihrem SCM-System nur noch konfigurieren, wie die verschiedenen Schritte im Lebenszyklus mit den zugehörigen Sicherheitseinheiten in Ihrem Sicherheitssystem übereinstimmen. Das heißt, nur die Benutzer, die über den entsprechenden Zugriff auf die erforderliche Sicherheitseinheit verfügen, dürfen den Server auffordern, den entsprechenden Schritt im Workflow auszuführen.

Hier einige Beispiele, wie Sie Ihr SCM-System so konfigurieren, dass etwas Magisches passiert:

  • Wenn ein Benutzer Zugriff hat PrmUnit, dann ist eine solche Benutzer erlaubt eine beantragen Förderung zu Einheit -Testen. Offensichtlich sind die Benutzer in der Gruppe GrpDevsdie dazu berechtigten Benutzer (Hinweis: nicht zB die Benutzer in der Gruppe GrpRelMgnt).
  • Wenn ein Benutzer Zugriff hat PrmQA, dann ist eine solche Benutzer erlaubt eine beantragen Förderung zu QA -Testen. Offensichtlich sind die Benutzer in der Gruppe GrpRelMgntdie dazu berechtigten Benutzer (Hinweis: nicht zB die Benutzer in der Gruppe GrpDevsoder in der Gruppe GrpEnduser).
  • Wenn ein Benutzer Zugriff auf hat PrdEnduser, kann dieser Benutzer die Änderung in der Bibliotheksstruktur autorisieren (dies ist in der Regel eine Voraussetzung dafür, dass Benutzer in einer Gruppe GrpRelMgntsogar eine Änderung überprüfen können). Offensichtlich sind die Benutzer in der Gruppe GrpEnduserdie (einzigen) dafür autorisierten Benutzer.
  • Wenn ein Benutzer Zugriff darauf hat PrdRelmgnt, kann dieser Benutzer eine Aktivierung in der Produktion (= die letzte / höchste Ebene in der Bibliotheksstruktur) autorisieren .

3. Erwarten Sie das Unerwartete und seien Sie bereit dafür

Das obige ist nur eine Blaupause, die hoffentlich hilft zu verstehen, wie letztendlich der Server für die Aufgabentrennung sorgt ... vorausgesetzt, Sie haben die CxO-Deckung, um einige Zugriffsregeln auferlegen zu können, die nicht jedem gefallen werden.

Um das Bild wie oben beschrieben zu vervollständigen, erstellt der Server einen Audit-Trail (Protokollierung) von allen Vorgängen im System. Damit ist es jederzeit möglich Fragen wie zu beantworten

Was ist wann und warum passiert und welcher autorisierte Benutzer hat es tatsächlich genehmigt ... im Voraus?

Am schwierigsten ist es jedoch wahrscheinlich, geeignete Berichterstellungstools zur Verfügung zu haben (und zu wissen, wie man sie verwendet). Zumindest, um Anfragen von IT-Auditoren (leicht) zu befriedigen (ihre Fragen können sehr herausfordernd sein). Sie können aber auch auf relevante Protokollsätze in Ihrem SCM-System verweisen, um alle Arten von "Was ist passiert" -Fragen in Krisensituationen zu beantworten, in denen (ein Teil der) Produktion ausfällt.

PS: Ich überlasse es jedem selbst, ob meine Antwort Ja oder Nein DevOps-konform ist.

Pierre.Vriens
quelle
Das klingt nach einer grundlegenden Implementierung der Top-Down-Risikobewertung. Ich verstehe nicht, wie sie die Frage beantwortet, wie dies auf devops-Weise implementiert werden könnte, wenn devs die Berechtigung hätten, den "Deploy" -Schalter auszulösen. Ist die Idee, dass Sie es nicht in einer Devop-Organisation tun können?
Tensibai
@Tensibai "wenn" Entwickler die Berechtigung (Rolle) der (z. B.) endgültigen Genehmigung für Produkte (die sie in solchen Organisationen normalerweise NICHT haben) haben würden, würde ein solcher Server (gestartete Task) die Bereitstellung starten. Und gemäß dem Titel der Frage denke ich, dass dies eine mögliche Antwort ist. Man könnte sich jedoch fragen, ob dies das ist, was wir eine DevOps-Organisation nennen würden, aber ich weiß, dass Prüfer diese Art von "konfigurierbarer" Aufgabenteilung wirklich mögen (z. B. Vieraugen und Variationen davon). Vielleicht kann uns Richard bei seiner Sichtweise helfen?
Pierre.Vriens
1
Ich stimme zu, dass Auditoren es absolut mögen. Ich habe nur übersehen, wie dies mit der Explosion des Zugriffs zusammenhängt, die Auditor normalerweise nicht mag, wenn die Liste mehr als 6 bis 7 Personen enthält. Zu sagen, dass es nicht passt, ist meiner Meinung nach eine absolut gültige Antwort.
Tensibai,
1
Vielen Dank, dass Sie sich so viel Zeit für eine Antwort genommen haben. Eigentlich denke ich über die Implementierung einer 3-Personen-Regel nach, bei der ein Entwickler den Code schreibt, ein anderer Entwickler den Code überprüft und eine dritte Person den Freigabeknopf drückt, um den Code bereitzustellen. Die andere Überlegung ist, dass dies Teil einer unternehmensweiten Agile / DevOps-Übernahme ist. Die Entwicklungsteams sind recht klein. Mit dem Nettoeffekt, dass kleine Gruppen von Menschen Zugang zur Produktion haben, scheint dies unter Risikogesichtspunkten günstig zu sein .
Richard Slater
1
@ Pierre.Vriens Kann nicht zweimal upvote, tolle Erweiterung :)
Tensibai
5

Aufgrund meiner Kenntnisse der französischen "internen Kontroll" -Vorschriften, die den von Ihnen genannten SEC-Vorschriften in etwa entsprechen, gehe ich davon aus, dass eine Verknüpfung mit einem französischen Rechtstext hier nicht wirklich nützlich wäre und mir keine gute Übersetzung bekannt ist.

In einem idealen Modell "Sie bauen es, Sie führen es aus" ist jeder im Team für die Änderung verantwortlich. Die Risikobewertung kann nicht durch eine Aufgabentrennung erzwungen werden. Die einzige Möglichkeit, die Einhaltung der Vorschriften zu gewährleisten, besteht in einer regelmäßigen Prüfung der Transaktionen innerhalb eines kurzen Zyklus sowie einer unveränderlichen Verfolgung der Maßnahmen, um zu der Person zurückzukehren, die die Freigabe vorgenommen hat .
Dies bedeutet, dass alle Transaktions- und Aktionsprotokolle in einen eingeschränkten Bereich verschoben werden, auf den das Team keinen Zugriff hat, und dass eine Änderung der protokollierten Daten durch Funktionstests abgefangen wird, auf die das Team keinen Zugriff hat durch die Prüfung und verfolgt zu seinem Autor.

Dies gilt nicht für alle Produkte. Zum Zeitpunkt des Schreibens in Frankreich muss jedes Unternehmen, das Geld ausgeben darf (hauptsächlich Banken), sicherstellen, dass jede Transaktion erfasst wird, und kann daher nicht das Risiko eingehen, eine Transaktion zu verpassen.
Auf der anderen Seite besteht keine rechtliche Verpflichtung, ein kommerzielles Angebot oder eine Risikobewertung nachzuverfolgen, wenn jemand um einen Kredit bittet. Daher lassen sich die Produkte, die für diese Kundenauswahl und die Berechnung der Gebühren im Angebot zuständig sind, leichter in eine Stelle einfügen -Release-Audit-Modell.

Die Hauptidee ist, dass das Freigabemodell gemäß den Risikobewertungspflichten angepasst werden muss.

Eine verwandte Ressource ist die Norm ISO27001 .

Tensibai
quelle
Interessante Antwort und sehr relevant, da viele europäische Banken in der Tat in Frankreich tätig sind. Gibt es eine Chance, dass Sie die Bedeutung von "Geld ausgeben" erweitern, dh, Sie können nur Geld an einem Geldautomaten ausgeben, oder Sie müssen den Restbetrag überweisen. In diesem Fall wäre eine Verknüpfung mit den Statuten wertvoll, da sie einen Hinweis auf die einschlägigen Gesetze gibt, unabhängig von der Sprache, in der sie gesprochen werden.
Richard Slater,
@RichardSlater Kurz gesagt, jedes Unternehmen, das mit Geld arbeitet, kann sowohl eine reine Investmentgesellschaft als auch Kreditvermittler entlang der traditionellen Banken sein. Meist handelt es sich um alles, was irgendwo finanzielle Auswirkungen hat (von wenigen Ausnahmen abgesehen, die die Behörde unter bestimmten Umständen geben kann). Die legale "Liste" auf Französisch ist hier, aber selbst auf Französisch ist dies nicht immer offensichtlich.
Tensibai
Ich gehe
Richard Slater
@ Richard in der Tat scheint, dass der französisch-englische Link nicht auf Wikipedia aktualisiert wurde. Ich werde später aktualisieren (oder wenn Sie möchten, können Sie es
gerne
Related: Wie kann ich Entwickler in meinem Team davon überzeugen, "Sie bauen es, Sie leiten es" zu akzeptieren?
Dan Cornilescu
0

IMHO, Developers & Operations könnten durch nichts anderes als zwei Git-Repositorys für dieselbe Codebasis mit jeweils unterschiedlichen Berechtigungsmodellen dargestellt werden, so dass Teams sich überhaupt nicht gegenseitig in die Arbeit einmischen.

Nennen wir sie Dev.mygithub.co & ops.mygithub.co , nur als Beispiel.

Die Idee ist, dass Entwickler können zum Erstellen / Zweig / merge Inhalt ihres Herzens -git vollständige Rückverfolgbarkeit bietet und das ist , was hier- mittlerweile zählt, in den Momenten , dass Rechtsrahmen impliziert eine Bewertung Aufwand Pull - Request kann angehoben werden, die Verschmelzung geschieht auf kontrollierte Weise.

Ein Entwicklungszweig, der dieses Konzept auf die nächste Stufe hebt, kann über einen weiteren Pull-Request- Act in die Produktion der Remote-Ops übertragen werden . Der letzte Teil muss durch die Hände und Augen des Betriebs geschehen, da sie die Verantwortung haben, ihn in die Produktion zu überführen, und sie den Überprüfungsgrad auswählen.

Ein solches System ermöglicht uneingeschränkte Flexibilität, vollständige Rückverfolgbarkeit, die frühzeitige Erkennung von Problemen über eine Vielzahl von Prozessen, die Trennung von Bedenken und eine sehr vernünftige Benutzererfahrung im Prozess !

NB Das oben beschriebene Modell kann befolgt werden, auch wenn sich Ops & Dev vollständig überlappen!

fgeorgatos
quelle
1
Sicherlich könnte dieselbe Kontrolle durch Pull-Anforderungen und Post-Commit-Hooks erreicht werden, die sicherstellen, dass Entwickler frei Commit ausführen können, Merge-Commits jedoch nur von einer genehmigten Gruppe von Personen durchgeführt werden können. Ebenso könnte derselbe Post-Commit-Hook sicherstellen, dass die Autoren der Commits, aus denen die Pull-Anforderung bestand, die Person, die die Pull-Anforderung gestellt hat, nicht mit einbezogen haben.
Richard Slater
@RichardSlater: Der Grund, warum Sie möglicherweise zwei unterschiedliche Repositorys haben möchten, besteht darin, dass Sie sowohl Entwicklern das Zusammenführen ermöglichen müssen , wenn sie Code im Entwicklermodus frei austauschen, als auch die meisten Entwickler daran hindern, Code zusammenzuführen, wenn dies der Fall ist in Richtung Produktion gehen (modulo SysOps, dh die sogenannte "anerkannte Personengruppe").
Fgeorgatos
Wiederum können Sie dies mit Post-Commit-Hooks und Pull-Anfragen erreichen, ganz zu schweigen davon, dass GitHub Enterprise geschützte Zweige zulässt.
Richard Slater
0

höher ist teurer:

  • Unterschiedliche Entwicklungs- und Betriebsseiten und Methoden, um die Arbeit von einer zur anderen zu übertragen
  • verschiedene dev and ops Systeme & Methoden wie oben
  • verschiedene dev und ops git / vcs Repositories & verwandte Methoden
  • verschiedene dev und ops git / vcs Zweige (geschützt) & verwandte Methoden

Je nachdem, was Sie tun, sind einige Lösungen besser als andere. Wenn Sie beispielsweise zwei Teams mit unterschiedlichen Rollen bedienen müssen, die jeweils Eigentümer sind und vollständige Nachverfolgbarkeit bieten, bewegen Sie sich über die ersten drei.

Kurz gesagt, alles, was einen Mann oder eine Frau dazu zwingt, kann den Ball nicht alleine nehmen und damit rennen, und er / sie überschreitet eine eindeutige explizite Grenze zwischen Entwicklern. Je nach Risikograd kann diese Grenze nun durchgesetzt werden oder nicht.

fgeorgatos
quelle