Driftrocks Reise zur kontinuierlichen Bereitstellung

Im letzten Jahr hat Driftrock eine ziemlich typische Reise hinter sich - Sie haben es vielleicht schon einmal gehört - wir sind von manuellen Implementierungen und einer Abneigung gegen die Auslieferung von Software zu automatisierten und wiederholbaren Implementierungen übergegangen, wobei der Schwerpunkt auf der Bereitstellung von Werten liegt.

Anstatt Sie mit einem weiteren Beitrag über die Vorzüge von Continuous Delivery zu langweilen, obwohl ich das gerne tun würde, werde ich versuchen, mich darauf zu konzentrieren, wie wir diesen Wandel erreicht haben. Inspiriert von dem Buch More Fearless Change von Mary Lynn Manns & Linda Rising werde ich mein Bestes tun, um mich an die Schritte zu erinnern, die wir unternommen haben, und insbesondere an die Muster, die wir weiterhin verwenden, um zu versuchen, die Verhaltensweisen des Teams zu ändern.

Das Jahr/die Jahre zurückdrehen

Zunächst etwas Kontext: Im Juni 2016 schlängelte sich eine Änderung an einer unserer Anwendungen ihren Weg in die Produktion. Es gab nur sehr wenig Wissen darüber, ob eine Änderung bereitgestellt worden war, es gab ein frustrierend populäres Verzweigungsmodell, das die kognitive Belastung dramatisch erhöhte, und Bereitstellungen wurden manuell vom Rechner eines Entwicklers über die CLI von Heroku ausgelöst.

Ein neuer Wechsel von der Entwicklung zur Produktion sah in etwa so aus:

Grün - automatisierter Schritt.
Orange - unvermeidbarer manueller Schritt oder ein manueller Schritt, den wir (noch) nicht ändern wollen.
Rot - vermeidbarer manueller Schritt.

Außerdem gab es bei diesem Bereitstellungsprozess je nach Anwendung eine Reihe von Unstimmigkeiten. Einige verfügten über keine Staging-Umgebung, diejenigen, die über eine solche verfügten, wurden vielleicht oder vielleicht auch nicht automatisch im Staging bereitgestellt, und nicht bei allen Anwendungen wurden automatische Tests auf dem Master oder anderen Zweigen durchgeführt. Kurz gesagt, es war unnötig komplex, sehr inkonsistent und wenig bis gar nicht automatisiert. Kein Wunder also, dass es dem Team an Interesse mangelte, wenn es um die Bereitstellung von Software ging.

All dies bedeutete, dass die Bereitstellung unregelmäßig und riskant war. Meistens wurde ein großer Stapel von Änderungen live geschaltet, was die Wahrscheinlichkeit erhöhte, dass etwas schief ging und manchmal die Möglichkeit eines sicheren Rollbacks ausschloss.

Baby-Schritte

Ich werde versuchen, die Schritte zu erklären, die wir unternommen haben, und die relevanten Muster, die wir verwendet haben, um das oben beschriebene Szenario zu verbessern. Ganz unten auf dieser Seite finden Sie einen Verweis auf die Muster, die in diesen Schritten erwähnt werden. Außerdem finden Sie hier alle Muster übersichtlich aufgelistet und beschrieben.

Schritt 1 - Alle einbeziehen

Unkonventionell begann es mit der Verbesserung unserer Retrospektiven. Das Team brauchte eine Plattform, um Probleme zu besprechen und Verbesserungen vorzuschlagen(alle einbeziehen). Obwohl wir ein wöchentliches Gespräch hatten, das als Retrospektive bezeichnet wurde, hatte es wenig Ähnlichkeit mit den Retrospektiven, die ich in anderen Unternehmen gesehen hatte. Ursprünglich war diese Besprechung eher ein wöchentliches Status-Update, bei dem es um die tägliche Arbeit und ihre Fortschritte ging und nicht um die Frage, wie wir unsere Arbeitsweise verbessern können. Der Vorschlag und die anschließende Demonstration eines strukturierteren Ansatzes für Retrospektiven (durch die Moderation der ersten Retros) hatte erhebliche Auswirkungen auf das Team über Continuous Delivery hinaus, aber einer der ersten Diskussionspunkte war die Art und Weise, wie wir unsere Software bereitstellen(Plant the Seeds).

Schritt 2 - Tun Sie es einfach

Da das Team noch etwas unsicher war, wie es von einer Umstellung auf Continuous Delivery profitieren könnte, war der nächste Schritt ganz einfach: Ich zeigte ihnen ein Beispiel(Just Do It). Ich stellte eine einfache HTTP-API-Anwendung mit einem Endpunkt zusammen, der "200 OK" zurückgab, und erstellte eine Bereitstellungspipeline in Snap CI. Ich habe versucht, so zu verfahren, wie wir unsere normalen Anwendungen behandeln könnten, und habe nur die unmittelbarsten Probleme in Angriff genommen(Pick Your Battles): manuelle Bereitstellungen und die Verwaltung mehrerer Zweige bei der Bereitstellung. Letzteres verringert auch den Abstand zwischen lokaler Entwicklung und Produktion. Wir haben gezeigt, dass sich unser Bereitstellungsprozess allmählich in diese Richtung entwickeln könnte:

Wie nicht anders zu erwarten (wie bei funktionierender Software), wurde dies zu einem großartigen Bezugspunkt für die Demonstration und Erläuterung des Wertes von CD und dessen Vergleich mit dem, was wir taten.

Schritt 3 - Probelauf

Mit dieser Saat, einem funktionierenden Beispiel und regelmäßigen Problemen bei der Auslieferung von Qualitätssoftware (die nur den Schweregrad hervorheben - Weckruf) nahm die Zustimmung des restlichen Teams stetig zu. Der nächste Schritt bestand darin, das Team zu verpflichten, eine oder zwei echte Anwendungen auf das neue System zu übertragen(Testlauf). Wir nahmen zwei problematische Anwendungen, um unsere Annahmen so früh wie möglich zu validieren, erstellten Bereitstellungspipelines für sie, brachten sie erfolgreich zum Einsatz und ließen die Änderung einlaufen. An diesem Punkt hatte ich glücklicherweise etwas Hilfe(Ask for Help), wodurch der Fortschritt viel schneller und die potenziellen Rückschläge leichter zu bewältigen waren.

Schritt 4 - Beharrliche PR

Ein Muster, das in dem Buch erwähnt wird, ist mir während dieses Prozesses besonders aufgefallen: Persistent PR. Wenn ich darüber nachdenke, tauchte dieses Muster an vielen Stellen auf, manchmal absichtlich, oft aber auch unabsichtlich. Hier ist eine Aufschlüsselung, wo es auftauchte:

• Wir haben unser regelmäßiges Stand-up-Meeting dahingehend geändert, dass es sich zunächst auf die Bereitstellung in der Produktion, dann auf das Staging und dann auf die aktive Entwicklung konzentriert - typischerweise bekannt als Walk the Board. Obwohl dies indirekt geschieht, erinnert es das Team regelmäßig daran, sich zuerst auf die Auslieferung der Software zu konzentrieren und darauf, wie wir die Arbeitselemente in die Produktion überführen können.
• Bei einer wöchentlichen Firmensitzung haben wir kurz demonstriert, wie wir unsere Vorgehensweise bei der Bereitstellung von Software geändert haben. Dies geschah zufällig, aber es war eine Gelegenheit, die es wert war, genutzt zu werden(Smell of Success).
• Wir begannen mit der Erfassung und Übermittlung von Metriken über die Anzahl der Einsätze in der Produktion.
• Wir haben einige Feedbackschleifen eingeführt, um den Informationsfluss rund um den Einsatz zu erleichtern:
• Slack-Benachrichtigungen - Übermittlung von Informationen über fehlgeschlagene Builds oder erfolgreiche Bereitstellungen. Das bedeutete, dass die Entwickler nicht mehr nach dem Status ihrer Änderungen suchen mussten, sondern dass er zu ihnen kam.
• Versionshinweise - wir begannen, kundenorientierte Änderungen intern anzukündigen, sobald sie eingeführt wurden. Dies trug dazu bei, das Interesse der Mitarbeiter im gesamten Unternehmen an neuen Funktionen zu wecken und diese zu diskutieren.
• Überwachung - ein Thema, das wir noch nicht ganz ausgereift haben, aber wir experimentieren weiter mit der Überwachung und besseren Möglichkeiten, Feedback von unseren Produktionssystemen zu erhalten.

Und wo stehen wir jetzt?

Wir stellen derzeit etwa 15 Mal pro Woche in die Produktion ein, was für unsere Teamgröße ein gutes, nachhaltiges Tempo ist. Am Ende haben wir etwa 30 Projekte auf Snap CI übertragen. Wir haben CD-Pipelines für eine Vielzahl von Anwendungen erstellt: Ruby-Gems, Elixir-Pakete, statische Websites, die auf AWS gehostet werden, Webanwendungen auf Heroku und andere, die in Kubernetes gehostet werden. Jeder im Team übernimmt die Verantwortung dafür, dass eine Änderung, an der er arbeitet, in der Produktion bereitgestellt wird, und arbeitet eng mit anderen Teammitgliedern zusammen, um die entsprechenden Funktionen zu testen. Wir verlassen uns zunehmend auf automatisierte Tests, Feature-Toggles und Abwärtskompatibilität - Themen, die in unseren Retrospektiven eine große Rolle gespielt haben.

Nebenbei bemerkt hat Snap CI nicht wirklich die Erwartungen erfüllt, aber auch das hat einige positive Aspekte mit sich gebracht. Nachdem wir mehrere Probleme hatten, begannen wir, in die Verwendung von Docker für CI zu investieren, um die Build-Umgebung zu isolieren und zu übernehmen. Dies hatte viele Auswirkungen, wie z. B. die Verwendung von Docker in der Entwicklung und die Umstellung auf Kubernetes. Außerdem verringerte sich dadurch unsere Abhängigkeit von dem CI/CD-Tool unserer Wahl, was schon bald sehr wichtig wurde, als Snap CI ankündigte, dass es eingestellt werden würde. Glücklicherweise sind wir jetzt in einer viel besseren Position, um zu verstehen, was wir brauchen, und so sind wir gerade dabei, auf Buildkite umzusteigen (ein anderer Artikel für ein anderes Mal!).

Ich hoffe, Sie erhalten einen Einblick in unsere weitere Umstellung auf Continuous Delivery und in die Muster, die uns dabei geholfen haben. Unser Ansatz entwickelt sich weiter, während wir lernen, und wir wissen, dass wir noch einen weiten Weg vor uns haben. All diese Bemühungen in vier Schritten zusammenzufassen, ist sicherlich zu einfach. Um dorthin zu gelangen, wo wir jetzt sind, hat selbst unser kleines Team viele Monate gebraucht. Diese Reise hat uns daran erinnert, dass eine solche Veränderung nicht über Nacht geschieht, sondern viele kleine, unauffällige Schritte in die richtige Richtung erfordert.

Andere hilfreiche Ressourcen

Linda Rising - Mythen und Muster des organisatorischen Wandels
Kontinuierliche Bereitstellung - Jez Humble & Dave Farley
Kontinuierliche Bereitstellung - Vom Tellerwäscher zum Millionär - Hibri Marzook
Trunk-basierte Entwicklung

Muster ändern Referenz

Hier ist eine Auswahl von Mustern, die ich oben erwähnt habe, in leichter Umschreibung aus dem Buch:

Baby Steps - Machen Sie einen kleinen Schritt nach dem anderen in Richtung Ihres Ziels.
Involvieren Sie jeden - Jeder sollte die Möglichkeit haben, seinen Beitrag zu leisten.
Plant the Seeds - Nutzen Sie jede Gelegenheit, um das Interesse an einer Idee zu wecken.
Just Do It - Warten Sie nicht auf den perfekten Moment, sondern machen Sie den ersten kleinen Schritt und beginnen Sie zu lernen.
Pick your Battles - Konzentrieren Sie Ihre Bemühungen auf die dringendsten Probleme.
Probelauf - Wenn es Widerstände gibt, sich auf eine Idee einzulassen, schlagen Sie ein kurzes Experiment vor.
Weckruf - Weisen Sie auf die Probleme hin, die einen Veränderungsbedarf hervorrufen.
Bitten Sie um Hilfe - Suchen Sie nach Menschen und Ressourcen, die Sie bei Ihren Bemühungen unterstützen und zur Beteiligung ermutigen.
Ausdauernde Öffentlichkeitsarbeit - Halten Sie die neue Idee vor aller Augen und werben Sie immer wieder auf verschiedene Weise für sie.
Der Geruch des Erfolgs - Wenn Ihre Bemühungen zu einem sichtbaren positiven Ergebnis führen, betrachten Sie dies als einen lehrreichen Moment.

‍