Meetings durch langsame Deployments (2015)

Langsame Deployments verursachen Meetings

• Software-Design ist ein Training für zwischenmenschliche Beziehungen. Dasselbe gilt für andere Fähigkeiten im Software Engineering.
• Die Beschwerde eines Engineers, "Es gibt zu viele Meetings, um überhaupt deployen zu können", kann durch die Begrenzung der Deployment-Kapazität entstehen.
• Chuck Rossi hat bei Facebook beobachtet, dass die Anzahl der Änderungen, die in einem einzelnen Deployment verarbeitet werden kann, fest ist. Wenn mehr Änderungen erforderlich sind, braucht man mehr Deployments.
• Facebook hat die Deployment-Geschwindigkeit in den letzten fünf Jahren von wöchentlich auf täglich und dann auf drei Mal täglich erhöht; den Release-Zyklus der Mobile-App hat es von sechs auf vier und dann auf zwei Wochen reduziert.
• "Änderungen pro Deployment" ist eine unelastische Kennzahl. Sie lässt sich verbessern, aber das braucht Zeit. Wird die aktuelle Schwelle überschritten, muss die Änderungszahl sinken.
• Steigt der organisatorische Overhead, beginnt eine positive Feedback-Schleife: geringere Arbeitslast -> höherer Druck -> mehr Fehler -> weniger Änderungen pro Deployment -> mehr Overhead -> geringere Arbeitslast.
• Um mehr Änderungen abzuarbeiten, muss die Deployment-Kapazität erhöht werden. Das geht durch häufigere Deployments oder durch mehr Änderungen pro Deployment.
• Der Versuch, Overhead zu reduzieren, kann schließlich in Meetings münden. Das verhindert, dass zu viel Code auf einmal deployed wird.

Software-Design: Tidy First?

• Software-Design ist ein Training für zwischenmenschliche Beziehungen. Die Verbesserung von technischen Fähigkeiten ist eine Möglichkeit, Beziehungen zu verbessern.

[roxie]

Das ist eine gute Meinung.

[GN⁺]

Hacker News Kommentar

• Es ist wichtig, das Deployment-Risiko zu verringern, indem Tests und organisatorische Eigenschaften verbessert werden, aber das ist nicht der einzige Ansatz

  • Es ist effektiver, die Anzahl der Änderungen pro Deployment zu reduzieren
  • Häufige kleine Deployments liefern schneller Mehrwert und führen zu kleineren Fehlern
  • In Kombination mit Canary-Deployments und schrittweisen Rollouts ist eine Bereitstellung kein großes Risiko mehr
  • DORA-Studien sowie Accelerate, The Phoenix Project und The Goal unterstützen diesen Ansatz

• Es wird versucht, das Konzept der „Software Literacy“ zu erklären

  • Das bedeutet die Fähigkeit, dass ein Unternehmen mit Code betrieben werden kann
  • Wenn nicht alle Entscheidungsträger auf Code achten, fehlt es an Software Literacy
  • Ein Unternehmen muss mit neuen Konzepten betrieben werden können

• Wegen der langen Testzeiten in CI-Pipelines wurde entschieden, sich auf die Wiederherstellung zu konzentrieren

  • Die Tests wurden vereinfacht, der Fokus auf Recovery gelegt und als Bereitstellungsstrategie wurde Canary eingesetzt
  • Dieser Ansatz war eine frische Erfahrung

• Organisationen können die Verbesserung von Deployments behindern

  • Gegen Bürokratie anzukämpfen ist in den meisten Organisationen unmöglich
  • Langsame Deployments sind ein Problem, aber nicht das einzige Problem

• Tests werden aufgrund der Angst vor großen Veränderungen häufiger

  • Es besteht die Tendenz, dass Meetings zum Ziel werden
  • Es wird Rat benötigt, wie man Nicht-Techniker durch technische Veränderungen führt

• Frage, warum CloudFormation langsam ist

• Mikroservices ermöglichen es, die Deployment-Frequenz horizontal zu skalieren

• Software-Performance, also menschliche Performance, ist wichtig

  • Für schnelle Iteration und reduzierte Risiken ist schnelle Testautomatisierung notwendig

• Schnelle Deployments lösen Incident-Response-Meetings aus