Continuous Delivery

für

Datenwissenschaftler

Wer hat's erfunden?

Nein

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

Ja

  • 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.

 

Brauche ich das als

DATA Scientist?

Was Ist die IDEE

  • 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?

Was bringt es?

  • 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

Was braucht man?

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

Frage den DevOp deines Vertrauens!

WORAUF soll der Data Scientist achten?

  • 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

MAcht das wirklich jemand?

Und Wohin mit den Daten?

 

ENDE