Ich erkenne, dass mit NiFi, wie ihr Dokument es definiert, "kontinuierliche Verbesserung in der Produktion auftritt" . Dies bietet sich nicht als traditionelles Entwicklungswerkzeug an. Für das Projekt, an dem ich gerade arbeite, wurde jedoch entschieden, dass dies das Werkzeug ist, das wir verwenden werden. Daher möchte ich lieber nicht über die Vorteile sprechen, da mir klar ist, dass es einige Probleme geben wird.
Wenn ich beispielsweise Änderungen in eine bestehende Umgebung (vom Staging in die Produktion) verschiebe und Live-Änderungen am Ziel vorgenommen haben, werden sie überschrieben. Ich habe also Fragen zur Organisation des Entwicklungszyklus.
Als der ursprüngliche Autor des von Ihnen zitierten Artikels und ein Mitglied des Apache NiFi PMC möchte ich zunächst sagen, dass Sie große Fragen stellen, und ich kann schätzen, woher Sie kommen. Wir sollten das Einführungsdokument wahrscheinlich verbessern, um die von Ihnen aufgeworfenen Bedenken besser widerzuspiegeln.
Sie haben recht, dass der aktuelle Ansatz darin besteht, Vorlagen für die Flüsse zu erstellen, und Sie können diese dann an die Versionskontrolle übergeben. Es ist auch der Fall, dass Benutzer die Bereitstellung dieser Vorlagen mithilfe von Skripten automatisieren, die mit der REST-API von NiFi interagieren. Aber wir können und sollten weit mehr tun, als den Datenfluss-Management-Job einfacher zu machen, unabhängig davon, ob Sie ein Entwickler sind, der genau beschreibt, was eingesetzt wird, oder ob Sie eine operationsorientierte Person sind, die diese Teile selbst zusammenstellen muss / p>
Elemente von 1 und 2 werden in der kommenden Version 1.0 enthalten sein und Punkt 3 wird in der kommenden Version vollständig behandelt. In der Zwischenzeit denke ich, dass es für den Multi-Developer-Fall sinnvoll ist, ihre eigene lokale Instanz als einen Ort zu betrachten, an dem sie ihren Flow "Unit-Testing" testen und dann eine gemeinsame Staging- oder Produktionsumgebung verwenden können. Die wichtigste Sache, die man beachten sollte, ist, dass es für viele Strömungen und mit dem NiFi-Ansatz in Ordnung ist, mehrere Instanzen einer gegebenen Flussvorlage zu haben, die jeweils mit der Live-Zufuhr von Daten versorgt werden. Die Ergebnisse / Ausgaben dieses Flusses können so verdrahtet werden, dass sie tatsächlich an einen anderen Ort geliefert oder einfach geerdet werden. Auf diese Weise ähnelt es dem mentalen Modell der Verzweigung in der Quellcodeverwaltung wie Git. Sie können wählen, welche Sie "Produktion" gegenüber dem Fluss in der Grafik betrachten, ist einfach eine laufende Funktion Zweig, wenn Sie so wollen. Für Menschen, die aus dem traditionelleren Ansatz kommen, ist dies nicht offensichtlich und wir müssen mehr tun, um dies zu beschreiben und zu demonstrieren. Wir sollten jedoch auch traditionellere Ansätze unterstützen, und das ist es, was einige der Feature-Vorschläge, die ich verlinkt habe, ermöglichen.
[1] Ссылка
[2] Ссылка
[3] Ссылка
[4] Ссылка
Tags und Links design-patterns deployment lifecycle apache-nifi