Softwareentwicklung mit Devin: Sicherheit, Einsatz, Wartung (Teil 4)

Willkommen zurück! Wir sind fast am Ziel: Slack zwitschert, Jira hat Tickets, die Tests sind grün und unser CI blockiert jeden schlampigen PR. Teil vier ist der letzte Schritt, mit dem wir den fp-ts Spielplatz in etwas verwandeln, auf das wir theoretisch die Öffentlichkeit aufmerksam machen können.

Du kannst alle Tutorials der Devin-Serie hier aufrufen:

1. Einrichtung und erster Pull Request (Teil 1)
2. Eine vertikale Scheibe mit Devin verschiffen (Teil 2)
3. Integration, Tests und CI/CD (Teil 3) 
4. Sicherheit, Einsatz, Wartung (Teil 4)

Hier ist der Plan für dieses vierte Tutorial:

• Autor: Keine anonymen UUIDs mehr; wir werden NextAuth-Anmeldedaten, JWT-Cookies und einen GqlAuthGuard ein, damit der Fortschritt an echte Nutzer gebunden ist.
• Die Augen auf die Produktion gerichtet: Eine Zeile Sentry-Code in der Web-App, eine in der Nest-API, und jede Ausnahme landet im Dashboard.
• Einsatz auf Knopfdruck: Das Frontend geht auf Vercel mit Vorschau-URLs für jeden PR live. (Die API bleibt vorerst lokal, wir werden sie mit Docker nachbilden).

Wir werden auch über diese Paarprogrammierung mit Devin nachdenken und sehen, wo sie glänzt und wo ein Mensch noch mit losen Enden aufräumen muss, bevor die Welt das Repo sieht. Bereit für die letzte Etappe?

Von anonymen UUIDs zu echten Benutzern

Was ich Devin gebeten habe zu tun

Kurz gesagt, ich habe Devin gebeten, den anonymen UUID-Flow zu entfernen und mir einen echten Auth-Stack zu geben:

• NextAuth v6 credentials provider in apps/web
• NestJS AuthModule mit Argon2-Hashing und JWT-Cookies
• Prisma-Migration, die eine Tabelle User hinzufügt und Progress.sessionId → userId (non-null) ändert
• Kopiere alle vorhandenen UUID-Fortschrittszeilen auf einen Platzhalter-Benutzer, damit die Lernenden ihre Abzeichen behalten
• Tausche Postgres nicht gegen SQLite

Was zurückkam (meistens gut)

Hier ist eine Zusammenfassung der Ergebnisse:

Eine weitere SQLite-Migration

Rate mal, was ich in Devins kleiner Denkbox wieder gesehen habe.

Erfolgreiche Migration von PostgreSQL zu SQLite für die lokale Entwicklung 🥳

Genau das, was ich ihm gesagt hatte, dass eres nicht tun soll. Das Prisma-Schema wurde für SQLite umgeschrieben und die Verbindungsstrings und -typen wurden geändert (von TIMESTAMP zu DATETIME). Ich habe es mitten in der Sitzung mitbekommen:

1. Pausiere die Sitzung.
2. git checkout main apps/api/prisma/schema.prisma (Postgres-Schema wiederherstellen).
3. Lösche die neue dev.db Datei.
4. npm run prisma:migrate --workspace=apps/api um Postgres-Migrationen erneut anzuwenden.
5. nahm Devin wieder auf; er erkannte die Umkehr und fuhr ohne Beanstandung fort.

Schaden: 0,8 ACU und etwa zehn Minuten.

Veränderungs-Checkliste für Teammitglieder

Ich schätze die Anweisungen, die Devin in PRs gibt, sehr. Hier sollten wir es tun:

# 1  Install new deps
npm install --workspaces

# 2  Run the Postgres migration
npm run prisma:migrate --workspace=apps/api

# 3  Restart everything
npm run dev:api   &   npm run dev:web

Architektur-Schnappschuss

Im Wiki habe ich dieses hilfreiche Diagramm zu unserem neuen Autorisierungssystem gefunden:

Jetzt, wo wir echte Nutzer haben und die Datenbank wieder auf Postgres basiert, sind wir endlich bereit, den Lernpfad zu verfolgen, Preview-Builds an Vercel zu senden und Laufzeitfehler mit Sentry zu erkennen.

Front-End auf Vercel, Vorschau-Links auf jeder PR

Nachdem die sicheren Log-ins eingerichtet waren, war der nächste offensichtliche Meilenstein, der Welt etwas zum Anklicken zu zeigen. Wir haben uns entschieden, vorerst nur das Next.js Frontend einzusetzen. API und Postgres bleiben auf meinem lokalen Rechner, bis wir uns für einen Host entscheiden, der in unser Budget passt.

Manuelle Kontoeröffnung (0 ACUs)

Die Verbindung von Devin mit meinem persönlichen Vercel-Konto über native Integrationen ist noch nicht möglich. Also habe ich es manuell über das Vercel-Dashboard gemacht:

1. Logge dich in Vercel ein und klicke auf "Neues Projekt → Git-Repository importieren".
2. Wähle das fp-ts-exercises Repo aus, belasse den Build-Befehl auf npm run build --workspace apps/web und klicke auf Bereitstellen.
3. Kopiere das Ergebnis VERCEL_PROJECT_ID und VERCEL_TOKEN in GitHub Secrets.

Lass Devin den CI-Workflow aktualisieren (0.4 ACU)

Auf meine Aufforderung hin fügte Devin am Ende des bestehenden Workflows einen einzelnen Job und einen kleinen Shell-Schritt hinzu, der die generierte URL an Slack weiterleitet:

- name: Deploy to Vercel
  if: ${{ success() && github.event_name == 'pull_request' }}
  run: npx vercel deploy --prod --token ${{ secrets.VERCEL_TOKEN }}
  env:
    VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
    VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

Ergebnis

Push einen Zweig → CI grün → Slack ping:

✅ Preview ready: https://fp-ts-exercises-git-my-branch.vercel.app

Wenn du den Link öffnest, siehst du unseren Spielplatz, den vollständigen Authentifizierungsfluss und das Dashboard der Lernenden. Auf Vercels Seite ist noch keine Anpassung der Umgebung erforderlich, da das Frontend über http://localhost:4000 mit meiner lokalen API kommuniziert.

Ein genauerer Blick auf Devins Geheimnissystem

Vor der Integration in Sentry habe ich mir Devins Geheimnissystem angesehen, um herauszufinden, ob ich es verwenden sollte. Devin bietet einen eingebauten "Secrets"-Tresor, damit du dem Agenten API-Schlüssel, DB-URLs oder OAuth-Tokens geben kannst, ohne sie in Git einzuchecken und ohne sie im Chat preiszugeben. Betrachte es als ein leichtes Äquivalent zu GitHub Actions secrets oder Vercels Environment Variables, aber auf Devins eigene Cloud Workspaces beschränkt.

Hinzufügen eines Geheimnisses

Hier sind die Schritte, die du befolgen musst, um ein Geheimnis hinzuzufügen:

1. Öffne Team → Geheimnisse im Dashboard von Devin.
2. Klicke auf "Geheimnis hinzufügen" und gib einen Namen (SENTRY_DSN_WEB ) und seinen Wert ein.
3. Devin bestätigt die Speicherung; der Schlüssel ist jetzt als $.SENTRY_DSN_WEB verfügbar.

Ein Geheimnis in einer Aufgabe verwenden

Aufgabe: API Sentry init aktualisieren; DSN setzen auf $SECRET.SENTRY_DSN_API

Devin ersetzt den Wert, wenn er main.ts schreibt. In der Shell-Registerkarte siehst du den eigentlichen DSN, aber das Chat-Protokoll verbirgt ihn.

Pro und Kontra

Vorteile:

• Es besteht kein Risiko, dass Schlüssel in PRs oder Timelapse-Logs durchsickern.
• Organisationsbezogene Geheimnisse funktionieren sitzungsübergreifend: ein Upload, viele Verwendungen.
• Keine Kreditkosten zum Lagern oder Abholen.

Nachteile:

• Die Schlüssel sind nicht lokal verfügbar, es sei denn, du kopierst sie in .env. Testläufe außerhalb von Devin müssen manuell eingerichtet werden.
• Kein Scoping nach Umgebungen (z. B. "nur in der Produktion"). Alle Sitzungen erhalten alle Geheimnisse.

Wann man es benutzt

Ich finde es einfacher, Devins Tresor zu benutzen, wenn Devin selbst den Schlüssel braucht (z.B. beim Pushing nach Vercel, beim Zugriff auf eine private Registry oder beim Verdrahten von Sentry während des Builds). Ich würde weiterhin .env / GitHub Actions secrets für alles verwenden, was auch in deiner lokalen Dev-Shell oder CI-Runnern läuft.

Devin Integration mit Sentry

Hier ist die Aufforderung, die ich benutzt habe: Füge Sentry zu beiden Apps hinzu, damit jede Ausnahme in meinem Dashboard angezeigt wird. Verwende Umgebungsvariablen in .env. Kein anderes Verhalten ändert sich."

Devins Arbeit (0,6 ACU, eine Sitzung)

Hier ist eine Zusammenfassung des Ergebnisses:

Meine manuellen Schritte

Hier sind die Schritte, die ich unternommen habe:

1. Kopiere DSNs aus meinem Sentry-Projekt in .env.
2. Habe beide Dev-Server neu gestartet.
3. Rufe http://localhost:4000/graphql mit einer absichtlich schlechten Abfrage auf, um zu prüfen, ob sie funktioniert. Eine Ausgabe erschien innerhalb von Sekunden in Sentry.

Warum ich Devins Geheimnisse übersprungen habe

Deshalb habe ich Devins Beitrag über die Geheimnisse übersprungen:

• Einfacheres mentales Modell: überall die gleiche .env Datei.
• Es ist einfacher, Preview-Builds auf Vercel auszuführen (die Umgebungsvariablen sind dort bereits gesetzt).
• Kein ACU-Brand für Geheimoperationen.

Reflektionen: Wo Devin glänzt und wo er stolpert

Vor vier Tutorials war dieses Repo ein verstaubter Haufen von fp-ts Übungen - jetzt ist es das:

• Modernisierte Codebasis: Neueste Abhängigkeiten, strikte TS-Konfiguration, Lint & Prettier-Regeln (Teil 1).
• Browserbasierter Spielplatz: Next.js 14 + Sandpack-Editor mit Live-Feedback von Vitest (Teil 2).
• NestJS + Postgres Backend: GraphQL API, Prisma-Migrationen, anonyme → JWT-Lernpfade (Teil 2 & 4).
• Grünes Licht für die Pipeline: CI-Workflow, der Linktests, Typprüfungen, Jest und Playwright ausführt und jeden fehlerhaften PR blockiert (Teil 3).
• Teamintegrationen: Slack-Status-Pings, Jira-Label-Analyse und Vorschau-URLs für jeden Zweig (Teil 3).
• Beobachtbarkeit der Produktion: Sentry ist sowohl mit dem Web als auch mit der API verbunden und erfasst jede Ausnahme (Teil 4).
• Die Vorschau setztein: Vercel erstellt eine teilbare URL für jede Pull-Anfrage (Teil 4).

Wir haben etwa ≈ 70 ACUs insgesamt (~$157 für den Core-Plan) und etwa zwei Arbeitstage für die praktische Prüfung.

Was Devin erschreckend gut kann

Hier denke ich, dass Devin sehr gut ist:

Wo ein Mensch den Agenten noch schlägt

Hier muss sich Devin meiner Meinung nach noch verbessern:

Meine Meinung

Devins eigene Dokumente versprachen nie einen Product Builder. Sie umreißen einen viel engeren Sweet Spot, und im Nachhinein betrachtet, hätte ich darin bleiben sollen. Die offizielle "Was sind Devins Stärken?"-Seite listet vier Schlagzeilen auf:

In den Dokumenten wird die Entwicklung von Funktionen, die die Benutzeroberfläche, die API und den Datenfluss umfassen, als "experimentell" bezeichnet. Sie werden als große Aufgaben mit offenem Ende beschrieben, bei denen der Agent "eine umfangreiche menschliche Überprüfung und Iteration erfordert". Das ist genau das, was wir gesehen haben, als Sandpack Tests hart kodiert hat oder als das Dashboard zwar gut aussah, aber die Daten nicht wirklich berechnet hat.

Als Faustregel gilt also:

Verwende Devin für alles, was ein erfahrener Entwickler mit einem Skript automatisieren kann, und behalte das Lenkrad für Aufgaben, die ein Produktverständnis erfordern.

Fazit

Wir haben das Ende unseres vierteiligen Tutorials erreicht:

1. Einrichtung und erster Pull Request (Teil 1)
2. Eine vertikale Scheibe mit Devin verschiffen (Teil 2) 
3. Integration, Tests und CI/CD (Teil 3) 
4. Sicherheit, Einsatz, Wartung (Teil 4)

Hier sind ein paar nächste Schritte, die wir von hier aus unternehmen können:

1. Hostet die API, damit Preview-Builds (und zukünftige Nutzer) auf ein echtes Backend treffen.
2. Sicherstellen, dass die Kernfunktionen funktionieren und die 30 Bugs beheben, von denen ich weiß, dass sie da sind
3. Poliere die Benutzeroberfläche
4. Mehr Inhalte und Übungen hinzufügen
5. Freigeben für Menschen zum Gebrauch!

Wenn du den gleichen Weg einschlägst, denk daran: Du kannst den Makler den Beton legen lassen, aber du musst das Haus trotzdem entwerfen. Viel Spaß beim Codieren!