Geekstammtisch

Geekstammtisch

Das heimelige Nerdgespräch über Webentwicklung, Ruby/Rails und mehr

GST033 - (Code)ship all the things!

Audio herunterladen: MP3 | AAC | OGG | OPUS

Unser Gast (00:00:00)

  • Florian Motlik
  • CTO und Co-Founder von https://codeship.io
  • Codeship ist ein Continuous Integration/Deployment Service
  • Ist 2011 als Neben-dem-Studium-Projekt gestartet
  • 2012 dann die Entscheidung das ganze Vollzeit zu verfolgen: Studium hinschmeißen und alle ziehen nach Berlin
  • Nach Berlin dann 2013 nach Boston
  • Hauptsitz in Boston und ein Büro Wien
  • Wachsen erstmal "nur" vor Ort in Boston/Wien, Remote erst später; Ziel: gesunder Wachstum

Usability ist wichtig (00:05:45)

  • Usability war von Anfang im Fokus
  • Geführter Einstieg in das Produkt und Features
  • Noch vor der Anmeldung eines Nutzers sollen Screencasts und Blogposts Interessenten in die Thematik einführen
  • Bei Anmeldung weiß man dann schon im Grunde worum es geht und kann schneller starten

Tour durch Codeship.io (00:10:46)

  • Erster Schritt: Anmeldung über GitHub (https://github.com/) oder Bitbucket (https://bitbucket.org/)
  • Anschließend die Wahl des Repositories
  • Einrichtung der Test-Befehle, dazu gibt Templates für die unterschiedlichsten Sprachen und Umgebungen
  • Solange der Exit-Status eines Befehls 0 ist wird der nächste Schritt ausgeführt
  • Nach dem Testing kommt das Deployment
  • Auch hier lässt sich aus fertigen Anbindungen wählen, oder ein eigenes Skript wird verwendet
  • Das Deployment ist dabei eher als Pipeline zu verstehen:
    • Deploye erst auf Staging
    • Lasse dann gegen Staging einige Tests laufen
    • Deploye dann auf Produktion
    • Prüfe auch hier mit einem Skript
  • Am Ende des Tages kann Ablauf beliebig komplex oder sehr einfach sein, was immer gebraucht wird
  • Genauso wird im übrigen auch Codeship selbst getestet und deployed
    • "Eat your own dog food" ist vor allem für Developer-Produkte extrem wichtig

Infrastruktur (00:14:10)

  • Website läuft auf Heroku (https://www.heroku.com/home)
  • Sidekiq (http://sidekiq.org/) als Worker Queue mit externem Redis (https://openredis.com/)
  • Die interessanten Dinge passieren bei AWS (https://aws.amazon.com/): Die Ausführung der Jobs
    • Zu AWS ist man von Hetzner über Rackspace gekommen. Die Erklärung warum haben wir dann später leider vergessen zu erwähnen :/
  • AWS-Setup
    • Eigenes Auto-Scaling: Mehr Builds -> mehr Server
    • Die größten Compute-Instanzen (c3.8xlarge) als Basis, Unterteilung mit LXC (https://linuxcontainers.org/)
    • Ein Container mit einem vollständigen Ubuntu inkl. aller möglichen Abhängigkeiten
    • Learning 1: Container eignen sich besser als dedizierte kleine Maschinen, weil mehr Speicher und CPU
    • Learning 2: Einfach alles hochfahren treibt den Speicherverbrauch hoch, macht aber das Handling sehr viel leichter
  • Jeder Push auf das Repo erzeugt eine neue virtuelle Maschine auf der man im Grunde tun und lassen kann was man will
    • Es gibt aus Sicherheitsgründen kein sudo
    • Es lässt sich alles nach installieren was ohne sudo geht
  • Es sind die gängigen Sprachen in unzähligen Versionen enthalten + Haskell
  • Das gleiche gilt für Datenbanken
  • Support ist sehr wichtig
  • Ein Dienst für Developer fordert Developer als Support, daher muss jeder Entwickler auch einen Tag Support machen und zwar 7 Tage die Woche
  • Es gibt einen Cache-Layer (wo zum Beispiel auch Rubygems gecached werden) in den sich eigene Erzeugnisse ebenfalls cachen lassen

Build-Artefakte (00:20:50)

  • Keine Integration in Codeship: Build-Artefakte müssen per Skript woanders hinkopiert werden
  • Hintergrund: Nach jedem Build wird der Container vollständig zerstört
  • Deployment muss kein "Deployment" auf einen Server sein, sondern kann auch ein Script sein, welches z.B. Artefakte auf S3 kopiert
  • von Codeship vordefinierte Deployments sind vorgefertigte Abläufe, machen aber sonst nichts spezielles
  • im Wesentlichen gibt es keine Unterscheidung zwischen Setup, Test und Deploymentphasen: Es werden lediglich Kommandos ausgeführt
  • Im Environment werden alle möglichen Informationen exportiert
  • Ein spezieller Schutz für "geheime" Informationen (wie Access Keys) können aktuell noch nicht verschlüsselt in die Build-Umgebung gereicht werden

Private Installations (00:28:10)

  • Konkrete Pläne gibt es für On-Premise Installationen gibt es aktuell nicht
  • Codeship will sich nicht in Unternehmen rein verkaufen, sondern die Teams sollen Codeship haben wollen

Server in der EU und Datenschutz? (00:31:30)

  • Aktuell benutzt Codeship AWS EC2 Instanzen in us-east
  • Instanzen in der EU werden irgendwann wichtig sein (Datenschutzgesetz und auch Ausfallsicherheit)
  • Aber: Die Kunden haben aktuell ihren Code ohnehin auf Github oder Bitbucket, und deren Code liegt dann ohnehin nicht in der EU

Produktentwicklung & Fokus behalten (00:33:45)

  • Wie behält man den Fokus bei der Entwicklung?
  • Der Fokus war bei Codeship notwendig, weil Flo der einzige Entwickler war
  • Tech-only Start-Ups "bauen sich gerne in den Markt", was nicht funktioniert

Blogposts und Screencast (00:37:30)

  • 20% der Entwicklerzeit geht in Marketing: z.B. Blogposts und Screencasts
  • Der Aufwand für einen Blogpost: 4-8 Stunden, wenn man nicht zu viel Research machen muss
  • ...und bei Screencasts: Aufnahme 2-3 Stunden, Schneiden noch mal 1-1,5 Tage
  • Auch in den 20%: Meetups organisieren, Konferenzbesuche, User Groups...
  • Flo's Pro Tip: Sticker!!!

Hosting bei Heroku (00:42:40)

  • Codeship selber läuft auf Heroku mit 8 Add-Ons
    • Postgres: https://addons.heroku.com/heroku-postgresql#premium-ika
    • Logentries: https://addons.heroku.com/logentries
    • New Relic: https://addons.heroku.com/newrelic
  • New Relic Alternative: Skylight: https://www.skylight.io/

Pricing bei Codeship (00:49:15)

  • Codeship Preise: https://codeship.io/pricing
  • Kostenfrei (keine: 50 Builds, ein Concurrent Build
  • 49 USD: ein Concurrent Build, sonst keine Limits
  • je 50 USD mehr, +1 Concurrent Build

AWS (00:51:50)

  • EC2 Reserved Instances: https://aws.amazon.com/ec2/purchasing-options/reserved-instances/
  • AWS Trusted Advisor: https://aws.amazon.com/premiumsupport/trustedadvisor/

Immutable Servers (00:54:40)

  • Server sind immutable
  • Server werden gebaut mit Packer (http://www.packer.io/)
    • Aus einer JSON Konfiguration und Skripten zur Provisionierung wird eine Amazon Machine Image (AMI) erstellt
  • Worklfow bei Codeship.io:
    • Code-Änderungen auf GitHub
    • Automatische Tests
    • Erstellung des AMI (Laufzeit ~ 90 Minuten)
  • Austausch eines AMI
    • Alte Server werden ausgemacht wenn keine Jobs mehr laufen
    • Scaling-System fährt nur noch neue Maschinen hoch
  • Wichtig: Laufende Server werden nicht mehr angefasst!
  • Vorteil:
    • Alle Server sind immer gleich
    • Server sind getestet bevor ein AMI überhaupt gebaut wird
  • Ziel bei der Automatisierung: Fokus der Entwickler auf die Entwicklung, alles nach dem Push muss automatisch geschehen

Automatisierung (01:00:56)

  • Weiteres wichtiges Tool ist Librato (https://metrics.librato.com/) zur Erfassung und Auswertung von sämtlichen Daten
  • Neben Betriebsdaten von Heroku und Amazon laufen dort auch Businessdaten rein
  • Alerts auf unterschiedlichen Ebenen
  • Wenn was ist, dann wird man benachrichtigt
  • Über Health-Checks werden sogar die Build-Server automatisch deaktiviert und neue Instanzen hochgefahren
  • Wenn alles automatisiert ist, dann können sich die Entwickler stärker auf ihre Arbeit konzentrieren
  • Keine dedizierte Ops-Abteilung, sondern gute Sys-Admins, die in die Entwicklungsabteilung und deren Prozesse integriert sind (aka: DevOps)
  • Am Ende haben alle Beteiligten (Frontend, Backend, Ops) den gleichen Workflow

Wie kommen auf die Jobs auf die Build-Server (01:05:00)

  • Auf jedem Build-Server läuft ein Sidekiq-Job
  • Die Web-App schiebt neue Jobs in die Queue
  • Die Build-Server schieben Ergebnisse zur Anzeige auf der Webseite auch wieder in eine Queue
  • Sidekiq-Pro kommt zum Einsatz

Provisionierung der LXC-Container (01:08:12)

  • Provisionierung via Bash
  • Aktuelles Projekt: Migration auf Ansible (http://www.ansible.com/home)
  • Ansible erscheint für die Anforderungen als die sinnvollste Lösung
  • Trotz LXC ist Docker (http://www.docker.com/) aktuell keine Alternative
  • Früher oder später werden sie auf Docker umstellen, da es sich als das Tooling für LXC entwickelt
  • Aktuell würde es aber mehr Arbeit machen als Benefit bringen

UX (01:12:59)

  • Die Komplexität liegt bei Codeship.io in der Feinabstimmung aller beteiligten Komponenten
  • Technisch ist es kein Hexenwerk
  • Wie bereits mehrfach angesprochen: UI/UX war und ist eine der großen Herausforderungen
  • Daher: Dedizierte Menschen, die sich um dieses Thema kümmern
  • Interviews mit Kunden
  • User-Tracking spielt auch eine wichtige Rolle
  • Kommunikation mit den Usern über Intercom (https://www.intercom.io/)
    • grundsätzlicher Support
    • Auf Basis von Metriken Identifikation von möglichen Problemen bei Kunden
  • In der UI werden unterschiedliche Fehler unterschieden: Bundle Install, Tests nicht gelaufen, etc
    • Matching der Fehlermeldung auf Reguläre Ausdrücke
    • Nicht nur die Fehlermeldung sondern entsprechender Hinweis auf die Fehlerursache
    • Next-Steps: Unterschiedliche Benachrichtigungen für unterschiedliche Fehlertypen

Kommentare


Neuer Kommentar