Text size
Auf meinem Radar5 Min. Lesezeit

Portale, CLIs oder Git: Was Entwickler wirklich verwenden

Ein glänzendes Portal ist schön. Aber ist es das, was Ihre Entwickler tatsächlich jeden Tag öffnen?

Portals, CLIs or Git: what developers really use
KI-generierte Illustration

Wenn Plattformteams ihre Arbeit vorzeigen, zeigen sie normalerweise ein Portal. Schöne Karten, Service-Seiten, ein großer "Erstellen"-Button. Es zeigt sich wunderschön.

Aber wenn ich Entwickler wirklich arbeiten sehe, leben sie selten in einem Portal. Sie leben in ihrem Editor, ihrem Terminal, ihren Zugwünschen und ihrem Chat-Tool. Die Frage, die sich jedes Plattformteam stellen sollte, ist: Wo sollte die Plattform Entwickler treffen?

Drei Möglichkeiten, eine Plattform anzubieten

Ein Webportal (Hintergrund, Hafen und andere). Perfekt für Entdeckungen: Dienstleistungen, Eigentümer, Dokumente finden, und für gelegentliche Aufgaben wie die Erstellung eines neuen Dienstes. Weniger gut für Dinge, die man 20 Mal am Tag macht.

Ein CLI. Entwickler, die im Terminal leben, lieben ein gutes Befehlszeilenwerkzeug. platform create service, platform logs, platform env up- Ich weiß . Schnell, scriptbar, einfach zu bedienen in der Informatik. Der Nachteil: Jemand muss es bauen und warten, und es muss überall installiert und aktualisiert werden.

Git als Schnittstelle (GitOps). Entwickler ändern eine YAML-Datei in einem Repository, öffnen eine Pull-Anfrage und die Automatisierung macht den Rest. Jede Änderung wird überprüft, verändert und überprüft. Der Nachteil: YAML-Ermüdung und weniger erkennbar für Neulinge.

Keines davon ist "das Richtige". Sie sind in verschiedenen Momenten gut.

Die beste Plattform-Schnittstelle ist die, die Entwickler bereits betrachten, wenn sie sie brauchen.

Was ich gelernt habe, indem ich Entwickler

Wenn man Entwickler fragt, was sie von einer Plattform wollen, sind die Antworten selten "ein schöneres Portal". Meistens sind es Dinge wie:

  • "Ich will nur wissen, warum mein Einsatz fehlgeschlagen ist, ohne jemanden zu fragen".
  • "Ich will Protokolle für meinen Dienst ohne eine Abfrage Sprache zu lernen".
  • "Ich will eine Testumgebung ohne Ticket zu öffnen".
  • "Ich will wissen, wem der Dienst gehört, der meinen kaputt macht".

Beachten Sie, dass es hier um Ergebnisse geht, nicht um Schnittstellen. Die Aufgabe des Plattformteams ist es, diese Ergebnisse einfach zu machen, egal wo sich der Entwickler befindet.

Einige praktische Muster, die gut funktionieren:

  • Bringen Sie Informationen zur Anfrage. Vorsicht URLs, Testergebnisse, Sicherheitsbefunde und Kostenänderungen als Kommentare zum PR.
  • Alarme zum Chat bringen mit Links direkt zum rechten Dashboard und Runbook.
  • Nutzen Sie das Portal für die Entdeckung und seltenen Aktionen, nicht täglichen Arbeit.
  • Die wahre Quelle der Wahrheit in Git behalten, und lassen Sie das Portal und CLI aus ihm lesen.

Docs sind ein Feature

Der am meisten unterschätzte Teil jeder Plattform ist die Dokumentation. Eine Plattform, die niemand versteht, ist eine Plattform die niemand benutzt.

Gute Plattformdokumente:

  • Beginnen Sie mit "Wie mache ich X" -Anleitungen, nicht mit Architekturdiagrammen.
  • Sie leben neben dem Code (Docs-as-code) und werden wie Code überprüft.
  • Haben Sie Kopieren- und Einfügen-Beispiele, die wirklich funktionieren.
  • Sie gehören jemandem und werden regelmäßig überprüft.

Wenn Sie in diesem Quartal nur Zeit für eine Verbesserung haben, schlägt die Verbesserung von Dokumenten oft das Hinzufügen einer neuen Funktion.

Vor- und Nachnummern

Welche Schnittstelle Sie auch wählen, messen Sie, ob sie hilft. Vor- und Nachvergleiche nützlich:

  • Zeit von "Ich brauche einen neuen Service" zu "er läuft in einer Testumgebung".
  • Anzahl der Routineanfragen an das Plattformteam.
  • Wie oft benötigen Entwickler Hilfe, um eine fehlgeschlagene Bereitstellung zu debuggen.
  • Umfrageantworten auf "Wie einfach ist es, eine Änderung zu liefern?"

Wenn sich die Zahlen nach dem Starten eines Portals nicht bewegen, ist das Portal nicht das Problem, das Sie lösen mussten.

Also, welches sollst du bauen?

Beginnen Sie, wo Ihre Entwickler bereits sind. Für die meisten Teams sind das Git und Pull-Anfragen, mit guter Automatisierung dahinter. Fügen Sie eine CLI hinzu, wenn Ihre Entwickler terminal-schwer sind. Fügen Sie ein Portal hinzu, wenn Entdeckung ein echtes Problem wird, normalerweise, wenn Sie Dutzende von Diensten und Teams haben.

Meine Meinung: Bauen Sie die Plattform um die Gewohnheiten der Entwickler, nicht um die Demo. Die Vorführung dauert zehn Minuten, die Gewohnheiten dauern Jahre.

Desly