DevOps LEGO: Wie wir eine Pipeline auf Würfeln angelegt haben

Irgendwie setzen wir den Kunden auf ein Objekt elektronisches Dokumentenmanagementsystem. Und dann zu einem anderen Objekt. Und noch einer. Und am vierten und fünften. Sie wurden so mitgerissen, dass sie 10 verteilte Objekte erreichten. Mächtig passiert ... vor allem, als wir zur Lieferung von Änderungen kamen. Im Rahmen der Lieferung an den Produktionskreislauf für 5 Testsystemszenarien dauerte dies 10 Stunden und 6-7 Mitarbeiter. Diese Kosten zwangen uns, so wenig wie möglich zu liefern. Nach dreijähriger Betriebszeit konnten wir es nicht ertragen und beschlossen, das Projekt mit einer Prise DevOps zu würzen.



Jetzt sind alle Tests in 3 Stunden abgeschlossen und 3 Personen nehmen daran teil: ein Ingenieur und zwei Tester. Verbesserungen werden deutlich in Zahlen ausgedrückt und führen zu einer Verringerung des geliebten TTM. Nach unserer Erfahrung gibt es weit mehr Kunden, denen DevOps helfen kann, als diejenigen, die überhaupt davon wissen. Um DevOps näher an die Menschen heranzuführen, haben wir einen einfachen Konstruktor entwickelt, über den wir in diesem Beitrag ausführlicher sprechen werden.

Jetzt werden wir genauer erzählen. In einem Energieunternehmen in 10 großen Anlagen wird ein technisches Dokumentenmanagementsystem eingesetzt. Ohne DevOps ist es nicht einfach, in Projekten dieser Größenordnung zu arbeiten, da ein großer Teil der manuellen Arbeit die Arbeit erheblich verzögert und auch die Qualität verringert - jede manuelle Arbeit ist mit Fehlern behaftet. Auf der anderen Seite gibt es Projekte, bei denen es sich um eine Installation handelt, aber es ist erforderlich, dass alles automatisch, konstant und fehlerfrei funktioniert - zum Beispiel dieselben Dokumentenverwaltungssysteme in großen monolithischen Organisationen. Andernfalls nimmt jemand die Einstellung manuell vor, vergisst die Bereitstellungsanweisungen - und infolgedessen gehen die Einstellungen auf dem Produkt verloren und alles stürzt ab.

Normalerweise arbeiten wir mit dem Kunden über einen Vertrag zusammen. In diesem Fall weichen unsere Interessen ein wenig voneinander ab. Der Kunde betrachtet das Projekt streng im Rahmen des Budgets und der TK. Es kann schwierig sein, ihm die Vorteile verschiedener DevOps-Praktiken zu erklären, die nicht Teil von TK sind. Und wenn er an schnellen Releases mit Mehrwert für das Unternehmen interessiert ist, am Aufbau einer Automatisierungspipeline?

Leider ist es bei der Arbeit mit vorab genehmigten Werten nicht immer möglich, dieses Interesse zu finden. In unserer Praxis gab es einen Fall, in dem wir die Entwicklung eines skrupellosen und ungenauen Auftragnehmers aufgreifen mussten. Es war ein Horror: Es gibt keine tatsächlichen Quellcodes, die Codebasis desselben Systems auf verschiedenen Installationen ist unterschiedlich, die Dokumentation fehlte teilweise, teilweise von schrecklicher Qualität. Natürlich hatte der Kunde keine Quellcodeverwaltung, Montage, Freigaben usw.

Bisher kennt nicht jeder DevOps, aber es lohnt sich, über seine Vorteile zu sprechen, über echte Ressourceneinsparungen, die Augen leuchten für alle Kunden. Daher gibt es im Laufe der Zeit immer mehr Anfragen, die DevOps betreffen. Um mit Kunden problemlos dieselbe Sprache sprechen zu können, müssen Geschäftsprobleme und DevOps-Praktiken schnell miteinander verbunden werden, um eine geeignete Entwicklungspipeline aufzubauen.

Wir haben also einerseits eine Reihe von Problemen, andererseits gibt es Wissen, Praktiken und DevOps-Tools. Warum nicht die Erfahrung mit allen teilen?

Erstellen Sie einen DevOps-Konstruktor

Agile hat ein eigenes Manifest. ITIL hat eine eigene Methodik. DevOps hat weniger Glück - es hat noch keine Vorlagen und Standards erworben. Obwohl einige versuchen, den Reifegrad von Unternehmen anhand einer Bewertung ihrer Entwicklungs- und Betriebsmethoden zu bestimmen.

Glücklicherweise hat das berüchtigte Unternehmen Gartner im Jahr 2014 die wichtigsten DevOps-Praktiken und die Beziehungen zwischen ihnen gesammelt und analysiert. Auf dieser Grundlage habe ich die Infografik veröffentlicht:



Wir haben es als Grundlage für unseren Konstrukteur genommen . In jedem der vier Bereiche gibt es eine Reihe von Tools - wir haben sie in der Datenbank gesammelt, die beliebtesten, identifizierten Integrationspunkte und geeignete Optimierungsmechanismen identifiziert. Insgesamt stellten sich 36 Praktiken und 115 Tools heraus, von denen ein Viertel offene oder freie Software ist. Als nächstes werden wir darüber sprechen, was wir in den einzelnen Bereichen getan haben und wie es beispielsweise im Projekt implementiert wurde, um einen technischen Workflow zu erstellen, von dem aus wir den Beitrag gestartet haben.

Die Prozesse

In dem berüchtigten EDMS-Projekt wurde das Managementsystem für technische Dokumentation in jeder der 10 Einrichtungen nach demselben Schema eingesetzt. Die Installation umfasst 4 Server: einen Datenbankserver, einen Anwendungsserver, Volltextindizierung und Inhaltsverwaltung. Bei der Installation arbeiten sie innerhalb eines einzelnen Knotens und befinden sich im Rechenzentrum der Einrichtungen. Alle Objekte unterscheiden sich geringfügig in der Infrastruktur, dies beeinträchtigt jedoch nicht die globale Interaktion.

Gemäß den DevOps-Praktiken haben wir zuerst die Infrastrukturen lokal automatisiert, dann die Lieferung an die Testschaltung und dann an die Produktivität des Kunden gebracht. Jeder Prozess verlief Schritt für Schritt. Die Umgebungseinstellungen werden im Quellcodesystem festgelegt, wobei berücksichtigt wird, welche Verteilung für automatische Aktualisierungen erfasst wird. Bei Änderungen in der Konfiguration müssen die Ingenieure lediglich die entsprechenden Änderungen am Versionskontrollsystem vornehmen - und das automatische Update wird dann problemlos durchgeführt.

Dank dieses Ansatzes wurde der Testprozess erheblich vereinfacht. Zuvor gab es Tester im Projekt, die nur die Stände manuell aktualisierten. Jetzt kommen sie einfach und sehen, dass alles funktioniert hat und beschäftigen sich mit nützlicheren Dingen. Jedes Update wird automatisch getestet - von der Oberflächenebene bis zur Automatisierung des Geschäftsszenarios. Die Ergebnisse werden in TestRail als separate Berichte dargestellt.

Kultur

Kontinuierliches Experimentieren lässt sich am besten durch das Testdesign erklären. Das Testen eines noch nicht existierenden Systems ist kreative Arbeit. Wenn Sie einen Testplan schreiben, müssen Sie verstehen, wie Sie richtig testen und welche Zweige durchlaufen werden müssen. Finden Sie auch ein Gleichgewicht zwischen Zeit und Budget, um die optimale Anzahl von Schecks zu ermitteln. Es ist wichtig, genau die erforderlichen Tests auszuwählen, zu berücksichtigen, wie der Benutzer mit dem System interagiert, die Umgebung und mögliche externe Faktoren zu berücksichtigen. Sie können nicht ohne kontinuierliches Experimentieren auskommen.

Nun zur Kultur der Interaktion. Früher gab es zwei Kriegsparteien - Ingenieure und Entwickler. Die Entwickler sagten: "Es ist uns egal, wie es anfängt. Sie sind Ingenieure, Sie sind schlau und sorgen dafür, dass es ohne Unterbrechung funktioniert . “ Die Ingenieure antworteten: „Sie Entwickler sind zu rücksichtslos. Lassen Sie uns vorsichtiger sein, und wir werden Ihre Veröffentlichungen seltener veröffentlichen. Denn jedes Mal, wenn Sie uns einen löchrigen Code geben und nicht wissen, wie wir interagieren, ist nicht klar . “ Dies ist ein kulturelles Interaktionsproblem, das aus Sicht von DevOps anders aufgebaut ist. Hier haben Sie sowohl Ingenieure als auch Entwickler, die Teil eines einzigen Teams sind, das sich ständig ändernde, aber gleichzeitig zuverlässige Software zum Ziel hat.

Auf der Skala eines Teams sollen sich Spezialisten gegenseitig helfen. Wie war es vorher? Zum Beispiel wurde eine Art dicke Bereitstellungsanweisung vorbereitet, Seiten bei 50. Der Ingenieur las sie, verstand etwas nicht, fluchte und bat den Entwickler, um drei Uhr morgens einen Kommentar abzugeben. Der Entwickler kommentierte und fluchte auch - am Ende war niemand glücklich. Außerdem gab es natürlich einige Fehler, da Sie sich nicht an alles in der Anleitung erinnern werden. Und jetzt schreibt der Ingenieur zusammen mit dem Entwickler ein Skript für die automatisierte Bereitstellung der Anwendungssoftware-Infrastruktur. Und sie sprechen fast in derselben Sprache miteinander.

Leute

Die Größe des Teams wird durch den Umfang der Aktualisierung bestimmt. Das Team wird während der Bildung des Angebots rekrutiert, es schließt diejenigen ein, die vom allgemeinen Projektteam wünschen. Anschließend wird ein Aktualisierungsplan mit der Verantwortung für jede Phase erstellt, während das Team die Ausführung ausführt. Alle Teammitglieder sind austauschbar. Als Teil des Teams haben wir auch einen Sicherheitsentwickler, der jedoch fast nie eine Verbindung herstellen muss.

Technologie

Im Schema für Technologie werden einige Punkte hervorgehoben, aber darunter befinden sich eine Reihe von Technologien - mit ihren Beschreibungen können Sie ein ganzes Buch veröffentlichen. Also werden wir die interessantesten hervorheben.

Infrastruktur als Code

Nun werden Sie wahrscheinlich niemanden mit diesem Konzept überraschen, aber bevor die Beschreibung der Infrastrukturen zu wünschen übrig ließ. Die Ingenieure sahen sich die Anweisungen mit Entsetzen an , die Testumgebungen waren einzigartig, sie wurden gepflegt und geschätzt, Staubpartikel wurden von ihnen weggeblasen.

Jetzt hat niemand Angst zu experimentieren. Es gibt grundlegende Images von virtuellen Maschinen, es gibt vorgefertigte Szenarien für die Bereitstellung von Umgebungen. Alle Vorlagen und Skripte werden im Versionskontrollsystem gespeichert und schnell aktualisiert. Zuvor war eine Konfigurationslücke aufgetreten, als ein Paket an einen Stand geliefert werden musste. Jetzt müssen Sie nur noch eine Zeile in den Quellcode einfügen.

Neben Infrastrukturszenarien und Pipelines wird für die Dokumentation auch der Ansatz Dokumentation als Code verwendet. Dank dessen ist es einfach, neue Personen mit dem Projekt zu verbinden, sie über die im Testplan beschriebenen Funktionen in das System einzuführen und Testfälle wiederzuverwenden.

Kontinuierliche Lieferung und Überwachung

In unserem letzten Artikel über DevOps haben wir darüber gesprochen, wie wir Tools ausgewählt haben, um eine kontinuierliche Bereitstellung und Überwachung zu implementieren. Oft ist es nicht erforderlich, etwas neu zu schreiben - es reicht aus, zuvor geschriebene Skripte zu verwenden, die Integration zwischen den Komponenten korrekt aufzubauen und eine gemeinsame Verwaltungskonsole zu erstellen. Alle Prozesse können mit einer einzigen Schaltfläche oder einem einzigen Zeitplan gestartet werden.

Es gibt verschiedene Konzepte in Englisch, Continuous Delivery und Continuous Deployment. Beide können als "kontinuierliche Lieferung" übersetzt werden, aber tatsächlich gibt es einen kleinen Unterschied zwischen ihnen. In unserem Projekt für das technische Dokumentenmanagement eines verteilten Energieunternehmens wird die Lieferung eher verwendet, wenn die Installation für den Verkauf auf Befehl ausgeführt wird. In der Bereitstellung erfolgt die Installation automatisch. Die kontinuierliche Bereitstellung in diesem Projekt ist im Allgemeinen ein zentraler Bestandteil von DevOps geworden .

Wenn Sie bestimmte Parameter erfassen, können Sie im Allgemeinen klar verstehen, warum DevOps-Praktiken nützlich sind. Und dies der Führung zu vermitteln, die Zahlen liebt. Die Gesamtzahl der Starts, die Ausführungszeit der Phasen des Skripts, der Prozentsatz der erfolgreichen Starts - all dies wirkt sich direkt auf die bevorzugte Markteinführungszeit aller aus, dh auf die Zeit vom Festschreiben an das Versionskontrollsystem bis zur Veröffentlichung der Version in einer produktiven Umgebung. Mit der Einführung der erforderlichen Tools erhalten Ingenieure wertvolle Indikatoren per E-Mail, die der Projektmanager auf einem Dashboard sieht. So können Sie die Vorteile neuer Tools sofort erkennen. Und Sie können sie mit dem DevOps-Konstruktor in Ihrer Infrastruktur ausprobieren.

Wer braucht unseren DevOps-Konstruktor ?

Wir werden nicht schummeln: Für den Anfang wurde er für uns nützlich. Wie bereits erwähnt, müssen Sie mit dem Kunden dieselbe Sprache sprechen, und mithilfe des DevOps-Konstruktors können wir schnell die Grundlage für ein solches Gespräch ermitteln. Geschäftsleute können sich selbst bewerten, was sie brauchen, und sich so schneller entwickeln. Wir haben versucht, den Konstruktor so detailliert wie möglich zu gestalten, und eine Reihe von Beschreibungen hinzugefügt, damit jeder Benutzer versteht, was er wählt.

Das Format des Designers ermöglicht es Ihnen, die vorhandenen Erfahrungen des Unternehmens in Bezug auf Bauprozesse und Automatisierung zu berücksichtigen. Sie müssen nicht alles aufschlüsseln und neu erstellen, wenn Sie nur Lösungen auswählen können, die sich normal in vorhandene Prozesse integrieren lassen und die Lücken einfach schließen können.

Vielleicht hat sich Ihre Entwicklung bereits auf ein höheres Niveau bewegt und unser Tool scheint zu "Kapitän" zu sein. Aber wir finden es nützlich für uns selbst und hoffen, dass es einigen Lesern nützlich ist. Wir erinnern Sie an den Link zum Konstruktor - wenn überhaupt, erhalten Sie die Schaltung sofort nach Eingabe der Quelldaten. Wir werden für das Feedback und die Ergänzungen dankbar sein.