Michael
Michael DevOps, Cloud, Performance skills, High math skills

DevOps to NoOps

DevOps to NoOps

"DevOps to NoOps – Bei der digitalen Transformation geht es nicht nur um Technologie, 80% sind Kultur - eine CTO-Perspektive" Das ist richtig, wenn wir uns des gesamten IT-Materials bewusst sind, ist dies klar - Technologie ist nicht alles. Natürlich ist es sehr wichtig, aber um moderne Lösungen für anspruchsvolle Kunden zu entwickeln, sollten wir uns aller Aspekte der Softwarebereitstellung und -produktion bewusst sein und dabei auf unsere Teamkultur und unser mentales Bewusstsein achten. Lassen Sie uns einen Blick auf den Produktionsprozess, historische Aspekte und Gründe der digitalen Transformation werfen.

Digitale Transformation

"Die digitale Transformation kann sich auf alles beziehen, von der IT-Modernisierung (z. B. Cloud Computing) über die digitale Optimierung bis hin zur Erfindung neuer digitaler Geschäftsmodelle. Der Begriff wird in Organisationen des öffentlichen Sektors häufig verwendet, um sich auf bescheidene Initiativen wie das Setzen von Diensten zu beziehen Online- oder Legacy-Modernisierung. Daher ist der Begriff eher „Digitalisierung“ als „digitale Geschäftstransformation“. Dies ist ein Link: Gartner-Definition. Mit anderen Worten, die digitale Transformation ist nichts anderes als die Entwicklung der IT, um neue Geschäftsmöglichkeiten zu erschließen oder zu entdecken von der realen Welt in die digitale Welt. Was bedeutet es für die Erstellung von Software im Allgemeinen?

Bei der digitalen Transformation gibt es drei Schlüsselfaktoren:

digital transformation
  • Prozesse - Automatisierte Softwareentwicklung und -wartung durch kontinuierliche Integration mit Continuous Delivery - Mustern

  • Tools - moderne Softwarekomponenten und -techniken wie Pipelines, Terraform und andere DevOps-Tools

  • Menschen - der wichtigste Faktor, den wir zitiert haben, ist menschlicher Ansatz, Kultur und Erfahrung

NoOps

Alles hat eigene Zyklen wie Jahreszeiten, Mondfinsternis usw. Vor einigen Jahren hatten wir keine DevOps-Ingenieure - warum? Da wir sie einfach nicht brauchten, war unsere Software einfacher, wir haben keinen Link verwendet: microservices oder Micro-Frontends - Methoden. Unser Entwicklungsprozess war aufgrund der monolithischen Architektur sehr einfach. Natürlich hatten wir auch einige Probleme mit monolithischen Anwendungen, aber der Maßstab war im Vergleich zur aktuellen Situation, in der unsere Softwarearchitektur mit Hunderten von Technologien, Mustern und Komponenten viel ausgefeilter und fortschrittlicher ist, sehr gering. Aus diesem Grund waren wir von der Technologie gezwungen, einen neuen Beruf namens DevOps zu schaffen, der sich der Verwaltung der Prozessautomatisierung für unsere moderne Architektur widmet.

Automation

Für einige Teams und Unternehmen ist die Automatisierung wie ein Stechpalmengral. Sie versuchen, Prozesse zu automatisieren, aber ohne die geringste menschliche Aktivität zu eliminieren, können alle Anstrengungen zunichte gemacht werden. Um definitiv NoOps zu sein, möchten wir wie unser Held aus dem Bild unten sein.

automation


Um dieses Ziel zu erreichen, sollten wir uns auf mindestens drei sehr wichtige Softwaretechniken konzentrieren:

  • CI / CD. Eine manuelle Aktivität in unserem Entwicklungsprozess ist eine schlechte Praxis, da unser Team leicht auf diese manuelle Aktion warten kann, um sie nur manuell auszuführen. Alle Aktivitäten, insbesondere Integrationstests, E2E-Tests und Sicherheitsüberprüfungen, sollten immer Teil des automatisierten Pipeline-Prozesses sein.

  • SaaS. Natürlich gibt es viele erfolgreiche On-Premise-Bereitstellungen, aber in den meisten Fällen kann die Verwendung von Software as a Service und Cloud-Umgebungen die Markteinführungszeit, Qualität und Sicherheit unserer Softwarelösung erheblich verlängern.

  • Infrastruktur als Code. Damit wir und unsere Kunden keine Zeit damit verschwenden, unsere Systemarchitektur manuell vorzubereiten und neu zu erstellen.

Everything as Code

Everything as code is a modern approach to build every component around the system from source code. keep and build it directly form source code. To not left any space for manual activities and use great mechanisms like version control systems.

Es gibt mehrere Bereiche zu überprüfen:

  • Automatisierung. Der Prozess kann einfach im Quellcode gespeichert und versioniert werden.

  • Infrastruktur. Um manuelle Aktivitäten in unserer Infrastruktur zu vermeiden, können wir alles mit Link beschreiben: Terraform und Ansible.

  • Tests. Mit modernen E2E-Frameworks wie Cypress oder Testcontainer können wir alle Prozesse in den CI/CD-Fluss einbinden, versionieren, ändern und anpassen unsere Testfälle.

  • Dokumentation. Alles ist besser als die Word-Dokumentation, aber heute müssen wir viele großartige Tools wie Markdown Asciidoc und Mechanismen wie den Link GitLab Pages erstellen , speichern, veröffentlichen und pflegen Sie Dokumentationen für unsere Projekte.

gitlab pages
Figure 1. GitLab Pages Flow


Testing

Die Testmethodik ist ziemlich klar, insbesondere für Unit-Tests und Integrationstests. Aber manchmal können wir überladene E2E-Testimplementierungen beobachten. Insbesondere für Legacy-Systeme großer Unternehmen versuchen ihre Teams, alles mit E2E im nächtlichen Erstellungsprozess zu testen, wobei sie die grundlegende E2E-Regel vergessen:

tests pyramid

E2E-Tests können also nicht überladen werden, aber wie geht das?

  • Verwenden Sie keine nächtlichen Builds mehr. Wir sollten alles so schnell wie möglich halten. Warten Sie nicht auf lange nächtliche E2E-Prozesse, da es äußerst schwierig ist zu untersuchen, wer den Build beschädigt hat. Es ist eine enorme Zeitverschwendung, dies zu tun.

  • 100% Stabilität gewährleisten. Wenn E2E-Tests aufgrund einiger Komponenteninstabilitäten oder Testfehler nicht stabil sind, werden sie nicht automatisiert. Dies führt lediglich zu manuellen Aktivitäten, die diesen Prozess analysieren und aufrechterhalten.

  • Machen Sie einen Kompromiss. Wenn Ihre Software einige ältere oder instabile Komponenten enthält, die Ihre Testfälle regelmäßig nicht bestehen, ist es besser, sie separat auszuschließen, zu verspotten und zu testen, als alle modernen und agilen Komponenten für ihren Status verantwortlich zu machen.

Zusammenfassung

NoOps ist eine Art Zurück zur Route und der nächste Schritt für den Automatisierungsansatz. NoOps ist eine ideale Situation, in der alle Entwicklungsprozesse wartungsfrei sind. Um dieses Ziel zu erreichen, benötigen wir jedoch erfahrene DevOps und ein bewusstes Entwicklungsteam. Beginnen wir Ihre NoOps-Reise und sündigen Sie bitte nicht mehr!

good luck