Kaps - Continuous Deployment Roadmap
•
0 gefällt mir•194 views
Requirements for Continuous Deployment in larger Enterprises
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Kaps - Continuous Deployment Roadmap
Ähnlich wie Kaps - Continuous Deployment Roadmap (20)
Kaps - Continuous Deployment Roadmap
- 1. Continuous Deployment Roadmap Requirements for CD in larger Enterprises
- 2. Stephan Kaps Leiter Softwareentwicklung Bundesamt für Soziale Sicherung Gründer Java User Group Bonn Java Entwickler & Architekt seit 2002 Weitere Schwerpunkte: ✘ Softwareentwicklungsprozesse ✘ BizDevSecOps ✘ OpenSource ✘ Speaker & Autor @kitenco1
- 4. Release Anti-Pattern ✘ Software manuell deployen ✘ In der Staging- oder Test-Umgebung wird erst nach Ende der Entwicklung deployed ✘ Manuelle Konfiguration der Produktionsumgebung @kitenco1
- 5. Geht es besser? Releases sollen "langweilig" werden. Dafür sind gewisse Prinzipien, Praktiken und Techniken notwendig. Releases sollten mit geringem Risiko, häufig, verlässlich, günstig und rapide erfolgen können. @kitenco1
- 6. Automatic deployment in production @kitenco1
- 7. Shared Responsibilities Availability, Security and Quality & @kitenco1
- 11. Schlüsselkompetenzen für performante Softwarebereitstellung ✘ Führung ✘ Werkzeuge ✘ Automatisierung ✘ Kultur ständigen Lernens und ständiger Verbesserung @kitenco1
- 13. Vorteile ✘ Build & Checks bei jedem Commit ✘ Jederzeit auslieferbare Software ✘ Fail fast / Fast Feedback ✘ Gestiegene Qualität & Vertrauen @kitenco1
- 14. Anforderungen an CI ✘ Version Control ✘ CI-Server ✘ Artifact Repository ✘ Automated Tests ✘ Security Testing (SAST & DAST) ✘ Trunk-Based-Development ✘ Team Agreement @kitenco1
- 15. Notwendige Praktiken ✘ Nicht einchecken in einen Broken Build ✘ Alle commit Tests vor dem Einchecken ausführen, entweder lokal oder durch den CI-Server (erst den aktuellen Stand auschecken und Build und Tests durchlaufen) ✘ Bevor man weitermacht, auf den fertigen erfolgreichen Commit Test warten ✘ Niemals nach Hause gehen, wenn der Build broken ist ✘ Immer vorbereitet sein, auf die letzte Version zurückzugehen ✘ Time-Box-Fixing (10 Minuten?) Versuch das Problem zu lösen, sonst wird auf die letzte Version zurückgegangen ✘ Fehlgeschlagene Tests nicht auskommentieren ✘ Verantwortung für fehlgeschlagene Builds und Tests übernehmen, d.h. auch Tests anderer anpassen, wenn sie durch die eigene Änderung nicht mehr funktionieren ✘ Test-driven Development @kitenco1
- 16. Empfohlene Praktiken ✘ Extreme Programming Development Practices ✘ Den Build fehlschlagen lassen ○ bei Architektur Verstößen ○ Bei zu langsamen Tests ○ Bei Code Style Verstößen @kitenco1
- 18. Vorteile ✘ Release faster and more often ✘ Minimize risk ✘ Fast Feedback ✘ Increase trust in deployment process ✘ Faster project setup ✘ Increase transparency @kitenco1
- 19. Anforderungen für CD ✘ wie für CI ✘ Entwickle (gescriptete) Delivery Pipelines ✘ Automatisierte Datenbank Änderungen ✘ Unified Deployment ✘ Evtl. organisatorische oder kulturelle Herausforderungen @kitenco1
- 21. Wann nehme ich was? FLYWAY - gut für interne Anwendungen mit gleicher DB Technologie LIQUIBASE - gut für Produkte, die beim Kunden auf unterschiedlichen Datenbanken betrieben werden können müssen @kitenco1
- 24. @kitenco1
- 25. @kitenco1 Automated Scripted Pipelines jedes Projekt mit bestimmten TAG
- 26. Continuous-Delivery-Kompetenzen 1. Verwenden Sie eine Versionsverwaltung für alle Produktionsartefakte 2. Automatisieren Sie Ihren Deployment-Prozess 3. Implementieren Sie Continuous Integration 4. Nutzen Sie trunk-basierte Entwicklungsmethoden 5. Implementieren Sie Testautomatisierung 6. Unterstützen Sie Testdatenmanagement 7. Integration von Security in den Softwareentwicklungsprozess (DevSecOps) 8. Continuous Delivery implementieren @kitenco1
- 27. But what about long running changes or refactorings? @kitenco1
- 29. @kitenco1
- 30. @kitenco1
- 31. @kitenco1
- 32. @kitenco1
- 33. Vorteile ✘ eine Migration kann angehalten werden, aber der Build bleibt grün ✘ beide Implementierungen können parallel existieren und können somit getestet werden @kitenco1
- 36. @kitenco1
- 37. @kitenco1
- 38. @kitenco1
- 42. @kitenco1
- 44. @kitenco1
- 45. @kitenco1
- 46. @kitenco1
- 47. @kitenco1
- 48. 5. Security & Compliance @kitenco1
- 49. Container Security Risks ✘ foreign containers from unknown sources ✘ manipulated Images (maybe with Malware) ✘ containers with known vulnerabilities @kitenco1
- 50. Container Security Guide ✘ use only official or signed images ✘ implement Content Trust ✘ do Vulnerability Scans ✘ use a trusted Container Registry (Harbor Project) ✘ follow Container Security Verification Standard @kitenco1
- 52. @kitenco1
- 53. @kitenco1
- 54. @kitenco1
- 55. @kitenco1
- 57. “Stellen Sie sicher, dass Geheimnisse (z. B. kryptografische Schlüssel und Kennwörter) sicher mit einer Secret Management Lösung verwendet werden, anstatt z.B. unter Verwendung von Umgebungsvariablen einem Container bereitgestellt werden. @kitenco1
- 58. Container Security Verification Standard (CSVS) - OWASP OpenSource Projekt - Als ausführliche Anleitung zur Sicherheitsarchitektur - Als Ersatz für handelsübliche Checklisten - Für Sicherheitstrainings - drei Stufen, die man als Beginner, Fortgeschritten und Expertenlevel beschreiben könnte - Insgesamt 106 Empfehlungen, unterteilt in 12 Kategorien @kitenco1
- 61. Availability Quality & Speed Security Shared Responsibilities@kitenco1
- 62. Continuous Integration @kitenco1 Continuous Delivery Feature Toggles branch by Abstraction Secrets Management Zero Downtime Container Security Service Mesh
- 63. I wish you every success on this exciting journey @kitenco1
- 64. Vielen Dank! Kontakt: Stephan Kaps info@kitenco.de www.kitenco.de @kitenco1 https://www.xing.com/profile/Stephan_Kaps2 https://www.linkedin.com/in/stephan-kaps-b246b0ab/ http://de.slideshare.net/kitenco Quelle aller Hintergrundgrafiken ist https://www.pixabay.com https://open.spotify.com/album/2tHppzsY0ZPb57Xa7PRkEX