Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOps - Mehr Geschwindigkeit auf der Schiene

DevOps - Mehr Geschwindigkeit auf der Schiene

In diesem Vortrag erfahren Sie, warum sich der erste Ansatz einer zentralen CI/CD-Installation für alle Teams als problematisch erwies und durch dezentrale Pipelines ersetzt wurde. Danach lernen Sie die Tücken unserer Einführung einer eingekauften API-Management-Lösung kennen, und wieso sich der Kauf von großer On-Premise-Software nur schwer mit den agilen Prinzipien vereinbaren lässt. Der Zuhörer lernt zudem, wie wir im Team mit polyglotter Softwareentwicklung zu kämpfen haben und wie wir permanent gegen Wissensinseln ankämpfen. Zuletzt gehe ich darauf ein, wie wir mit umfassender Architekturdokumentation gestartet und gescheitert sind. Unser neuer Ansatz ist eine leichtgewichtige dezentrale Dokumentation mit AsciiDoc und ein im Team abgestimmter Toolstack, der auch vom Zuhörer adaptiert werden kann. Am Ende der Reise wird der Zuhörer einige Methoden und Tools kennen gelernt haben, um in einem Kontext zu überleben, der an vielen Stellen noch von klassischen Prozessen dominiert wird. Aber eines ist klar: Der Weg Richtung DevOps geht nicht plötzlich, es ist eine Reise mit Umwegen und Hindernissen. Die Reise ist es aber auf jeden Fall Wert!

Carsten Hoffmann

December 07, 2020
Tweet

More Decks by Carsten Hoffmann

Other Decks in Programming

Transcript

  1. Ein Reisebericht Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB 5 1.

    Kontext 2. Polyglotte Softwareentwicklung 3. CI/CD Pipelines 4. COTSS 5. Dezentrale Dokumentation
  2. Unsere Mission als Plattform Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB

    Innovationsgeschwindigkeit erhöhen API Ökosystem betreiben Wissensaufbau für Developer im Bereich Cloud/K8S 6
  3. You build it, you run it, you are responsible Lilienthal,

    Carola. Langlebige Software-Architekturen: Technische Schulden analysieren, begrenzen und abbauen. dpunkt. verlag, 2019. Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB 11 Create Refactor Abandon Replace
  4. 17 Beispiel für Team-Tool-Entscheidung -> Diagramme ü Speichern aller Diagramme

    als .drawio.png in Git Repositories ü Quelldatei=Zielformat ü Zugriff für jeden auf jedem Endgerät Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB formerly known as draw.io
  5. 18 Beispiel für Einzel-Tool-Entscheidungen -> Code Dev Tools q Keine

    Projektdateien in Git q .editorconfig (https://editorconfig.org/) q Projekt muss ohne IDE ausführbar sein Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB
  6. Beispiel einer zentralen Pipeline healthPath: '/actuator/health' displayName: 'Spring Boot Template’

    srcType: Maven testing: acceptance: command: 'node /opt/app/src/runner application/xml `pwd`/test-reports/test-results.xml' image: services/bh-images/newman-sidecar-image:latest environment: COLLECTION_FILE: src/test/resources/SpringBoot-AcceptanceTest.postman_collection.json apis: - name: ${APPLICATION_NAME} uris: /${NAMESPACE_NAME}/${APPLICATION_NAME} Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB 20
  7. 22 pipeship bringt: Workflow Danke an Thomas Kappatsch & Nicolas

    Byl für diese Folien Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB @mcpipeface
  8. Beispiel einer dezentralen Pipeline --- include: - https://.../rgbs-generic-stage-dev-local/release/0.71.0-20201029160137-b802e13-pipeship-pipeline.yaml - https://.../business-hub-generic-prod-local/bizhub-pipeline/2.0.26-20201116165355-f538ec3-bizhub-

    pipeline.yml variables: APPLICATION_URL_SUFFIX_TEST: ".berlin.dbcs.db.de" APPLICATION_URL_SUFFIX_PROD: ".berlin.dbcs.db.de" MAVEN_SETTINGS_PATH: "./pipeship/.m2/settings.xml" # Run Postman/newman acceptance tests automatic_test_run: tags: - test variables: STAGE: at image: name: postman/newman:4.5-alpine entrypoint: [""] script: - 'newman run --insecure --env-var "baseUrl=${GATEWAY_URL}/${CI_PROJECT_NAME}/${STAGE}/${CI_COMMIT_REF_NAME}/spring-boot- template/v1" src/test/resources/SpringBoot-AcceptanceTest.postman_collection.json' Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB 23
  9. 26 Einführung von COTSS v Tätigkeiten dauern seit ca. 27

    Monaten an (and counting) v Bisher kein produktiver Nutzen v Qualitätsprobleme v Microservicearchitektur die durch komplizierte Automatisierung gemanaged wird v DB hat den Hersteller dazu “überredet” OpenShift zu unterstützen v Mehrfach Probleme entdeckt, die nur in OpenShift auftreten, da der Hersteller den Support zwar zugesichert hat, aber nicht von Anfang an geplant hatte v Abbruch der Installation auf OpenShift à Entscheidung für AWS EKS v Viele “Monsterstories”, da das Zerteilen der technischen Integrationsaufgaben in kleinere Stories häufig nicht sinnvoll möglich war. -> Wochenlange Laufzeit. v Fehler die nicht nachvollziehbar waren, nur bei uns auftraten, und meistens nur in Produktion. v Ohne Konfigurationsänderungen unsererseits Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB
  10. 31 Tool Tips Artillery – Simple Loadtesting Diagrams.net – Versionierbare

    Diagramme für jeden (formerly known as draw.io) Mocha, Chai, Sinon – Unser Javascript UnitTestStack Spock – Java Tests mit Groovy renovatebot – Automatische Dependency Updates per MergeRequest Zalando API Guidelines – Beispiel für API Guidelines als Startpunkt docToolchain – docs as code als fertige Toolchain Postman/Newman – REST-Client: exploratives und automatisiertes Testen excote – npm package für permanentes Testen (github.com/dbsystel/excote) k9s – Kubernetes CLI-UI mob – Simple CLI für remote mob programming (@simonharrer) Carsten Hoffmann | @Morl99 @DBSystel @DevOps_DB