Zusammenfassung
Mittlerweile wird die Infrastruktur immer mehr mithilfe von Code (Provisionierungsskripte, Dockerfiles, (Shell-) Skripte etc. ) beschrieben und automatisiert. Klassische Betriebsabteilungen mutieren auf einen Schlag zu Entwicklungsabteilungen und müssen programmieren, um an ihre Infrastruktur zu kommen.
Doch ist auch allen Beteiligten klar, dass sie zu professionellen Programmierern geworden sind? Wenn man sich Entwicklungsprozess und Code anschaut, erinnern beide stark an die Fricklermentalität der 2000er: Juhuu, es läuft irgendwie, kein VCS, keine Qualitätssicherung mit Test oder Review. Wenn es sich stark nach “normaler” Softwareentwicklung anfühlt, warum dann auch nicht die Best Practices und Lessons Learned der letzten 30 Jahren auf Infrastructure as Code adaptieren und somit die Qualität erhöhen? Müssen die frisch gebackenen OpsDevs die alten Fehler der Devs wiederholen? Kann man Infrastruktur-Code vielleicht sogar testgetrieben entwickeln?
Dieser Vortrag lädt zu einer Zeitreise ein, welche Best Practices - organisatorisch wie auch handwerklich - in der Softwareentwicklung zur einer höheren Qualtität geführt haben und wie diese Erkenntisse helfen können, die Entwicklung von Infrastruktur-Code qualitativ hochwertiger zu machen
Blog Post “#FlattenTheCurve: Another QS Barcamp Perspective”
#qscamp keynote war toll, und der anschließende open space war eine echte Ergänzung 😂 pic.twitter.com/QBMwgtWWQZ
— Ursula Beiersdorf (@Testhexe) September 5, 2020
Es war sehr interessant und gut zu sehen, das wir bei der Transformation beim Kunden in die richtige Richtung gehen.
— MaikNog (@MaikNog) September 5, 2020
Vielen Dank für den interessanten Vortrag! Hoffentlich haben auch OPs Vertreter die Message mitgenommen #qscamp
— QS-Barcamp (@QS_Barcamp) September 5, 2020
#qscamp #FlattenTheCurve: Keynote Takeaway: Die Lernkurve von OPS beim Programmieren wird schneller flach durch Pairing von DEV und OPS! @SandraParsick
— Ursula Beiersdorf (@Testhexe) September 5, 2020
