Infrastructure as Code: So überwinden Sie Probleme mit XP

Hallo, Habr! Zuvor habe ich mich über das Leben im Infrastructure-as-Code-Paradigma beschwert und nichts zur Lösung der aktuellen Situation angeboten. Heute melde ich mich zurück, um Ihnen zu sagen, welche Ansätze und Praktiken Ihnen helfen, dem Abgrund der Verzweiflung zu entkommen und die Situation in die richtige Richtung zu lenken.

In einem früheren Artikel „Infrastruktur als Code: erste Bekanntschaft“ Ich teilte meine Eindrücke zu diesem Bereich mit, versuchte über die aktuelle Situation in diesem Bereich nachzudenken und schlug sogar vor, dass Standardpraktiken, die allen Entwicklern bekannt sind, hilfreich sein könnten. Es mag den Anschein haben, dass es viele Beschwerden über das Leben gab, aber es gab keine Vorschläge für einen Ausweg aus der aktuellen Situation.

Wer wir sind, wo wir sind und welche Probleme wir haben

Wir sind derzeit im Sre Onboarding Team, das aus sechs Programmierern und drei Infrastrukturingenieuren besteht. Wir alle versuchen, Infrastructure as Code (IaC) zu schreiben. Wir tun dies, weil wir grundsätzlich wissen, wie man Code schreibt, und in der Vergangenheit „überdurchschnittliche“ Entwickler waren.

• Wir haben eine Reihe von Vorteilen: einen bestimmten Hintergrund, Kenntnisse über Praktiken, die Fähigkeit, Code zu schreiben, den Wunsch, neue Dinge zu lernen.
• Und es gibt einen nachlassenden Teil, der auch ein Minuspunkt ist: mangelndes Wissen über Infrastruktur-Hardware.

Der Technologie-Stack, den wir in unserem IaC verwenden.

• Terraform zum Erstellen von Ressourcen.
• Packer zum Zusammenstellen von Bildern. Dies sind Windows- und CentOS 7-Images.
• Jsonnet, um einen leistungsstarken Build in Drone.io zu erstellen sowie Packer-JSON und unsere Terraform-Module zu generieren.
• Azure.
• Ansible bei der Bildvorbereitung.
• Python für Hilfsdienste und Bereitstellungsskripte.
• Und das alles in VSCode mit Plugins, die von den Teammitgliedern gemeinsam genutzt werden.

Fazit von mir letzter Artikel Das war so: Ich habe versucht, (vor allem mir selbst) Optimismus einzuflößen, ich wollte sagen, dass wir die uns bekannten Ansätze und Praktiken ausprobieren werden, um mit den Schwierigkeiten und Komplexitäten, die in diesem Bereich bestehen, umzugehen.

Wir kämpfen derzeit mit den folgenden IaC-Problemen:

• Unvollkommenheit der Werkzeuge und Mittel zur Codeentwicklung.
• Langsame Bereitstellung. Infrastruktur ist Teil der realen Welt und kann langsam sein.
• Mangel an Ansätzen und Praktiken.
• Wir sind neu und wissen nicht viel.

Extreme Programming (XP) zur Rettung

Alle Entwickler sind mit Extreme Programming (XP) und den dahinter stehenden Praktiken vertraut. Viele von uns haben mit diesem Ansatz gearbeitet und er war erfolgreich. Warum also nicht die dort niedergelegten Grundsätze und Praktiken nutzen, um Infrastrukturherausforderungen zu meistern? Wir haben uns für diesen Ansatz entschieden und sehen, was passiert.

Prüfung der Anwendbarkeit des XP-Ansatzes auf Ihre BrancheHier finden Sie eine Beschreibung der Umgebung, für die XP gut geeignet ist, und wie sie sich auf uns auswirkt:

1. Sich dynamisch ändernde Softwareanforderungen. Uns war klar, was das Endziel war. Die Details können jedoch variieren. Wir entscheiden selbst, wohin wir rollen müssen, daher ändern sich die Anforderungen regelmäßig (hauptsächlich von uns selbst). Wenn wir das SRE-Team nehmen, das die Automatisierung selbst übernimmt und die Anforderungen und den Arbeitsumfang selbst einschränkt, dann passt dieser Punkt gut.

2. Risiken, die durch befristete Projekte mit neuer Technologie entstehen. Bei der Verwendung einiger uns unbekannter Dinge können Risiken auftreten. Und das ist zu 100 % unser Fall. Unser gesamtes Projekt war der Einsatz von Technologien, mit denen wir nicht vollständig vertraut waren. Im Allgemeinen ist dies ein ständiges Problem, weil... Im Infrastruktursektor entstehen ständig viele neue Technologien.

3,4. Kleines, am selben Ort ansässiges erweitertes Entwicklungsteam. Die von Ihnen verwendete automatisierte Technologie ermöglicht Unit- und Funktionstests. Diese beiden Punkte passen nicht ganz zu uns. Erstens sind wir kein eingespieltes Team und zweitens sind wir zu neunt, was man als großes Team bezeichnen kann. Obwohl nach einigen Definitionen eines „großen“ Teams ein Team aus mehr als 14 Personen besteht.

Schauen wir uns einige XP-Praktiken an und wie sie sich auf die Geschwindigkeit und Qualität des Feedbacks auswirken.

XP-Feedback-Loop-Prinzip

Nach meinem Verständnis ist Feedback die Antwort auf die Frage: Mache ich das Richtige, gehen wir dorthin? XP verfügt dafür über ein göttliches Schema: eine Zeitrückkopplungsschleife. Das Interessante daran ist: Je niedriger wir sind, desto schneller können wir das Betriebssystem dazu bringen, die notwendigen Fragen zu beantworten.

Dies ist ein ziemlich interessantes Diskussionsthema, denn in unserer IT-Branche ist es möglich, schnell ein Betriebssystem zu bekommen. Stellen Sie sich vor, wie schmerzhaft es ist, sechs Monate lang an einem Projekt zu arbeiten und erst dann festzustellen, dass am Anfang ein Fehler passiert ist. Dies geschieht beim Entwurf und bei der Konstruktion komplexer Systeme.

In unserem Fall von IaC hilft uns Feedback. Ich werde sofort eine kleine Anpassung an der obigen Abbildung vornehmen: Der Release-Plan hat keinen monatlichen Zyklus, sondern erfolgt mehrmals täglich. Mit diesem Betriebssystemzyklus sind einige Praktiken verbunden, die wir genauer betrachten werden.

Wichtig: Feedback kann eine Lösung für alle oben genannten Probleme sein. In Kombination mit XP-Übungen kann es Sie aus dem Abgrund der Verzweiflung befreien.

Wie Sie sich aus dem Abgrund der Verzweiflung befreien: drei Übungen

Tests

Tests werden in der XP-Feedbackschleife zweimal erwähnt. Es ist nicht einfach so. Sie sind äußerst wichtig für die gesamte Extreme Programming-Technik.

Es wird davon ausgegangen, dass Sie über Unit- und Akzeptanztests verfügen. Einige geben Ihnen innerhalb weniger Minuten Feedback, andere innerhalb weniger Tage, sodass das Schreiben länger dauert und seltener überprüft wird.

Es gibt eine klassische Testpyramide, die zeigt, dass es mehr Tests geben sollte.

Wie lässt sich dieser Rahmen auf uns in einem IaC-Projekt anwenden? Eigentlich... überhaupt nicht.

• Unit-Tests können nicht zu viele sein, obwohl es viele davon geben sollte. Oder sie testen etwas sehr indirekt. Tatsächlich können wir sagen, dass wir sie überhaupt nicht schreiben. Aber hier sind ein paar Anwendungen für solche Tests, die wir durchführen konnten:
  1. Jsonnet-Code testen. Das ist zum Beispiel unsere Drohnenmontage-Pipeline, die ziemlich kompliziert ist. Der Jsonnet-Code wird durch Tests gut abgedeckt.
     Wir nutzen dies Unit-Test-Framework für Jsonnet.
  2. Tests für Skripte, die beim Start der Ressource ausgeführt werden. Skripte werden in Python geschrieben und daher können Tests darauf geschrieben werden.
• Eventuell ist es möglich, die Konfiguration in Tests zu überprüfen, wir machen das aber nicht. Es ist auch möglich, Regeln zur Überprüfung der Ressourcenkonfiguration zu konfigurieren tflint. Allerdings sind die Prüfungen dort einfach zu einfach für Terraform, viele Testskripte sind jedoch für AWS geschrieben. Und wir sind auf Azure, daher trifft dies wiederum nicht zu.
• Komponentenintegrationstests: Es hängt davon ab, wie Sie sie klassifizieren und wo Sie sie platzieren. Aber grundsätzlich funktionieren sie.

  So sehen Integrationstests aus.

  
  
  Dies ist ein Beispiel für die Erstellung von Bildern in Drone CI. Um sie zu erreichen, müssen Sie 30 Minuten warten, bis sich das Packer-Bild bildet, und dann weitere 15 Minuten warten, bis sie vorbei sind. Aber es gibt sie!

  Bildverifizierungsalgorithmus

  1. Der Packer muss das Image zunächst vollständig vorbereiten.
  2. Neben dem Test befindet sich ein Terraform mit einem lokalen Status, den wir zum Bereitstellen dieses Images verwenden.
  3. Beim Aufklappen wird ein in der Nähe liegendes kleines Modul genutzt, um die Arbeit mit dem Bild zu erleichtern.
  4. Sobald die VM über das Image bereitgestellt wurde, können die Prüfungen beginnen. Grundsätzlich erfolgt die Kontrolle mit dem Auto. Es prüft, wie die Skripte beim Start funktionierten und wie die Daemons funktionieren. Dazu loggen wir uns per ssh oder winrm in die neu hochgefahrene Maschine ein und prüfen den Konfigurationsstatus bzw. ob die Dienste aktiv sind.

• Ähnlich verhält es sich mit Integrationstests in Modulen für Terraform. Hier finden Sie eine kurze Tabelle, in der die Merkmale solcher Tests erläutert werden.

  
  
  Das Feedback zur Pipeline dauert etwa 40 Minuten. Alles passiert sehr lange. Es kann zur Regression verwendet werden, für Neuentwicklungen ist es jedoch im Allgemeinen unrealistisch. Wenn Sie sehr, sehr darauf vorbereitet sind, laufende Skripte vorbereiten, können Sie die Zeit auf 10 Minuten reduzieren. Aber das sind immer noch keine Unit-Tests, die 5 Teile in 100 Sekunden erledigen.

Das Fehlen von Unit-Tests beim Zusammenstellen von Bildern oder Terraform-Modulen fördert die Verlagerung der Arbeit auf separate Dienste, die einfach über REST ausgeführt werden können, oder auf Python-Skripte.

Beispielsweise mussten wir sicherstellen, dass sich die virtuelle Maschine beim Start beim Dienst registriert ScaleFT, und als die virtuelle Maschine zerstört wurde, löschte sie sich selbst.

Da wir ScaleFT als Dienst haben, sind wir gezwungen, über die API damit zu arbeiten. Dort war ein Wrapper geschrieben, den man herausziehen und sagen konnte: „Geh rein und lösche dies und das.“ Es speichert alle notwendigen Einstellungen und Zugriffe.

Wir können dafür bereits normale Tests schreiben, da es sich nicht von gewöhnlicher Software unterscheidet: Eine Art Apiha wird verspottet, man zieht es und schaut, was passiert.

Ergebnisse der Tests: Unit-Tests, die das Betriebssystem in einer Minute liefern sollten, liefern es nicht. Und Testarten weiter oben in der Pyramide sind effektiv, decken aber nur einen Teil der Probleme ab.

Paar-Programmierung

Tests sind natürlich gut. Man kann viele davon schreiben, sie können unterschiedlicher Art sein. Sie werden auf ihrem Niveau arbeiten und uns Feedback geben. Aber das Problem mit schlechten Unit-Tests, die das schnellste Betriebssystem liefern, bleibt bestehen. Gleichzeitig möchte ich immer noch ein schnelles Betriebssystem, mit dem man einfach und angenehm arbeiten kann. Ganz zu schweigen von der Qualität der resultierenden Lösung. Glücklicherweise gibt es Techniken, die noch schnelleres Feedback liefern können als Unit-Tests. Das ist Paarprogrammierung.

Wenn Sie Code schreiben, möchten Sie so schnell wie möglich Feedback zu seiner Qualität erhalten. Ja, Sie können alles in einem Feature-Zweig schreiben (um niemandem etwas kaputt zu machen), einen Pull-Request in Github stellen, ihn jemandem zuweisen, dessen Meinung Gewicht hat, und auf eine Antwort warten.

Aber man kann lange warten. Die Leute sind alle beschäftigt und die Antwort, selbst wenn es eine gibt, ist möglicherweise nicht von höchster Qualität. Angenommen, die Antwort kam sofort, der Rezensent hat die ganze Idee sofort verstanden, aber die Antwort kommt immer noch spät, im Nachhinein. Ich wünschte, es wäre früher. Darauf zielt die Paarprogrammierung ab – zum Zeitpunkt des Verfassens dieses Artikels.

Nachfolgend sind die Paarprogrammierungsstile und ihre Anwendbarkeit bei der Arbeit an IaC aufgeführt:

1. Klassisch, Erfahren+Erfahren, Schicht nach Timer. Zwei Rollen – Fahrer und Navigator. Zwei Menschen. Sie arbeiten am gleichen Code und wechseln nach einer bestimmten vorgegebenen Zeitspanne die Rolle.

Betrachten wir die Kompatibilität unserer Probleme mit dem Stil:

• Problem: Unvollkommenheit von Tools und Tools für die Codeentwicklung.
  Negative Auswirkung: Die Entwicklung dauert länger, wir werden langsamer, das Tempo/Rhythmus der Arbeit geht verloren.
  Wie wir kämpfen: Wir verwenden andere Tools, eine gemeinsame IDE und lernen auch Abkürzungen.
• Problem: Langsame Bereitstellung.
  Negative Auswirkung: Erhöht die Zeit, die zum Erstellen eines funktionierenden Codeteils benötigt wird. Wir langweilen uns beim Warten, unsere Hände strecken sich aus, um etwas anderes zu tun, während wir warten.
  Wie wir kämpfen: Wir haben es nicht überwunden.
• Problem: Mangel an Ansätzen und Praktiken.
  Negative Auswirkung: Es fehlt das Wissen darüber, wie man es gut und wie man es schlecht macht. Verlängert den Erhalt von Feedback.
  Wie wir kämpfen: Der gegenseitige Austausch von Meinungen und Praktiken in Paararbeit löst das Problem nahezu.

Das Hauptproblem bei der Verwendung dieses Stils in IaC ist das ungleichmäßige Arbeitstempo. In der traditionellen Softwareentwicklung gibt es eine sehr einheitliche Bewegung. Sie können fünf Minuten damit verbringen, N zu schreiben. Nehmen Sie sich 10 Minuten Zeit und schreiben Sie 2N, 15 Minuten - 3N. Hier können Sie fünf Minuten damit verbringen, N zu schreiben, und dann weitere 30 Minuten damit verbringen, ein Zehntel von N zu schreiben. Hier wissen Sie nichts, Sie stecken fest, dumm. Die Untersuchung nimmt Zeit in Anspruch und lenkt vom Programmieren selbst ab.

Fazit: In seiner reinen Form ist es für uns nicht geeignet.

2. Tischtennis. Bei diesem Ansatz schreibt eine Person den Test und eine andere übernimmt die Implementierung. Wenn man bedenkt, dass bei Unit-Tests alles kompliziert ist und man einen Integrationstest schreiben muss, dessen Programmierung viel Zeit in Anspruch nimmt, geht die Leichtigkeit des Ping-Pong verloren.

Ich kann sagen, dass wir versucht haben, die Verantwortlichkeiten für den Entwurf eines Testskripts und die Implementierung des Codes dafür zu trennen. Ein Teilnehmer hat das Drehbuch verfasst, in diesem Teil der Arbeit war er verantwortlich, er hatte das letzte Wort. Und der andere war für die Umsetzung verantwortlich. Es hat gut geklappt. Die Qualität des Skripts steigt mit diesem Ansatz.

Fazit: Leider lässt das Arbeitstempo die Verwendung von Ping-Pong als Paarprogrammierungspraxis in IaC nicht zu.

3. Starker Stil. Schwierige Übung. Die Idee ist, dass ein Teilnehmer zum Anweisungsnavigator wird und der zweite die Rolle des Ausführungstreibers übernimmt. In diesem Fall liegt das Entscheidungsrecht ausschließlich beim Navigator. Der Treiber druckt nur und kann mit einem Wort Einfluss auf das Geschehen nehmen. Die Rollen ändern sich lange Zeit nicht.

Gut zum Lernen, erfordert aber ausgeprägte Soft Skills. Hier sind wir ins Stocken geraten. Die Technik war schwierig. Dabei geht es nicht einmal um Infrastruktur.

Fazit: Es kann potenziell genutzt werden, wir geben den Versuch nicht auf.

4. Mobbing, Swarming und alle bekannten, aber nicht aufgeführten Stile Wir denken nicht darüber nach, weil Wir haben es noch nicht ausprobiert und es ist unmöglich, im Rahmen unserer Arbeit darüber zu sprechen.

Allgemeine Ergebnisse zur Verwendung der Paarprogrammierung:

• Wir haben ein ungleichmäßiges Arbeitstempo, was verwirrend ist.
• Wir sind auf nicht ausreichend gute Soft Skills gestoßen. Und das Themengebiet trägt nicht dazu bei, diese unsere Mängel zu überwinden.
• Lange Tests und Probleme mit Tools erschweren die gepaarte Entwicklung.

5. Trotzdem gab es Erfolge. Wir haben unsere eigene Methode „Konvergenz – Divergenz“ entwickelt. Ich werde kurz beschreiben, wie es funktioniert.

Wir haben feste Partner für ein paar Tage (weniger als eine Woche). Wir erledigen gemeinsam eine Aufgabe. Wir sitzen eine Weile zusammen: der eine schreibt, der andere sitzt da und schaut dem Support-Team zu. Dann verstreuen wir uns eine Zeit lang, jeder macht ein paar unabhängige Dinge, dann kommen wir wieder zusammen, synchronisieren uns sehr schnell, machen etwas zusammen und verstreuen uns dann wieder.

Planung und Kommunikation

Der letzte Übungsblock, durch den Betriebssystemprobleme gelöst werden, ist die Organisation der Arbeit mit den Aufgaben selbst. Dazu gehört auch der Erfahrungsaustausch außerhalb der Paararbeit. Schauen wir uns drei Praktiken an:

1. Ziele durch den Zielbaum. Wir haben das Gesamtmanagement des Projekts über einen Baum organisiert, der endlos in die Zukunft reicht. Technisch erfolgt das Tracking in Miro. Es gibt eine Aufgabe – es ist ein Zwischenziel. Daraus ergeben sich entweder kleinere Ziele oder Aufgabengruppen. Aus ihnen entstehen die Aufgaben selbst. Alle Aufgaben werden auf diesem Board erstellt und verwaltet.

Dieses Schema liefert auch Feedback, das einmal täglich erfolgt, wenn wir uns bei Kundgebungen synchronisieren. Wenn allen ein gemeinsamer, aber strukturierter und völlig offener Plan vorliegt, ist allen bewusst, was gerade passiert und wie weit wir fortgeschritten sind.

Vorteile der visuellen Vision von Aufgaben:

• Kausalität. Jede Aufgabe führt zu einem globalen Ziel. Aufgaben werden in kleinere Ziele gruppiert. Der Infrastrukturbereich selbst ist recht technisch. Es ist nicht immer sofort klar, welche konkreten Auswirkungen beispielsweise das Schreiben eines Runbooks zur Migration auf ein anderes Nginx auf das Unternehmen hat. Wenn die Zielkarte in der Nähe ist, ist es klarer.
  
  Kausalität ist eine wichtige Eigenschaft von Problemen. Es beantwortet direkt die Frage: „Tue ich das Richtige?“
• Parallelität. Wir sind zu neunt und es ist körperlich einfach unmöglich, alle auf eine Aufgabe zu schicken. Auch Aufgaben aus einem Bereich reichen möglicherweise nicht immer aus. Wir sind gezwungen, die Arbeit zwischen kleinen Arbeitsgruppen zu parallelisieren. Gleichzeitig sitzen die Gruppen einige Zeit an ihrer Aufgabe, sie können durch jemand anderen verstärkt werden. Manchmal trennen sich Menschen von dieser Arbeitsgruppe. Jemand fährt in den Urlaub, jemand macht einen Bericht für die DevOps-Konferenz, jemand schreibt einen Artikel über Habr. Es wird sehr wichtig zu wissen, welche Ziele und Aufgaben parallel erledigt werden können.

2. Ersatzmoderatoren der Morgenbesprechungen. Bei Stand-ups haben wir dieses Problem: Die Leute erledigen viele Aufgaben parallel. Manchmal sind Aufgaben lose miteinander verbunden und es besteht kein Verständnis dafür, wer was tut. Und die Meinung eines anderen Teammitglieds ist sehr wichtig. Hierbei handelt es sich um zusätzliche Informationen, die den Lösungsverlauf des Problems verändern können. Natürlich ist normalerweise jemand dabei, aber Ratschläge und Tipps sind immer nützlich.

Um diese Situation zu verbessern, verwendeten wir die Technik „Changing the Leading Stand-Up“. Jetzt werden sie nach einer bestimmten Liste rotiert, und das zeigt seine Wirkung. Wenn Sie an der Reihe sind, müssen Sie eintauchen und verstehen, was vor sich geht, um ein gutes Scrum-Meeting durchzuführen.

3. Interne Demo. Hilfe bei der Lösung eines Problems durch Pair Programming, Visualisierung am Problembaum und Hilfe bei Scrum-Meetings am Morgen sind gut, aber nicht ideal. Als Paar sind Sie nur durch Ihr Wissen begrenzt. Der Aufgabenbaum hilft dabei, global zu verstehen, wer was tut. Und der Moderator und die Kollegen des Morgenmeetings werden sich nicht tief in Ihre Probleme vertiefen. Sie könnten sicherlich etwas verpassen.

Die Lösung bestand darin, sich gegenseitig die geleistete Arbeit vorzuführen und anschließend zu besprechen. Wir treffen uns einmal pro Woche für eine Stunde und zeigen Details zu Lösungen für Aufgaben, die wir in der letzten Woche erledigt haben.

Während der Demonstration ist es notwendig, die Details der Aufgabe offenzulegen und unbedingt ihre Funktionsweise zu demonstrieren.

Die Berichterstattung kann anhand einer Checkliste erfolgen.1. Treten Sie in den Kontext ein. Woher kam die Aufgabe, warum war sie überhaupt notwendig?

2. Wie wurde das Problem bisher gelöst? Beispielsweise waren massive Mausklicks erforderlich oder es war überhaupt nicht möglich, etwas zu tun.

3. Wie wir es verbessern. Zum Beispiel: „Sehen Sie, jetzt gibt es Scriptosik, hier ist die Readme-Datei.“

4. Zeigen Sie, wie es funktioniert. Es empfiehlt sich, einige Benutzerszenarien direkt zu implementieren. Ich will X, ich mache Y, ich sehe Y (oder Z). Ich stelle beispielsweise NGINX bereit, rauche die URL und erhalte 200 OK. Wenn die Aktion lang ist, bereiten Sie sie im Voraus vor, damit Sie sie später zeigen können. Es ist ratsam, es eine Stunde vor der Demo nicht zu sehr zu zerbrechen, wenn es zerbrechlich ist.

5. Erklären Sie, wie erfolgreich das Problem gelöst wurde, welche Schwierigkeiten bestehen bleiben, was nicht abgeschlossen ist und welche Verbesserungen in der Zukunft möglich sind. Zum Beispiel jetzt CLI, dann wird es eine vollständige Automatisierung in CI geben.

Es empfiehlt sich, die Redezeit für jeden Redner auf 5-10 Minuten zu begrenzen. Wenn Ihre Rede offensichtlich wichtig ist und länger dauern wird, stimmen Sie dies vorab im Sre-Takeover-Kanal ab.

Nach dem persönlichen Teil gibt es immer eine Diskussion im Thread. Hier erscheint das Feedback, das wir zu unseren Aufgaben benötigen.

Als Ergebnis wird eine Umfrage durchgeführt, um den Nutzen des Geschehens zu ermitteln. Dies ist eine Rückmeldung über den Kern der Rede und die Wichtigkeit der Aufgabe.

Lange Schlussfolgerungen und was als nächstes kommt

Der Ton des Artikels scheint etwas pessimistisch zu sein. Das ist nicht so. Zwei niedrigere Feedbackebenen, nämlich Tests und Paarprogrammierung, funktionieren. Nicht so perfekt wie bei der traditionellen Entwicklung, aber es gibt einen positiven Effekt.

Tests bieten in ihrer aktuellen Form nur eine teilweise Codeabdeckung. Viele Konfigurationsfunktionen bleiben ungetestet. Ihr Einfluss auf die eigentliche Arbeit beim Schreiben von Code ist gering. Integrationstests haben jedoch einen Effekt und ermöglichen Ihnen die bedenkenlose Durchführung von Refactorings. Das ist eine großartige Leistung. Mit der Verlagerung des Schwerpunkts auf die Entwicklung in Hochsprachen (wir haben Python, los) verschwindet das Problem auch. Und Sie brauchen nicht viele Prüfungen für den „Klebstoff“; eine allgemeine Integrationsprüfung reicht aus.

Die Arbeit zu zweit hängt mehr von bestimmten Personen ab. Da sind der Aufgabenfaktor und unsere Soft Skills. Bei manchen Menschen klappt es ganz gut, bei anderen schlechter. Das hat auf jeden Fall Vorteile. Selbst wenn die Regeln der Paararbeit nicht ausreichend beachtet werden, ist klar, dass sich allein die Tatsache, dass Aufgaben gemeinsam erledigt werden, positiv auf die Qualität des Ergebnisses auswirkt. Persönlich finde ich die Arbeit zu zweit einfacher und angenehmer.

Übergeordnete Möglichkeiten der Einflussnahme auf das Betriebssystem – präzises Planen und Bearbeiten von Aufgaben – haben Auswirkungen: hochwertiger Wissensaustausch und verbesserte Entwicklungsqualität.

Kurze Schlussfolgerungen in einer Zeile

• HR-Praktiker arbeiten im IaC, jedoch mit weniger Effizienz.
• Stärken Sie, was funktioniert.
• Überlegen Sie sich Ihre eigenen Kompensationsmechanismen und -praktiken.

Source: habr.com