2. DevOps – Was ist das?
„DevOps beschreibt einen kulturellen Wandel in
Organisationen, der sich auf das Zusammenspiel
von Personen, Prozessen und Werkzeugen
fokussiert mit dem Ziel, den
Anwendungslebenszyklus […] schneller und
vorhersehbarer zu gestalten.“
https://mva.microsoft.com/training-topics/devops-ger
12. Vorgehen
„Even with the best tools, DevOps is just another
buzzword if you don't have the right culture.“
Martin Fowler
http://martinfowler.com/bliki/DevOpsCulture.html
Begrüßung
Besuch des webMontag als Blick über den Tellerrand
Wer ist Dev / wer ist Op?
Wer arbeitet in einem Unternehmen wo es DevOps gibt, bzw Bestrebungen dahin?
Vorstellung und Motivation „DevOps“ bzw. Besuch „DevOps Con 2015“
Überblick DevOps, Tools, Orga
Begriff als solcher seit ~2009 im Umlauf
Thematik vorher aber schon präsent, nur nicht so fokussiert verfolgt und „benannt“
Vergleich „Agile“ vs „Extreme Programming“
Geboren aus dem Bedarf, in einem gesättigten Markt schnell Lösungen liefern zu können und die Feedback-Loops kurz zu halten
Software wird „über die Mauer“ geworfen
Kommunikation über Ticket
Unterschiedliche Anforderungen
Dev/Fachabteilungen: Schnell liefern, Feedback einholen, Wert generieren
Ops: Stabilität, Kontrolle, Steuerung
Keiner weiß so richtig was der andere macht
Wir haben natürlich nicht nur im Pool rumgelümmelt, sondern auch ein bisschen was mitgebracht und erarbeitet
Konferenz 3 Tage, einer davon Workshop
Hochwertige Talks
Organisator hat Erfahrung (der gleiche wie bei der BASTA!)
Zweite DevOpsCon, die erste war im Sommer in Berlin. Wechselnder Turnus geplant
Tools nicht nur als „konkrete Bibliothek“ oder „Programm“ sehen, sondern als Ansatz, wie man (Denk-)Werkzeuge einsetzen kann
Containerisierung von Infrastruktur
Automatisierte Buildprozesse
Zentrales Logging
Microservices(Runterbrechen monolithischer Applikationen in kleinere Teile zur besseren Wartbarkeit und einfacherem Deployment)
Docker für Container
Jenkins oder Teamcity als Buildserver
OWASP ZAP für automatischer Security-Tests im Buildprozess(ISO!)
ELK-Stack(ElasticSearch, Logstash, Kibana) für Logging und Monitoring(inkl. Darstellung)
Auch für Microsoft-Umgebungen gibt es ein Tooling. MS einer der größten Docker-Unterstützer (Server, Azure, Windows)
Auch VMWare ist ein großer Unterstützer von Docker
Immer ein lauffähiges und lieferbares Produktinkrement
(Automatische) Tests und Abnahme von Entwicklungen
Sich in eine Lage versetzen, in der man schnell lauffähige Produkte liefern kann
Shipbare Software entwickeln
Continuous integration -> Software wird gefertigt z.B. ein nightly Build
Continuous delivery -> „every commit can be deployed to production“
Continuous deployment -> „every commit is deployed to production“
Es geht um Grundbedürfnisse
Verständnis von- und füreinander in allen Aspekten der Produktentwicklung
Von Anforderungsmanagement über Entwicklung, Betrieb, Vertrieb, Marketing können alle von kürzeren Lieferzyklen profitieren
Auch das große Thema „Security“ lässt sich zu Teilen sogar automatisiert in „DevOps“ umsetzen(Siehe z.B. OWASP ZAP)
Überschaubare, schlagkräftige Teams, in denen es Ansprechpartner für alle Facetten der Entwicklung von Features gibt
Anforderung, Technisches, Betrieb, Geschäftswert
Dabei ist es egal, welches „Projektmanagement-Framework“ man benutzt. Es geht um einen Wandel im Denken, der sich implizit auf die Organisationsstruktur auswirkt
Kürzere Feedback-Loops und Platzierung näher am Kunden... „Was will der Kunde eigentlich?“
Verhältnismäßigkeit sehen
Langsam anfangen, da wo es Sinn ergibt
Tooling nicht übertreiben. Tools einsetzen, wenn es „weh tut“ (Wix.com mit 150 Microservices denkt JETZT darüber nach, Service Discovery statt DNS-Einträgen für ihre Services einzusetzen)
Empirisches, wissenschaftliches Vorgehen
Plan, Do, Check, Act(PDCA nach William Edwards Deming)
Wir gehen davon aus, dass jeder Mitarbeiter jeder Zeit nach bestem Wissen und Gewissen handelt, und die für seine konkrete persönliche Situation bestmögliche Leistung abliefert
Einzelleistungen sind irrelevant. Was zählt, ist das Gesamtergebnis.
Es gibt keine „Schuldigen“, wenn man alles als Experiment betrachtet. Ein Experiment funktioniert entweder, oder es schlägt fehl.
„No asshole“-culture, „Punishless Failure“
Es gibt keine „Best Practices“. Jedes Unternehmen ist anders. Was bei Netflix oder Facebook funktioniert, wird höchstwahrscheinlich nicht in jedem Unternehmen funktionieren.
Projekte suchen, von denen man weiß, dass sie in DevOps-ähnlichen Ansätzen durchgeführt werden
CrossfunktionaleTeams
Beispiel: Familiäres Unternehmen, 30 Jahre am Markt, konnte den Kunden immer hinwerfen Friss oder Stirb... Geänderte Anforderungen, wie gehe ich vor?
DevOps ist nicht nur etwas für Projekte, sondern auch für Prozesse in bereits bestehenden Tools und Anwendungen, die noch gewartet werden
In komplexen Umfeldern mit unklaren Anforderungen lohnen sich Ansätze in Richtung DevOps und Continuous Deployment, um schneller Feedback zu erhalten und sich mit seiner Lösung langsam an das „Optimum“ heranzutasten
![DevOps – Was ist das?
„DevOps beschreibt einen kulturellen Wandel in
Organisationen, der sich auf das Zusammenspiel
von Personen, Prozessen und Werkzeugen
fokussiert mit dem Ziel, den
Anwendungslebenszyklus […] schneller und
vorhersehbarer zu gestalten.“
https://mva.microsoft.com/training-topics/devops-ger](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)