Die Software-Lieferantenfalle

Wenn Sie schon länger in der Softwareentwicklung tätig sind, sind Sie wahrscheinlich daran gewöhnt, auf eine bestimmte Art und Weise zu arbeiten, und waren schon einmal in der Situation, dass ein neues Tool Sie dazu zwingt, Ihre Arbeitsweise zu ändern. Manche denken vielleicht auch, dass die Verwendung von Tool X automatisch bedeutet, dass man den Prozess Y befolgt. Zum Beispiel: "Wir verwenden ArgoCD, also machen wir GitOps, richtig? Verstehen Sie mich nicht falsch, die Anpassung an ein neues Tool kann zu besseren Praktiken führen, aber sie wird zum Problem, wenn sie die zugrunde liegenden Probleme verschleiert. Dies sind einige gängige Beispiele, auf die Sie wahrscheinlich stoßen werden :

Das Wiederaufleben der Filialen

Damals, als Git zum Standard wurde (Anmerkung am Rande: Ja, ich bin alt genug, um mit Subversion gearbeitet zu haben), wurden viele Verzweigungsstrategien wie Git Flow, Github Flow und umgebungsbasierte Verzweigungen und Workflows erdacht, um instabilen, in der Entwicklung befindlichen Code von veröffentlichbarem Code zu trennen. Irgendwann begannen die meisten Teams mit Continuous Integration und Continuous Delivery, und es schien, dass man sich darauf einigte, dass eine stammbasierte Entwicklung mit kurzlebigen Zweigen der beste Weg für CI/CD ist. Dies verkürzt die Feedbackschleifen, verbessert die Zusammenarbeit und ist der schnellste Weg, um Probleme mit der Softwarequalität ans Licht zu bringen. In letzter Zeit wird jedoch wieder vermehrt die Anzahl der Zweige erhöht, um verschiedenen Umgebungen gerecht zu werden, oft im Zusammenhang mit GitOps, Infrastruktur und containerisierten Anwendungen.

Betrachten Sie die folgende Verzweigungsstrategie:

Dieser Arbeitsablauf zeigt, wie ein Entwickler eine Verzweigung von main erstellt, sie in einer Entwicklungsumgebung bereitstellt und dort alle möglichen automatisierten Tests und Prüfungen durchführt. Wenn dies alles erfolgreich war, kann die Verzweigung wieder mit main zusammengeführt werden, wo die Anwendung in einer Testumgebung bereitgestellt wird, und wenn sie fertig ist (oder automatisch), wird sie in die Produktionsumgebung übertragen. Beachten Sie, dass Sie bei jeder Änderung der Hauptanwendung die Hauptanwendung wieder in alle Zweige einbinden und somit den Schritt "Zum Testen bereitstellen" auslassen können, da Integrationstests auch gegen Zweige laufen können.

Dies ist der einfachste Ansatz für die Verzweigung, den man wählen kann. Wenn Sie sicherstellen, dass alle Verzweigungen kurzlebig sind (idealerweise innerhalb eines Tages zusammengeführt) und alle Tests automatisiert sind, sollten Sie die kürzesten Feedbackschleifen und das geringste Risiko haben.

Schauen wir uns nun denselben Arbeitsablauf an, wenn alle Umgebungen an Zweige gebunden sind:

Wie Sie sehen können, ist dies viel komplexer als die vorherige und es könnte sogar noch komplexer werden, wenn Entwickler ihre eigenen Zweige (kurzlebig oder nicht) für neue Funktionen zusätzlich zum Entwicklungszweig erstellen. Abgesehen davon, dass mehr Komplexität mehr Möglichkeiten bietet, dass Dinge schief gehen, verzögert dies auch die Feedbackschleifen, da Zusammenführung von zwischen Umgebungen ist häufig manuell durchgeführt. Darüber hinaus, ist es Es ist jetzt einfach, Änderungen in den Entwicklungs- oder Testumgebungen vorzunehmen, bevor man sich an die Produktion wagt, da gibt es keine einzige, kohärente Pipeline gibt, die eine Änderung in allen Umgebungen.Unter zu verdeutlichen.
,

als jede Zusammenführung zu main
automatisch und
sofort
in die
Produktion geht, nachdem sie alle Qualitätsprüfungen bestanden hat,
ist es
jetzt einfacher zu verschieben
indem man die Zusammenführung einfach verzögert
(absichtlich oder nicht)

von Dev zu Test oder von Test zu Prod

.

Diese
führt zu einer verzögerten Rückmeldung und
letztlich
höheren
Risiko
pro Freigabe
.

Wenn diese Informationen Sie überzeugt haben, Ihre Entscheidung zu überdenken, going Die Rückkehr zum Trunk-basierten Ansatz mag leichter gesagt als getan sein, da Tools, die den umgebungsbasierten Ansatz unterstützen, in der Regel eng an diesen gekoppelt sind. Es gibt jedoch oft Möglichkeiten, dies zu umgehen und dennoch Ihre bevorzugten Tools zu verwenden. Sie könnten z.B. Tags anstelle von Zweigen verwenden und automatisch einen bestimmten Commit auf main taggen, wenn die Pipeline ein bestimmtes Stadium durchläuft. Wenn die Pipeline zum Beispiel die Phase "test" durchläuft, könnten Sie diesen Commit mit "test" markieren. ". Ein anderer Ansatz wäre die Verwendung von umgebungsspezifischen Konfigurationsdateien und Templates, um zwischen verschiedenen Umgebungen zu unterscheiden, und das alles innerhalb derselben Verzweigung.

Drifterkennung und automatischer Abgleich

Als Hauptvorteil von GitOps und den Tools, die sich selbst als GitOps-Tools vermarkten, wird oft die Möglichkeit genannt, eine Abweichung zwischen einer Live-Umgebung und der Quelle der Wahrheit in Git zu erkennen und diese Abweichung dann automatisch auszugleichen. Hier ist meine Sorge: Wenn Git die Quelle der Wahrheit ist, bedeutet dies, dass alle Änderungen aus einem Git-Commit stammen und CI/CD durchlaufen sollten. Das bedeutet auch, dass Ihre Umgebungen unveränderlich sein sollten, und zwar nicht nur durch das, was Sie für die Bereitstellung verwenden. Grundsätzlich sollten Ingenieure nicht in der Lage sein, Ihre Umgebungen manuell zu ändern, insbesondere in der Produktion. Die Tatsache, dass es überhaupt eine Drift gibt, zeigt, dass Sie ein Problem haben, das nicht durch den Einsatz eines GitOps-Tools gelöst werden kann - ein solches Tool wird das Problem nur durch einen automatischen Abgleich verbergen.

Es könnte z.B. sein, dass eine manuelle Änderung vorgenommen wurde, um ein Problem schnell zu beheben, ohne dass dies anschließend "als Code" dokumentiert wurde. Oder Sie stellen fest, dass im Hintergrund ein Agent läuft, der Ressourcen zur Laufzeit verändert.

Anstelle eines automatischen Abgleichs schlage ich vor, dass Sie nur bei einer Abweichung alarmiert werden. Auf diese Weise können Sie Untersuchen Sie nicht nur, welche Ressource abgewandert ist, sondern auch deren Ursache. Nach der UntersuchungBeheben Sie die Abweichung, indem Sie die Ursache des Problems beheben. Das kann so einfach sein als das Verbot manueller Änderungen oder, falls dies nicht möglich ist, die Implementierung (oder Erzwingung) eines Prozesses, bei dem diese manuellen Änderungen immer als Code zu Git hinzugefügt werden anschließend.

Low-Code und der Verlust der technischen Praktiken

Low-Code- und No-Code-Plattformen sind auf dem Vormarsch, und es ist einfacher denn je geworden für jeder Anwendungen zu erstellen. Was oft vergessen wird, ist die Tatsache, dass, obwohl es ist es ist einfach, diese Softwareanwendungen zu entwickeln und bereitzustellen, es ist immer noch Software. Unter den Prozessdiagrammen und Benutzeroberflächen befindet sich immer noch Code. Deshalb, um eine eine hochwertige Anwendung zu erstellen, besonders wenn es ist nicht nur eine einmalige Anwendung ist, müssen Sie immer noch die besten technischen Verfahren anwenden. Sie müssen immer noch müssen über die Architektur nachdenken, automatisierte Tests und andere Qualitätstests in einer CI/CD-Pipeline implementieren, Sie müssen überwachen überwachen und über die Beobachtbarkeit nachdenken, und Sie müssen sicherstellen, dass dass es wartbar und erweiterbar ist (da Softwaresysteme haben die Tendenz ändern). Einige dieser Plattformen behaupten zwar, dass sie sich um diese Dinge für Sie kümmern, aber im Endeffekt Sie sind "nur" Plattformen. Sie nicht erstellen die eigentliche Anwendung für Sienoch pflegen seine Funktionalität. Das Ergebnis ist, ist es oft zu leicht vergessen, dass es einer technischen Denkweise bedarf, um spätere Qualitätsprobleme zu vermeiden.

Fazit

Der gemeinsame Nenner dieser Probleme ist folgender: Wenn ein Tool zu sehr auf eine bestimmte Arbeitsweise fixiert ist und diesen Prozess vereinfacht, können auch Probleme mit Ihrer Anwendung leicht ausgeblendet werden. Glücklicherweise ist auch die Lösung einfach: Verwenden Sie ein Tool oder eine bestimmte Funktion eines Tools nicht nur, weil Sie es können, sondern überlegen Sie auch, warum Sie es verwenden. Stellen Sie Fragenu Fragen wie:

• Warum lasse ich zu, dass dieses Tool automatisch eine Abweichung ausgleicht, und will ich nicht wissen, warum die Abweichung aufgetreten ist?
• Warum verwende ich diese Low-Code-Plattform? Weil ich schnell eine einmalige Anwendung erstellen möchte oder weil ich denke, dass ich keine technische Arbeit leisten muss?
• Und brauche ich wirklich so viele Zweige?

Wenn Sie sich diese Fragen stellen, werden Sie zumindest verstehen, warum bestimmte Entscheidungen getroffen werden, und hoffentlich auch besser geeignete Alternativen ins Auge fassen.

Dieser Blog ist Teil unserer Serie "
Ganzheitliche Horizonte
". Sehen Sie sich den vorherigen Eintrag an - "
Der Wandel jenseits des Hypes: Der Übergang von eitlen Metriken zu authentischen Geschäftszielen
" von Kateryna Zhuzha. Oder lesen Sie weiter zum nächsten Artikel - "
Die drei Formen von CI / CD
" von Dave van Stein.