Entwickler-Tools

Was in diese Kategorie gehört

Die Maschinerie rund ums Schreiben und Ausliefern von Code: Editoren, Versionsverwaltung, Code-Review, Continuous Integration, Paket-Registries, Umgebungs-Tooling und Release-Management.

Die Produkte hier kaufen die Menschen, die sie benutzen, was die Kategorie ungewöhnlich ehrlich macht. Entwickler verlassen Tools, die ihre Zeit verschwenden, und kein Beschaffungsprozess hält ein schlechtes lange am Leben.

Software im Produktivbetrieb zu beobachten gehört zu Monitoring. Schnittstellenarbeit für APIs steht unter API und Integrationen. Modellgestütztes Programmieren finden Sie bei den KI-Tools.

Die Pipeline ist das Produkt

Das meiste, was ein Team im Alltag spürt, kommt vom Weg, den eine Änderung zwischen Laptop und Produktion nimmt.

Dieser Weg hat vier Kontrollpunkte: Review, automatisierte Tests, ein Build-Artefakt und ein Deployment. Jedes Produkt in dieser Kategorie verbessert einen davon oder verbindet zwei.

Geschwindigkeit ist die Kennzahl, die Verhalten verändert. Eine Pipeline, die in vier Minuten fertig ist, wird ständig genutzt. Eine, die vierzig braucht, verändert, wie oft gepusht wird, fördert größere Änderungen und verschlechtert das Review. Wenn Sie Continuous-Integration-Dienste vergleichen, messen Sie einen echten Build Ihres eigenen Repositorys, statt einen Benchmark zu lesen.

Zuverlässigkeit zählt genauso. Eine Testsuite, die zufällig fehlschlägt, bringt allen bei, neu zu starten statt zu untersuchen, und sobald diese Gewohnheit besteht, schützt die Suite nichts mehr.

Versionsverwaltung und Review

Die Hosting-Plattform entscheidet mehr, als wo der Code liegt. Sie legt fest, wie Review funktioniert, was automatisch läuft, wer freigeben darf und wie die Historie ein Jahr später aussieht.

Prüfen Sie geschützte Branches, Pflichtprüfungen, Review-Zuweisung und ob Freigaben erzwungen statt nur empfohlen werden können. Prüfen Sie dann die gewöhnliche Ergonomie: wie eine große Änderung dargestellt wird, ob Kommentare einen Rebase überleben und wie leicht sich herausfinden lässt, warum eine Zeile so geschrieben wurde.

Die Migration zwischen Plattformen ist möglich und nie kostenlos. Code zieht sauber um, Issues, Pull-Request-Historie und Automatisierung kommen meist in schlechterem Zustand an, als sie losgingen.

Worauf Sie im Rest der Toolchain achten sollten

• Paket-Registries, privat für interne Bibliotheken und zwischengespeichert für öffentliche, damit ein Ausfall anderswo Ihren Build nicht stoppt.
• Umgebungen, reproduzierbar auf dem Laptop und in der Pipeline ohne eine Seite Einrichtungsanleitung.
• Geheimnisse, beim Build eingespielt und nie eingecheckt, mit Rotation ohne Ausfallzeit.
• Artefakte, versioniert und lange genug aufbewahrt, um auf die letzte Woche zurückzugehen statt nur auf gestern.
• Release-Werkzeuge, ob Feature-Flags, gestaffelte Rollouts oder ein schlichtes getaggtes Deployment.

Feature-Flags verdienen eine Anmerkung. Sie machen Releases ruhiger und werden zu technischen Schulden, wenn sie niemand entfernt, fragen Sie also, wie das Tool mit dem Abschalten umgeht und nicht mit dem Anlegen.

Preise, die Nutzung widerspiegeln und nicht die Kopfzahl

Continuous Integration wird nach Minuten, nach Parallelität oder pro Mitwirkendem abgerechnet. Schnellere Maschinen kosten pro Minute mehr und oft pro Build weniger, weshalb der brauchbare Vergleich die Kosten pro erfolgreichem Build bei der Größe Ihres Repositorys sind.

Speicher für Artefakte, Caches und Container-Images sammelt sich unbemerkt an, und die Standardwerte für die Aufbewahrung sind meist großzügig zugunsten des Anbieters. Plattformen mit Nutzerplätzen berechnen jeden mit Schreibzugriff, es lohnt sich also, ruhende Konten vierteljährlich zu prüfen.

Kostenlose Stufen sind hier ungewöhnlich gut, besonders für offene Arbeit, und ungewöhnlich leicht in einem arbeitsreichen Monat zu sprengen. Die breitere Sammlung stiller Messgrößen steht in was Preisseiten verschweigen.

Was Sie vor der Entscheidung testen sollten

Ziehen Sie ein echtes Repository mit seinen Tests und seinem langsamsten Build um und lassen Sie eine volle Woche normaler Arbeit darüber laufen.

Machen Sie dann absichtlich etwas kaputt: einen fehlschlagenden Test, ein abgelehntes Deployment, einen Rollback. Wie sich ein Tool an einem schlechten Tag verhält, ist der Teil, den Sie tatsächlich kaufen, und er taucht in der Vorführung nie auf.

Kaufreihenfolge für ein wachsendes Team

Ein Zweierteam braucht Versionsverwaltung mit Review und eine Pipeline, die Tests ausführt. Alles andere kann warten, und es früh hinzuzufügen kostet Aufmerksamkeit, die besser im Produkt aufgehoben wäre.

Bei fünf bis zehn Personen verlagert sich der Druck auf Build-Zeiten, Konsistenz der Umgebungen und eine private Registry für gemeinsamen Code. Das sind die Punkte, an denen sich Reibung im Team vervielfacht, statt eine Person zu treffen.

Darüber hinaus werden die Fragen zum Release-Management: Flags, gestaffelte Rollouts, Aufbewahrung von Artefakten und die Fähigkeit zu beantworten, was genau gerade in Produktion läuft.

Widerstehen Sie dem Kauf für das Team, das Sie erwarten. Tooling, das vor Bedarf eingeführt wird, wird zu einer Konfiguration, an deren Anlage sich niemand erinnert, und sie später zu entfernen ist schwerer, als sie hinzuzufügen gewesen wäre.