Wie kann DevOps helfen, Software Escrow-Verfahren zu verbessern?


7

Stellen Sie sich einen Softwareanbieter und einen lizenzierten Kunden einer Software dieses Anbieters vor, wobei die lizenzierte Software entweder vor Ort (beim Kunden) oder im Format einer SaaS-Lösung (vom Anbieter gehostet) verwendet wird. Der Kunde erhält jedoch nur Zugriff auf das, was zur Verwendung / Ausführung der Software erforderlich ist (ausführbare Dateien und ähnliche Dinge), also nicht auf die Quellkomponenten und alles, was damit zusammenhängt, um die ausführbaren Dateien zu erstellen.

Um die Geschäftskontinuität des Kunden in Szenarien zu schützen, in denen mit dem Anbieter möglicherweise ein Fehler auftritt (z. B. Insolvenz), können beide Parteien eine Art Software Escrow-Vereinbarung (SE ... 'also') (auch als Quellcode-Escrow bezeichnet ) vereinbaren . Mit dieser Vereinbarung vereinbaren beide Parteien, einen Dritten (= einen "Software Escrow Agent") einzubeziehen, dem beide Parteien vertrauen. Dies sind die Highlights einer solchen SE-Vereinbarung (= Spezifikationen des tatsächlichen SE-Prozesses):

  • ALLE Softwarekomponenten (im Zusammenhang mit der lizenzierten Software) vom Softwareanbieter an einem vereinbarten Ort im Zusammenhang mit dem SE-Agenten hinterlegt werden. Zu diesen Einzahlungen gehören die ausführbaren Dateien, aber auch die Quellkomponenten und alles, was damit zusammenhängt, um die ausführbaren Dateien zu erstellen (sogar Dokumentation, Anweisungen usw. zum Erstellen der ausführbaren Dateien).
  • Da der Softwareanbieter für die Dauer der Softwarelizenz mehrere Releases erstellen kann und der Kunde das Recht hat, solche neuen Releases (gemäß Lizenzvereinbarung) zu erhalten, besteht ein Teil dieser SE-Vereinbarung darin, dass "mit jeder größeren neuen Version" (was auch immer "Major" bedeuten mag ...), die an den SE-Agenten gelieferte Anzahlung wird ebenfalls aktualisiert / aktualisiert.
  • Wenn bestimmte Bedingungen erfüllt sind (z. B. Insolvenz des Anbieters), liefert der Software Escrow-Agent dem lizenzierten Kunden auf Anfrage dieses Kunden eine Kopie von allem, was hinterlegt wurde, damit der Kunde das weiterhin verwenden kann Software, und passen Sie bei Bedarf sogar den Quellcode an, um ihn weiterhin für das Geschäft des Kunden zu verwenden.

Eine übliche Praxis für einen solchen SE-Agenten, sich zu engagieren, ist eine juristische Person / juristische Person, beispielsweise ein Anwalt. Aber um die SE-Einzahlungen tatsächlich "zu verarbeiten" (von den SE-Agenten), müssen alle Arten von Release-Management- und / oder Software-Bereitstellungsaufgaben von jemandem oder etwas (dem armen SE-Agenten) ausgeführt werden, der es wahrscheinlich nicht weiß überhaupt, was die lizenzierte Software tun soll ... Spaß garantiert!

Meine Frage :

Wie kann DevOps dazu beitragen, die oben beschriebenen Software-Escrow-Verfahren zu verbessern? Wie was für-Werkzeuge würden Sie empfehlen, für die Erfüllung welchen Teils der SE-Vereinbarung verwendet zu werden? Und gegebenenfalls mit welchen (vorzugsweise Open Source) Softwarelösungen dafür?

Anmerkungen :

  1. Um die Sache nicht weiter zu komplizieren, gehen Sie einfach davon aus, dass zwischen allen Beteiligten vereinbart wurde, dass der SE-Agent KEINE " Überprüfungen " der getätigten Einzahlungen vornehmen muss. Das heißt: Was auch immer hinterlegt ist, wird als vollständig, aktuell, dokumentiert usw. angenommen.

  2. Über "Hauptneuversion": Nehmen Sie an, dass es jedes Jahr zwischen 1 und 3 gibt, was bedeutet, dass der lizenzierte Kunde nur erwartet, über den SE-Agenten Zugriff auf diese Versionen zu erhalten. Auch wenn Zwischenlieferungen (wie Fixes oder Betaversionen) an den lizenzierten Kunden stattgefunden haben, gelten diese Arten von Lieferungen als außerhalb des Geltungsbereichs liegend. Auch wenn es nur war, weil:

    • Der SE-Agent berechnet "für jede vom SE-Agent zu verarbeitende Einzahlung".
    • Der lizenzierte Kunde ändert Releases selten und ist nur daran interessiert, die SE-Vereinbarung nutzen zu können, wenn etwas schief geht. Für genau das Release, das er gerade ausführt, läuft etwas schief.

Antworten:


4

Eine sehr interessante Frage. Unter der Annahme, dass das Ziel eines Software-Escrow-Prozesses darin besteht, einer dritten Partei die Übernahme oder Nominierung einer zusätzlichen Partei zur Erfüllung der Verantwortung des Softwareanbieters zu ermöglichen, würde ich die folgenden Elemente eines DevOps-Betriebsmodells vorschlagen, die dies unterstützen würden Software-Treuhandkonto:

  1. Infrastruktur als Code - Die effektive Dokumentation durch eine ausführbare Spezifikation der abhängigen Infrastruktur, die in der Quellcodeverwaltung gespeichert und versioniert wird, bietet die Umgebungen, in denen der Quellcode entwickelt wird. Im Gegensatz zur statischen Dokumentation in Textdateien, da diese regelmäßig von der Software ausgeführt wird Anbieter, um ihre eigenen Umgebungen zu bauen, ist es nicht veraltet, unter "Bit Rot" zu leiden. Dies hat immer den größten Wert, wenn die gesamte Entwicklungspipeline in der Quellcodeverwaltung unter Verwendung von Infrastructure-as-Code-Principals erstellt und verwaltet wird.

  2. Kontinuierliche Integration - Das Ziel der kontinuierlichen Integration besteht darin, eine Reihe von Schritten auszuführen, die die Lösung regelmäßig integrieren, idealerweise bei jeder Änderung. In der Regel bedeutet dies, dass beim Einchecken und Verschieben in ein zentrales Repository eine Reihe von Tests ausgeführt werden, die den Prozess validieren. Aus Sicht der Software-Übertragungsurkunde würde ich erwarten, dass dies auch eine funktionierende Version in ein sekundäres "Backup" -Repository überträgt, das den Dritten gehört und von diesen betrieben wird . Es ist wichtig zu beachten, dass dies sowohl rechtlich als auch finanziell vom Softwareanbieter "nicht verbunden" sein muss.

  3. Kontinuierliche Bereitstellung - Das Ziel der kontinuierlichen Bereitstellung besteht darin, Software häufig in einem funktionierenden Zustand bereitzustellen. In diesem Sinne ist die dritte Partei nur ein weiteres Bereitstellungsziel, für das die Ausgaben bereitgestellt werden sollen, obwohl die Infrastruktur auf der Struktur der dritten Partei wahrscheinlich nicht aktiv hochgefahren wird .

Einige andere Überlegungen, die in die Gleichung einfließen sollten, sind:

  • Durch die Umstellung von der statischen Dokumentation auf die Infrastruktur als Code wird der Aufwand für die Aktualisierung der Dokumentation, in der die Installation, Konfiguration und Wiederherstellung von Software beschrieben wird, erheblich reduziert.
  • Vergessen Sie nicht die Verwaltung von Geheimnissen wie X.509-Zertifikaten, symmetrischen Schlüsseln, Kennwörtern und Lizenzschlüsseln. Diese können in der Quellcodeverwaltung gespeichert werden, haben jedoch ihre eigenen Nachteile.

Aus Sicht der Tools hängt dies sehr stark von der Entwicklungsumgebung ab. Ich glaube jedoch nicht, dass es spezielle Tools für das Software-Treuhandkonto gibt:

Wenn Sie in der Lage sind, die Prinzipien der Infrastruktur als Code, der kontinuierlichen Integration und der kontinuierlichen Bereitstellung auf ein Softwarepaket anzuwenden, können Sie damit Ihre Verpflichtungen aus einem Software-Treuhandvertrag erfüllen.


Was würde Capistrano auf Puppe oder Koch erfordern?
Tensibai

Beeindruckende Antwort, ich muss es noch ein paar Mal verdauen. Aber im Moment schon diese Kommentare / Gedanken: (1) Wen meinen Sie mit "Lieferant" (können Sie versuchen, "Softwareanbieter" oder "SE-Agent" zu verwenden, um dies zu klären)? (2) "Geheimnisse" wären in diesem Fall die Lizenzschlüssel (betrachten Sie diese auch als Codeteile, z. B. mit PU-IDs usw.). (3) Als ITer stimme ich der "kontinuierlichen" Empfehlung zu. "Kontinuierliche Einzahlungen" würden jedoch auch "kontinuierliche Rechnungen" bedeuten (= nicht erschwinglich), daher bin ich mir (noch) nicht sicher, wie die "Veröffentlichung" (wie 1 alle 6 Monate) dazu passt
Pierre.Vriens

@Tensibai: So wie ich das sehe, ist Capistrano ein Bereitstellungstool mit einer Konfigurationsverwaltungsfunktion. Ansible ist ein Konfigurationsmanagement-Tool mit einer Bereitstellungsfunktion. Nur weil Sie ein Tool für beide Aufgaben verwenden können, bedeutet dies nicht, dass Sie dies tun sollten .
Richard Slater

@ Pierre.Vriens - Ich habe versucht, sowohl Ihren Punkt 1 als auch Ihren Punkt 2 anzusprechen . Punkt 3 erfordert jedoch möglicherweise etwas mehr Input. Grundsätzlich ändert sich die Branche, wenn ein SE-Agent vorschlägt, dass jede Einzahlung zu einer Rechnung führt, und dann respektvoll sein Kostenmodell erneut besuchen muss. Die Konsequenzen, wenn sie dies nicht tun, sind der Unterschied zwischen dem Gedeihen in einer DevOps-Welt und dem Verblassen in die Veralterung.
Richard Slater

Dieser Blog-Beitrag ist ein wenig alt und berücksichtigt keine Ressourcen des Küchenchefs , die hier von Capistrano inspiriert eingesetzt werden.
Bedeutet

1

Aber um die SE-Einzahlungen tatsächlich "zu verarbeiten" (von den SE-Agenten), müssen alle Arten von Release-Management- und / oder Software-Bereitstellungsaufgaben von jemandem oder etwas (dem armen SE-Agenten) ausgeführt werden, der es wahrscheinlich nicht weiß überhaupt, was die lizenzierte Software tun soll ... Spaß garantiert!

Ich würde keine Geschäfte mit einem SE-Anbieter machen, der eine solch unglückliche Situation zulässt - sie wissen nicht, was sie tun.

Wenn die SE-Einlagen vom SE-Agenten auf irgendeine Weise verarbeitet werden sollen, muss das genaue und vollständige Verarbeitungsverfahren in den Vereinbarungen vollständig dokumentiert sein , damit es tatsächlich verwendet werden kann.

Dies sollte auch die genaue Umgebungsspezifikation (oder das Verfahren zur Reproduktion) und die für eine solche Verarbeitung verwendete Toolchain enthalten. Mit anderen Worten, die Wahl steht dem SE-Agenten nicht wirklich einseitig offen. Außer vielleicht für die eigentliche Speicherstrategie (persönlich würde ich diese Auswahl auch in die Vertragsspezifikation aufnehmen, selbst wenn die Auswahl einseitig vom SE-Agenten getroffen wird).

Eine gute SE-Vereinbarung würde auch sicherstellen, dass jede SE-Einzahlung durch den Verkäufer diese Verarbeitung durchläuft und der Kunde immer das Ergebnis dieser bestimmten Verarbeitung erhält und qualifiziert / abzeichnet , nicht ein alternatives Ergebnis, das direkt vom Verkäufer kommt - um dies zu bestätigen Das Verfahren selbst bleibt für jede SE-Einzahlung auf dem neuesten Stand und wirksam.

Andernfalls ist die Fähigkeit, die "SE-Abhebungen" zu einem späteren Zeitpunkt (falls erforderlich) zu reproduzieren, fraglich, was praktisch die gesamte SE-Geschichte ungültig macht.


Merci Dan für diese Antwort. Ich stimme (den meisten) Ihrer Aussagen zu, aber es scheint, dass Sie meine "Anmerkung 1" nicht berücksichtigt haben. Ihre Antwort hier scheint sich auf eine (neue) Frage zu beziehen wie "Welche typischen Überprüfungsstufen werden in SE-Vereinbarungen angeboten (und wie wird eine ausgewählt)?". Zu
Ihrer Information

Ich habe Anmerkung 1 gesehen, aber wenn ich sie anwende, sehe ich nicht, wie die Frage Sinn macht :) Wenn es keine Verarbeitungspipeline gibt, wofür wird dann das Devops-Toolset verwendet? Außer vielleicht für das CRM / Speicher (meine Antwort berührt das auch).
Dan Cornilescu

Sie sind sich nicht sicher, was Sie mit diesem CRM in Ihrem Kommentar meinen (können Sie es erneut versuchen?). Stellen Sie sich außerdem vor, der (arme) SE-Agent akzeptiert Einzahlungen im Format von CDs, die physisch an sein Büro geliefert werden (z. B. 1 bis 3 CDs pro Jahr für "einen" Softwareanbieter, und es gibt einige Dutzend solcher Softwareanbieter). . Wenn der SE-Agent Sie beauftragen würde, diesen veralteten Ansatz durch die Einführung von DevOps-konformen Verfahren zu modernisieren, was würden Sie dann empfehlen?
Pierre.Vriens

@ Pierre.Vriens Sorry, vermischte Akronyme. Nicht CRM. Ich meinte Artefakt-Repository / Speicher.
Dan Cornilescu

@ Pierre.Vriens Wenn das Empfangen von CDs in der Vereinbarung festgelegt ist, ist das Speichern und Abrufen von CDs (oder CD-Images) so ziemlich alles, was dazu gehört. Wenn es mehr als das ist, aber keine Verarbeitung beinhaltet - ich bin mir nicht sicher, was das ist. Wenn die Verarbeitung auf dem Tisch bleibt, kann viel getan werden. Im Extremfall können Sie alle drei Teile der SE-Vereinbarung in die sw-Lieferpipeline einbeziehen, die sw produziert, das auch bei einem katastrophalen Anbieterereignis garantiert wartbar bleibt.
Dan Cornilescu
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.