Die aktuelle Organisation des von Ihnen beschriebenen Codes und der Konfiguration wird durch die beteiligten technischen Lösungen strukturiert. Dies ist ein schlechtes Design, das viel Aufwand bei unseren Wartungsaktivitäten und viele Fallen auf unserem Weg verursacht. Stattdessen sollte diese Organisation nach den von uns bereitgestellten Artefakten strukturiert sein .
Der Grund dafür ist, dass wir Artefakte ( z. B. ein Docker-Image oder ein Softwarepaket) als Objekte der folgenden Verben betrachten möchten :
- bauen
- Prüfung
- bereitstellen
um einen minimalen Satz automatisierter Aufgaben zu berücksichtigen, die wir ausführen möchten. Wenn Sie etwas an der Implementierung des Testverbs ändern möchten, können Sie den Ordner, der diesem Artefakt entspricht, im entsprechenden Repository aufrufen und dann die Jenkins-spezifischen Automatisierungselemente ermitteln, die aktualisiert werden müssen. Wenn die Automatisierungsrezepte nach technischen Lösungen strukturiert sind, müssen wir aus heiterem Himmel herausfinden, dass Jenkins an den Testverfahren beteiligt ist, und dort die artefaktbezogenen Automatisierungselemente finden. In komplexen Situationen macht die Organisation um technische Lösungen Aktualisierungen sehr schwierig, da wir a priori alle technischen Lösungen kennen müssen, die an einem Service beteiligt sind, um sie entsprechend zu aktualisieren.
Beispielsweise kann ein Repository, das den Code für eine Website und einen Mikrodienst "a" enthält, die folgenden Unterverzeichnisse für Vorgänge enthalten:
./ops/website
./ops/micro-service-a
die jeweils drei Skripte genannt build, testund deploy. Nachdem die Organisation der Automatisierungselemente irgendwie geklärt wurde, wenden wir uns der Konfiguration zu.
Die Hauptbedingungen und -anforderungen für die Konfigurationsorganisation werden durch das deployVerb festgelegt, wenn es auf ein serviceähnliches Artefakt angewendet wird. Das deployVerb sollte folgende Parameter haben:
- die Version des zu implementierenden Artefakts,
- das Bereitstellungsziel des Artefakts, das die konkrete Umgebung beschreibt, in der das bereitgestellte Artefakt ausgeführt wird ( z. B. ein Cluster und Endpunkte, mit denen es kommunizieren soll)
- die Anmeldeinformationen, mit denen eine Verbindung zu anderen Endpunkten ( z. B. Datenbanken) hergestellt werden soll
- die Laufzeitkonfiguration von (wie lange Cache-Einträge leben sollen, etc.)
Aus betrieblicher Sicht entspricht diese Aufschlüsselung der Parametrisierung den natürlichen Freiheitsgraden des Bereitstellungsproblems - abgesehen von den Anmeldeinformationen, die mit der Laufzeitkonfiguration gebündelt werden könnten. Es ist jedoch besser, sie zu trennen, um eine unachtsame Verbreitung zu vermeiden.