Continuous Delivery

Wer hat's erfunden?

Deine DS-Projekte bestehen aus Jupyter-Notebooks, die du am Ende des Projektes dem Kunden per Email sendest.

Du nutzt Technologien wie R-Shiny oder Plotly Dash um Prototypen zu erstellen.
Deine Modelle werden als MicroService (REST-API) in einer größeren App eingebunden.

Jede Code-Änderung wird automatisch in Produktion deployed.
- Das ist ja Wahnsinn! Da geht sofort alles kaputt!
Jede Code-Änderung durchläuft natürlich vor dem Deployment eine Batterie von automatischen Tests und nur wenn diese erfolgreich durchlaufen werden, wird deployed.
- Schön, aber was soll das bringen?

Mehr Spass am programmieren, durch sofortiges Feedback
Statt aufwendiger manueller Rollbacks bei Bugs wird einfach schnell eine neue Version deployed (Roll-Forward)
Mehr Transparenz (Wer hat wann was kaputt gemacht?)
Agilere Entwicklung --> Kanban statt Scrum
Höhere Codequalität durch erzwungenermaßen testbaren Code
Mehr Stabilität und Reproduzierbarkeit durch die automatisierten Tests
Statt stressiger Nachtschichten kurz vor der Deadline werden Releases langweilige Routine

Eine automatische Deployment-Pipeline
- z.B. jenkins, concourse-ci, drone.io
- Google Cloud Build, GitLab CI

Frage den DevOp deines Vertrauens!

Nur einen Master-Branch im Repository
Tests schreiben
App-Konfiguration wird mit der App im gleichen Repo abgelegt und versioniert.
Die Konfiguration wird zusammen mit der App installiert.
Es gibt eine Konfiguration pro Umgebung.
Statt Feature branches besser Feature Toggles
- Feature toggle: unfertige Features werden per Configurations-Flag abschaltbar gemacht
Datenbank-Migrations-Skripts schreiben für DB-Updates ohne Downtime