ECNS 2019: Workshop Enterprise CI/CD

Get Started. It's Free
or sign up with your email address
ECNS 2019: Workshop Enterprise CI/CD by Mind Map: ECNS 2019: Workshop Enterprise CI/CD

1. Anatomie einer CI/CD Pipeline

1.1. Phasen

1.1.1. Build

1.1.2. Package

1.1.3. Unit Test & Analysis

1.1.3.1. Unit Tests

1.1.3.2. Vulnerability Scan

1.1.3.3. Open Source License Scan

1.1.3.4. Statische Code-Analayse

1.1.3.5. Coverage Analysis

1.1.4. Auto-Deploy to Dev Stage

1.1.4.1. deploy application

1.1.4.2. provide shared services

1.1.5. Acceptance Tests & Analysis

1.1.6. Deploy to QA Stages

1.1.7. Acceptance Tests & Analysis

1.1.8. Deploy to Production Stage

1.1.8.1. deploy application

1.1.8.2. setup / transform shared services

1.1.9. Measure & Validate Deployment

1.1.9.1. measure CD key metrics

1.2. Best Practices aus den Impulsvorträgen

1.2.1. Microsoft

1.2.1.1. Feature Toggles verwenden für kontinuierlichen Flow in den Master

1.2.1.2. Deployments to Production über Rings/Stages

1.2.1.2.1. Canary for Internal Users

1.2.1.2.2. Smallest Data Center

1.2.1.2.3. Larget Data Centers

1.2.1.2.4. International Data Centers

1.2.1.3. Pull Requests als Continuous Delivery Unit

1.2.1.4. Shift Left bei Qualitätsanalysen und Testing

1.2.1.4.1. Integrationstests zu Unittests

1.2.1.4.2. Dependencies als PaaS Services

1.2.1.5. Umfassende Telemetrie-Daten für Qualitäts-Feedback zum Anwendungsverhalten

1.2.1.6. Fix / Patch Forward: kein Rollback sondern Fix durch die Pipeline pushen

1.2.2. Syncier

1.2.2.1. GitOps Deployment mit Sealed Clusters für Sicherheit und Nachvollziehbarkeit

1.2.2.2. Credentials asymmetrisch verschlüsselt und Entschlüsselung im Cluster

1.2.2.3. Operationale Metadaten zu Clustern und Namespaces

1.2.2.3.1. Kontaktdaten

1.2.2.3.2. Datenschutz-NIveau

1.2.2.3.3. Kostenstelle

1.2.2.4. Generell aktivierte Kubernetes Policies um Security und Betreibbarkeit sicherzustellen

1.2.2.5. Opt-Out von einzelnen Kubernetes Policies als Risk Acceptances

1.2.3. Telekom / QAware

1.2.3.1. Build once

1.2.3.1.1. die Deployment Unit wird nur einmal gebaut und wird dann nicht mehr angefasst

1.2.3.1.2. der Rest ist Konfiguration u.A. auch per Feature Toggle

1.2.3.2. Ops repository = mono repository

1.2.3.3. Trennung von CloudOps (Plattform) und DevOps (Anwendungen)

1.2.3.4. DeploymentSet als Continuous Delivery Unit über mehrere Deployment Units hinweg

1.2.3.5. Manuelle Stage-Promotion auf informierter Basis (Analyseergebnisse, Konfiguration, ...)

2. Typische CI/CD Probleme und Lösungen

2.1. Best Practices aus den Breakout Sessions

2.1.1. GitOps

2.1.1.1. Vorteile

2.1.1.1.1. ConfigManagement für Ops-as-Code

2.1.1.1.2. Nachvollziehbarkeit

2.1.1.1.3. Single Source of Truth

2.1.1.1.4. Traceability von Changes

2.1.1.1.5. Authentifizierung und Autorisierung von Benutzern

2.1.1.1.6. gewohntes git Tooling

2.1.1.1.7. Kontrolle über Changes über etablierte Dev-Workflows (aber neu für Ops)

2.1.1.1.8. keiner braucht Zugriff auf Cluster. Menschen werden von Deployment ferngehalten

2.1.1.2. Offene Fragen

2.1.1.2.1. Validierung von Manifesten

2.1.1.2.2. Berücksichtigung von Ausführungsreihenfolgen

2.1.1.2.3. in welchem Umfang sind manuelle Zugriffe z.B. per read-only kubectl oder sogar verändernd bei high-prio Hotfixes erlaubt?

2.1.1.2.4. Trennung von Infrastruktur- und Applikationscode

2.1.1.2.5. Mono vs. verteiltes Repo für Infrastructure-as-Code

2.1.1.2.6. Einheitlicher Mechanismus für Credential Management und Verteilung

2.1.2. Service-Abhängigkeiten

2.1.2.1. Was?

2.1.2.1.1. Drittsysteme

2.1.2.1.2. Datenbanken

2.1.2.2. Welche Umgebungen?

2.1.2.2.1. DEV Stages

2.1.2.2.2. QA Stages

2.1.2.2.3. PROD

2.1.2.3. Best Practices

2.1.2.3.1. Stages per Infrastructure-as-Code automatisiert ausrollen können

2.1.2.3.2. Eine Umgebung pro Entwickler in DEV zum Start und später ggF. konsolidieren

2.1.2.3.3. DEV eines attached servcies Instanz schnell aufsetzbar machen

2.1.2.3.4. kleine Inkremente bei Daten- und Schemamigrationen

2.1.2.3.5. mehrere API-Versionen aus Kompatibilitätsgründen gleichzeitig anbieten

2.1.2.3.6. wenn es bei Legacy-Anwendungen zu kompliziert wird: Refactoring statt komplexe CI/CD

2.1.3. Regulatorik

2.1.3.1. Sicherheit

2.1.3.1.1. Mantra: überwache, welche Exploits in Produktion sind und reagiere schnell

2.1.3.1.2. Werkzeuge

2.1.3.1.3. Teams sind verantwortlich die Vulnerabilities zu fixen

2.1.3.1.4. für Images

2.1.3.2. Open Source Compliance

2.1.3.2.1. kein Open Source Werkzeug dafür ausreichend -> kommerzielles Tool

2.1.3.2.2. scannt bei jedem PR, ob ein copyleft Effekt eintritt

2.1.3.3. Nachvollziehbarkeit

2.1.3.3.1. GitOps Ansatz und Kubernetes Audit Logs

2.1.3.3.2. Problem: dauerhaft stabil identifizierbares Artefakt

2.1.3.3.3. 4-Augen-Prinzip durch PRs

2.1.4. Legacy-Anwendungen

2.1.4.1. Standard-Probleme

2.1.4.1.1. Ansprechpartner sind nicht mehr da

2.1.4.1.2. keine Automatisierung

2.1.4.1.3. Legacy-Prozesse beim Deployment und der Freigabe

2.1.4.2. Best Practices

2.1.4.2.1. Reverse Engineering

2.1.4.2.2. Sarkophag an toten Stellen der Anwendung

2.1.4.2.3. lebendigen Teil rausschneiden und modern machen

2.1.4.2.4. Industrialisierung der Migration z.B. mit vorgefertigten Werkzeugen

3. Neuralgische Punkte & zentrale Fragestellungen

3.1. (1) Kontinuierliches und automatisches Feedback

3.1.1. Wie bekommt man einen roten Status schnell wieder grün?

3.1.2. Abbildung von Quality Gates und Security Checks

3.1.3. Test Automation in CI/CD

3.2. (2) der Mensch im CI/CD Prozess

3.3. (3) Wie viel Freiheiten lässt man den Entwicklern vs, wie viel standardisiert man zur Governance?

3.4. (4) Effiziente Pipelines für 100 Deployments pro Tag

3.5. (5) Erfahrungen mit GitOps

3.6. (6) Wie geht man mit regulatorischen Anforderungen in einer CI/CD Pipeline um?

3.7. (7) Wie bekommt man Legacy-Anwendungen auf eine CI/CD Plattform?

3.8. (8) Wie kommt man von einer kleinen Umgebung hin zu einer Enterprise Umgebung?

3.8.1. Einbettung von modernen CI/CD Workflows in klassische Unternehmensprozesse

3.9. (9) Umgang mit Service Abhängigkeiten

3.10. (10) Security & Compliance Scans & Fixes / Patches

4. Top-Takeaways

4.1. insbesondere Organisations-, Menschen- und Prozessfrage

4.2. keiner hat die Silver Bullet

4.3. man sollte mehr reden über die gemeinsamen Probleme

5. Slides

5.1. Rahmenvortrag

5.2. Josef Fuchshuber: Promotor