Chaos bewältigen: Mit Hilfe einer technologischen Landkarte Ordnung schaffen

Bild: Unsplash

Hallo zusammen! Wir sind Automatisierungsingenieure des Unternehmens Positive Technologien und wir unterstützen die Entwicklung der Produkte des Unternehmens: Wir unterstützen die gesamte Assembly-Pipeline von der Übergabe einer Codezeile durch Entwickler bis zur Veröffentlichung fertiger Produkte und Lizenzen auf Update-Servern. Informell werden wir DevOps-Ingenieure genannt. In diesem Artikel wollen wir über die technologischen Stufen des Softwareproduktionsprozesses sprechen, wie wir sie sehen und wie wir sie einordnen.

Aus dem Material erfahren Sie mehr über die Komplexität der Koordinierung der Entwicklung mehrerer Produkte, darüber, was eine technologische Landkarte ist und wie sie zur Rationalisierung und Replikation von Lösungen beiträgt, was die Hauptphasen und -schritte des Entwicklungsprozesses sind und welche Verantwortungsbereiche es gibt zwischen DevOps und Teams in unserem Unternehmen.

Über Chaos und DevOps

Kurz gesagt umfasst das Konzept von DevOps Entwicklungstools und -dienste sowie Methoden und Best Practices für deren Verwendung. Lassen Sie uns das Globale herausgreifen Ziel aus der Umsetzung von DevOps-Ideen in unserem Unternehmen: Dies ist eine konsequente Reduzierung der Produktions- und Wartungskosten von Produkten in quantitativer Hinsicht (Personenstunden oder Maschinenstunden, CPU, RAM, Festplatte usw.). Der einfachste und naheliegendste Weg, die Gesamtentwicklungskosten auf der Ebene des gesamten Unternehmens zu senken, ist Minimierung der Kosten für die Durchführung typischer Serienaufgaben in allen Phasen der Produktion. Aber was sind diese Phasen, wie kann man sie vom allgemeinen Prozess trennen, aus welchen Schritten bestehen sie?

Wenn ein Unternehmen ein Produkt entwickelt, ist alles mehr oder weniger klar: Es gibt normalerweise eine gemeinsame Roadmap und ein gemeinsames Entwicklungsschema. Aber was tun, wenn die Produktpalette erweitert wird und es mehr Produkte gibt? Auf den ersten Blick haben sie ähnliche Prozesse und Fließbänder, und das Spiel „Finde X-Unterschiede“ in Protokollen und Skripten beginnt. Was aber, wenn sich bereits mehr als 5 Projekte in der aktiven Entwicklung befinden und Support für mehrere über mehrere Jahre entwickelte Versionen erforderlich ist? Wollen wir die größtmögliche Anzahl an Lösungen in Produktpipelines wiederverwenden oder sind wir bereit, Geld für eine einzigartige Entwicklung jeder Lösung auszugeben?

Wie findet man ein Gleichgewicht zwischen Einzigartigkeit und seriellen Lösungen?

Diese Fragen tauchen seit 2015 immer häufiger vor uns auf. Die Anzahl der Produkte wuchs und wir versuchten, unsere Automatisierungsabteilung (DevOps), die die Montagelinien dieser Produkte unterstützte, auf ein Minimum zu erweitern. Gleichzeitig wollten wir so viele Lösungen wie möglich zwischen den Produkten reproduzieren. Warum sollte man schließlich bei zehn Produkten das Gleiche auf unterschiedliche Weise tun?

Entwicklungsleiter: „Leute, können wir irgendwie bewerten, was DevOps für Produkte tut?“

Wir: „Wir wissen es nicht, wir haben eine solche Frage nicht gestellt, aber welche Indikatoren sollten berücksichtigt werden?“

Entwicklungsleiter: "Wer weiß! Denken…"

Wie in diesem berühmten Film: „Ich bin in einem Hotel! ..“ – „Äh … Kannst du mir den Weg zeigen?“ Beim Nachdenken kamen wir zu dem Schluss, dass wir zunächst über den Endzustand der Produkte entscheiden müssen; Dies war unser erstes Ziel.

Wie analysiert man also ein Dutzend Produkte mit relativ großen Teams von 10 bis 200 Personen und ermittelt messbare Kennzahlen bei der Replikation von Lösungen?

1:0 zugunsten von Chaos oder DevOps auf den Schulterblättern

Wir begannen mit dem Versuch, IDEF0-Diagramme und verschiedene Geschäftsprozessdiagramme aus der BPwin-Serie anzuwenden. Die Verwirrung begann nach dem fünften Quadrat der nächsten Phase des nächsten Projekts, und diese Quadrate für jedes Projekt können im Schwanz einer langen Python in mehr als 50 Schritten gezeichnet werden. Ich war traurig und wollte den Mond anheulen – das passte überhaupt nicht.

Typische Produktionsaufgaben

Die Modellierung von Produktionsprozessen ist eine sehr komplexe und mühsame Aufgabe: Sie müssen viele Daten aus verschiedenen Abteilungen und Produktionsketten sammeln, verarbeiten und analysieren. Mehr dazu lesen Sie im Artikel „Modellierung von Produktionsprozessen in einem IT-Unternehmen".

Als wir mit der Modellierung unseres Produktionsprozesses begannen, hatten wir ein konkretes Ziel – jedem Mitarbeiter, der an der Entwicklung der Produkte unseres Unternehmens beteiligt ist, und den Projektmanagern Folgendes zu vermitteln:

• wie Produkte und ihre Komponenten, beginnend mit dem Commit einer Codezeile, den Kunden in Form von Installationsprogrammen und Updates erreichen,
• welche Ressourcen für jede Produktionsstufe der Produkte bereitgestellt werden,
• welche Dienstleistungen in jeder Phase beteiligt sind,
• wie die Verantwortungsbereiche für jede Stufe abgegrenzt sind,
• welche Verträge am Eingang und Ausgang jeder Stufe bestehen.

Ein Klick auf das Bild öffnet es in voller Größe.

Unsere Arbeit im Unternehmen gliedert sich in mehrere Funktionsbereiche. Die Leitung der Infrastruktur beschäftigt sich mit der Optimierung des Betriebs aller „Eisen“-Ressourcen der Abteilung sowie der Automatisierung der Bereitstellung virtueller Maschinen und der darauf befindlichen Umgebung. Die Überwachungsrichtung ermöglicht eine Kontrolle der Serviceleistung rund um die Uhr. Wir bieten auch Überwachung als Service für Entwickler an. Die Workflow-Richtung stellt Teams Tools zur Verfügung, um Entwicklungs- und Testprozesse zu verwalten, den Status des Codes zu analysieren und Analysen zu Projekten zu erhalten. Und schließlich sorgt die Webdev-Leitung für die Veröffentlichung von Releases auf den GUS- und FLUS-Update-Servern sowie die Lizenzierung von Produkten über den LicenseLab-Dienst. Um die Produktionspipeline zu unterstützen, richten wir viele verschiedene Supportdienste für Entwickler ein und pflegen diese (Sie können Geschichten über einige davon auf alten Meetups anhören: Op!DevOps! 2016 и Op!DevOps! 2017). Wir entwickeln auch interne Automatisierungstools, darunter Open-Source-Lösungen.

In den letzten fünf Jahren haben sich in unserer Arbeit viele gleichartige und routinemäßige Vorgänge angesammelt, und unsere Entwickler aus anderen Abteilungen kommen hauptsächlich aus den sogenannten typische Aufgaben, dessen Lösung ganz oder teilweise automatisiert ist, den Darstellern keine Schwierigkeiten bereitet und keinen nennenswerten Arbeitsaufwand erfordert. Gemeinsam mit den leitenden Bereichen haben wir solche Aufgaben analysiert und konnten einzelne Arbeitskategorien identifizieren, bzw Produktionsschritte, wurden die Etappen in unteilbare Schritte unterteilt, und mehrere Etappen addieren sich Produktionsprozesskette.

Das einfachste Beispiel einer Technologiekette sind die Phasen der Montage, Bereitstellung und Prüfung jedes unserer Produkte innerhalb des Unternehmens. Die Build-Phase wiederum besteht beispielsweise aus vielen einzelnen typischen Schritten: Herunterladen von Quellen von GitLab, Vorbereiten von Abhängigkeiten und Bibliotheken von Drittanbietern, Unit-Tests und statische Code-Analyse, Ausführen eines Build-Skripts auf GitLab CI, Veröffentlichen von Artefakten im Repository Artifactory und Generierung von Versionshinweisen durch unser internes ChangelogBuilder-Tool.

Über typische DevOps-Aufgaben können Sie in unseren anderen Artikeln auf Habré lesen: „Persönliche Erfahrung: Wie unser Continuous-Integration-System aussieht"Und"Automatisierung von Entwicklungsprozessen: Wie wir DevOps-Ideen bei Positive Technologies umgesetzt haben".

Es bilden sich viele typische Produktionsketten Herstellungsprozess. Der Standardansatz zur Beschreibung von Prozessen besteht in der Verwendung funktionaler IDEF0-Modelle.

Ein Beispiel für die Modellierung eines Fertigungs-CI-Prozesses

Besonderes Augenmerk legten wir auf die Entwicklung von Standardprojekten für ein Continuous-Integration-System. Dadurch konnte eine Vereinheitlichung der Projekte erreicht werden, wobei die sogenannten hervorgehoben wurden Release-Build-Schema mit Werbeaktionen.

So funktioniert das. Alle Projekte sehen typisch aus: Sie umfassen die Konfiguration von Assemblys, die in das Snapshot-Repository bei Artifactory fallen. Anschließend werden sie auf Prüfständen bereitgestellt und getestet und dann in das Release-Repository hochgestuft. Der Artifactory-Dienst ist ein zentraler Verteilungspunkt für alle Build-Artefakte zwischen Teams und anderen Diensten.

Wenn wir unser Release-Schema stark vereinfachen und verallgemeinern, dann umfasst es die folgenden Schritte:

• plattformübergreifende Produktmontage,
• Einsatz auf Prüfständen,
• Durchführung von Funktions- und anderen Tests,
• Förderung getesteter Builds zur Veröffentlichung von Repositorys bei Artifactory,
• Veröffentlichung von Release-Builds auf Update-Servern,
• Lieferung von Baugruppen und Updates zur Produktion,
• Starten der Installation und Aktualisierung des Produkts.

Betrachten Sie beispielsweise das technologische Modell dieses typischen Release-Schemas (im Folgenden einfach Modell) in Form eines funktionalen IDEF0-Modells. Es spiegelt die Hauptphasen unseres CI-Prozesses wider. IDEF0-Modelle verwenden das sogenannte ICOM-Notation (Input-Control-Output-Mechanismus) beschreibt, welche Ressourcen in jeder Phase verwendet werden, basierend auf den Regeln und Anforderungen, an denen gearbeitet wird, was die Ausgabe ist und welche Mechanismen, Dienste oder Personen eine bestimmte Phase implementieren.

Ein Klick auf das Bild öffnet es in voller Größe.

In der Regel ist es einfacher, die Beschreibung von Prozessen in Funktionsmodellen zu zerlegen und zu detaillieren. Aber je mehr Elemente es gibt, desto schwieriger wird es, etwas darin zu verstehen. Aber in der realen Entwicklung gibt es auch Hilfsstufen: Überwachung, Zertifizierung von Produkten, Automatisierung von Arbeitsabläufen und andere. Aufgrund des Skalierungsproblems haben wir diese Beschreibung aufgegeben.

Geburt der Hoffnung

In einem Buch stießen wir auf alte sowjetische Karten, die technologische Prozesse beschreiben (die übrigens noch heute in vielen Staatsbetrieben und Universitäten verwendet werden). Warten Sie, warten Sie, denn wir haben auch einen Workflow! Es gibt Phasen, Ergebnisse, Metriken, Anforderungen, Indikatoren usw. Und so weiter. Warum versuchen Sie nicht, Flussdiagramme auch auf unsere Produktpipelines anzuwenden? Es gab ein Gefühl: „Das ist es! Wir haben den richtigen Faden gefunden, es ist Zeit, ihn gut zu ziehen!

In einer einfachen Tabelle haben wir beschlossen, Produkte nach Spalten und technologische Stufen und Produktpipeline-Schritte nach Zeilen aufzuzeichnen. Meilensteine ​​sind etwas Großes, beispielsweise ein Produktentwicklungsschritt. Und die Schritte sind etwas kleiner und detaillierter, etwa der Schritt des Herunterladens des Quellcodes auf den Build-Server oder der Schritt des Kompilierens des Codes.

An den Schnittpunkten der Zeilen und Spalten der Karte tragen wir die Status für eine bestimmte Phase und ein bestimmtes Produkt ein. Für Status wurde eine Reihe von Zuständen definiert:

1. Keine Information - oder unangemessen. Es ist notwendig, die Nachfrage nach einer Stufe des Produkts zu analysieren. Entweder wurde die Analyse bereits durchgeführt, der Schritt wird jedoch derzeit nicht benötigt oder ist wirtschaftlich nicht gerechtfertigt.
2. Verschoben - oder im Moment nicht relevant. Eine Etappe in der Pipeline ist erforderlich, aber es fehlen in diesem Jahr die Kräfte für die Umsetzung.
3. Geplant. Die Umsetzung der Etappe ist für dieses Jahr geplant.
4. Umgesetzt. Die Stufe in der Pipeline wird im erforderlichen Volumen umgesetzt.

Das Ausfüllen der Tabelle begann Projekt für Projekt. Zunächst wurden die Phasen und Schritte eines Projekts klassifiziert und deren Status erfasst. Dann nahmen sie das nächste Projekt, korrigierten darin die Status und fügten die Phasen und Schritte hinzu, die in früheren Projekten fehlten. Als Ergebnis erhielten wir die Phasen und Schritte unserer gesamten Produktionspipeline und deren Status in einem bestimmten Projekt. Es stellte sich heraus, dass es etwas Ähnliches wie die Kompetenzmatrix der Produktpipeline war. Wir nannten eine solche Matrix eine technologische Karte.

Mit Hilfe der technologischen Landkarte stimmen wir messtechnisch sinnvoll mit den Teams die Arbeitspläne für das Jahr und die Ziele ab, die wir gemeinsam erreichen wollen: welche Etappen wir in diesem Jahr zum Projekt hinzufügen und welche wir auf später verschieben. Außerdem kann es im Laufe der Arbeit zu Verbesserungen in den Phasen kommen, die wir nur für ein Produkt abgeschlossen haben. Dann erweitern wir unsere Karte und führen diese Verbesserung als Stufe oder neuen Schritt ein, dann analysieren wir für jedes Produkt und finden heraus, ob die Verbesserung machbar ist.

Sie könnten uns widersprechen: „Das ist natürlich alles gut, nur wird die Anzahl der Schritte und Etappen mit der Zeit unerschwinglich groß.“ Wie sein?

Wir haben standardisierte und ziemlich vollständige Beschreibungen der Anforderungen für jede Phase und jeden Schritt eingeführt, damit sie von allen im Unternehmen gleichermaßen verstanden werden. Im Laufe der Zeit, wenn Verbesserungen eingeführt werden, kann es sein, dass ein Schritt in eine andere Phase oder einen anderen Schritt übergeht und dann „zusammenbricht“. Gleichzeitig passen alle Anforderungen und technologischen Nuancen zu den Anforderungen der Generalisierungsstufe oder -stufe.

Wie lässt sich die Wirkung replizierender Lösungen bewerten? Wir verwenden einen äußerst einfachen Ansatz: Wir rechnen die anfänglichen Kapitalkosten für die Implementierung einer neuen Stufe mit den jährlichen allgemeinen Produktkosten zusammen und dividieren sie dann bei der Replikation durch alle.

Teile der Entwicklung sind bereits als Meilensteine ​​und Schritte auf der Karte dargestellt. Wir können die Reduzierung der Produktkosten durch die Einführung von Automatisierung für typische Phasen beeinflussen. Anschließend betrachten wir die Veränderungen der qualitativen Merkmale, quantitativen Kennzahlen und den von den Teams erzielten Gewinn (in eingesparten Arbeitsstunden oder Maschinenstunden).

Technologische Karte des Produktionsprozesses

Wenn wir alle unsere Stufen und Schritte nehmen, sie mit Tags kodieren und zu einer Kette erweitern, wird es sich als sehr lang und unverständlich herausstellen (genau derselbe „Python-Schwanz“, über den wir am Anfang des Artikels gesprochen haben). :

[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]

Dies sind die Phasen des Erstellens von Produkten [Build], deren Bereitstellung auf Testservern [Deploy], des Testens [Testen], des Hochstufens von Builds zur Veröffentlichung von Repositorys basierend auf den Testergebnissen [Promote], des Generierens und Veröffentlichens von Lizenzen [License], des Veröffentlichens [ Veröffentlichung] auf dem GUS-Update-Server und Bereitstellung an FLUS-Update-Server, Installation und Aktualisierung von Produktkomponenten in der Infrastruktur des Kunden mithilfe von Product Configuration Management [Install] sowie Erfassung von Telemetriedaten [Telemetry] von installierten Produkten.

Darüber hinaus können einzelne Phasen unterschieden werden: Überwachung des Infrastrukturzustands [InfMonitoring], Versionierung des Quellcodes [SourceCodeControl], Vorbereitung der Build-Umgebung [Prepare], Projektmanagement [Workflow], Bereitstellung von Kommunikationstools für Teams [Communication], Produktzertifizierung [ Zertifizierung] und Sicherstellung der Autarkie von CI-Prozessen [CISelfSufficiency] (z. B. Unabhängigkeit von Baugruppen vom Internet). Dutzende Schritte in unseren Prozessen werden nicht einmal berücksichtigt, weil sie sehr spezifisch sind.

Der gesamte Produktionsprozess ist viel einfacher zu verstehen und zu betrachten, wenn er in Form dargestellt wird technologische Karte; Hierbei handelt es sich um eine Tabelle, in der die einzelnen Produktionsstufen und zerlegten Schritte des Modells in Zeilen geschrieben sind und in den Spalten eine Beschreibung dessen, was in jeder Phase oder jedem Schritt getan wird. Der Schwerpunkt liegt auf den Ressourcen, die jede Stufe bereitstellt, und der Abgrenzung der Verantwortungsbereiche.

Die Karte ist für uns eine Art Klassifikator. Es spiegelt die großen technologischen Teile der Herstellung von Produkten wider. Dadurch wurde es für unser Automatisierungsteam einfacher, mit Entwicklern zu interagieren und gemeinsam die Implementierung von Automatisierungsphasen zu planen sowie zu verstehen, welche Arbeitskosten und Ressourcen (Personal und Hardware) dafür erforderlich sind.

In unserem Unternehmen wird die Karte automatisch aus der Jinja-Vorlage als reguläre HTML-Datei generiert und dann auf den GitLab Pages-Server hochgeladen. Ein Screenshot mit einem Beispiel einer vollständig generierten Karte kann angezeigt werden Link.

Ein Klick auf das Bild öffnet es in voller Größe.

Kurz gesagt ist die technologische Landkarte ein verallgemeinertes Bild des Produktionsprozesses, das klar klassifizierte Blöcke mit typischer Funktionalität widerspiegelt.

Aufbau unserer Roadmap

Die Karte besteht aus mehreren Teilen:

1. Titelbereich – hier finden Sie eine allgemeine Beschreibung der Karte, grundlegende Konzepte werden vorgestellt, die wichtigsten Ressourcen und Ergebnisse des Produktionsprozesses werden definiert.
2. Dashboard – hier können Sie die Anzeige der Daten für einzelne Produkte steuern, es wird eine Zusammenfassung der durchgeführten Phasen und Schritte allgemein für alle Produkte bereitgestellt.
3. Technologische Karte – eine tabellarische Beschreibung des technologischen Prozesses. Auf der Karte:
   • alle Stufen, Schritte und ihre Codes sind angegeben;
   • Es werden kurze und vollständige Beschreibungen der Etappen gegeben.
   • die in jeder Phase verwendeten Input-Ressourcen und Dienste werden angegeben;
   • die Ergebnisse jeder Stufe und eines separaten Schritts werden angezeigt;
   • der Verantwortungsbereich für jede Stufe und jeden Schritt ist angegeben;
   • die technischen Ressourcen wie HDD (SSD), RAM, vCPU und die Arbeitsstunden, die zur Unterstützung der Arbeit in dieser Phase erforderlich sind, sowohl zum aktuellen Zeitpunkt – eine Tatsache, als auch für die Zukunft – ein Plan, wurden festgelegt;
   • Für jedes Produkt wird angegeben, welche technologischen Stufen oder Schritte dafür implementiert, zur Implementierung geplant, irrelevant oder nicht implementiert sind.

Entscheidungsfindung basierend auf der technologischen Landkarte

Nach Prüfung der Karte können – abhängig von der Rolle des Mitarbeiters im Unternehmen (Entwicklungsleiter, Produktmanager, Entwickler oder Tester) – einige Maßnahmen ergriffen werden:

• Verstehen Sie, welche Phasen in einem realen Produkt oder Projekt fehlen, und beurteilen Sie die Notwendigkeit ihrer Implementierung.
• die Zuständigkeitsbereiche zwischen mehreren Abteilungen abgrenzen, wenn diese auf unterschiedlichen Stufen arbeiten;
• Verträge an den Ein- und Ausgängen der Bühnen vereinbaren;
• Integrieren Sie Ihren Arbeitsschritt in den gesamten Entwicklungsprozess.
• Bewerten Sie den Bedarf an Ressourcen, die die einzelnen Phasen bereitstellen, genauer.

Alles oben Genannte zusammengefasst

Das Routing ist vielseitig, erweiterbar und leicht zu warten. Es ist viel einfacher, eine Beschreibung von Prozessen in dieser Form zu entwickeln und zu pflegen als in einem streng akademischen IDEF0-Modell. Darüber hinaus ist eine tabellarische Beschreibung einfacher, vertrauter und besser strukturiert als ein Funktionsmodell.

Für die technische Umsetzung der Schritte verfügen wir über ein spezielles internes Tool CrossBuilder – ein Layer-Tool zwischen CI-Systemen, Diensten und Infrastruktur. Der Entwickler muss sein Fahrrad nicht kürzen: In unserem CI-System reicht es aus, eines der Skripte (die sogenannte Aufgabe) des CrossBuilder-Tools auszuführen, das es unter Berücksichtigung der Merkmale unserer Infrastruktur korrekt ausführt .

Ergebnisse

Der Artikel ist recht lang geworden, was bei der Beschreibung der Modellierung komplexer Prozesse jedoch unvermeidlich ist. Abschließend möchte ich kurz unsere Hauptgedanken festhalten:

• Das Ziel der Umsetzung von DevOps-Ideen in unserem Unternehmen besteht darin, die Produktions- und Wartungskosten der Unternehmensprodukte quantitativ (Mann- oder Maschinenstunden, vCPU, RAM, Disk) konsequent zu senken.
• Die Möglichkeit, die Gesamtkosten der Entwicklung zu senken, besteht darin, die Kosten für die Durchführung typischer Serienaufgaben zu minimieren: Phasen und Schritte des technologischen Prozesses.
• Eine typische Aufgabe ist eine Aufgabe, deren Lösung vollständig oder teilweise automatisiert ist, den Ausführenden keine Schwierigkeiten bereitet und keine nennenswerten Arbeitskosten erfordert.
• Der Produktionsprozess besteht aus Phasen, die Phasen sind in unteilbare Schritte unterteilt, die typische Aufgaben unterschiedlichen Umfangs und Umfangs darstellen.
• Von disparaten typischen Aufgaben sind wir zu komplexen Technologieketten und mehrstufigen Modellen des Produktionsprozesses gelangt, die durch ein funktionales IDEF0-Modell oder eine einfachere Technologiekarte beschrieben werden können.
• Die technologische Landkarte ist eine tabellarische Darstellung der Phasen und Schritte des Produktionsprozesses. Das Wichtigste: Die Karte ermöglicht es Ihnen, den gesamten Prozess in seiner Gesamtheit zu sehen, in großen Teilen mit der Möglichkeit, diese zu detaillieren.
• Basierend auf der technologischen Landkarte ist es möglich, die Notwendigkeit der Einführung von Stufen in einem bestimmten Produkt zu beurteilen, Verantwortungsbereiche abzugrenzen, Verträge an den Ein- und Ausgängen von Stufen zu vereinbaren und den Ressourcenbedarf genauer einzuschätzen.

In den folgenden Artikeln werden wir genauer beschreiben, mit welchen technischen Hilfsmitteln bestimmte technologische Stufen auf unserer Karte umgesetzt werden.

Artikelautoren:

• Alexander Pasdnikow — Leiter Automatisierung (DevOps) bei Positive Technologies
• Timur Gilmullin - Stellvertreter Leiter der Automatisierungsabteilung (DevOps) bei Positive Technologies

Source: habr.com