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

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 (Artefakteim 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ürToolchain-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.

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:

• .NET-Entwicklung

  • GitHub oder BitBucket zur Quellcodeverwaltung
  • AppVeyor , TeamCity oder Jenkins für die Build- und Testelemente der Pipeline.
  • Ansible , Puppet oder Chef für die Konfigurationsverwaltungselemente der Pipeline.
  • ProGet für die Paketverwaltungselemente der Pipeline
  • Octopus Deploy für die Bereitstellungsaspekte der Pipeline

• Java-Entwicklung und teilweise Open Source-Plattformen

  • CircleCI , TravisCI , TeamCity oder Jenkins für die Build- und Testelemente der Pipeline.
  • Ansible , Puppet oder Chef für die Konfigurationsverwaltungselemente der Pipeline.
  • JFrog Artifactory oder Sonartype Nexus für die Paketverwaltungselemente der Pipeline
  • Capistrano für die Bereitstellungsaspekte der Pipeline

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.

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.