Desarrollo de software con Devin: Seguridad, implantación y mantenimiento (4ª parte)

¡Bienvenido de nuevo! Ya casi hemos llegado: Slack chirría, Jira tiene tickets, las pruebas están en verde y nuestro CI bloquea cada PR descuidado. La cuarta parte es el empujón final en el que convertiremos el patio de fp-ts en algo a lo que, en teoría, podríamos apuntar al público.

Puedes acceder a todos los tutoriales de la serie Devin aquí:

1. Configuración y primera Pull Request (Parte 1)
2. Enviar una rodaja vertical con Devin (2ª parte)
3. Integraciones, pruebas y CI/CD (3ª parte) 
4. Seguridad, implantación y mantenimiento (4ª parte)

Éste es el plan para este cuarto tutorial:

• Aut: Se acabaron los UUIDs anónimos; incluiremos credenciales NextAuth, cookies JWT y un GqlAuthGuard para que el progreso esté vinculado a usuarios reales.
• Ojos en la producción: Una línea de código Sentry en la aplicación web, una en la API Nest, y todas las excepciones aterrizan en el panel de control.
• Se despliega pulsando un botón: El front-end se activa en Vercel con URLs de previsualización en cada RP. (La API permanecerá local por ahora, fingiremos la producción con Docker).

También reflexionaremos sobre esta programación en parejas con Devin y veremos dónde brilla y dónde un humano aún tiene que arreglar los cabos sueltos antes de que el mundo vea el repositorio. ¿Listo para el último tramo?

De UUID anónimos a usuarios reales

Lo que le pedí a Devin

En resumen, le pedí a Devin que arrancara el flujo UUID anónimo y me diera una pila de autenticación real:

• Proveedor de credenciales NextAuth v6 en apps/web
• AuthModule de NestJS con hashing Argon2 y cookies JWT
• Migración Prisma que añade una tabla User y cambia Progress.sessionId → userId (no nulo)
• Copia cualquier fila de progreso UUID existente a un usuario marcador de posición para que los alumnos conserven sus insignias
• No cambies Postgres por SQLite

Lo que ha vuelto (en su mayoría bueno)

Aquí tienes un resumen de los resultados:

Otra migración a SQLite

Adivina lo que vi aparecer de nuevo en la pequeña caja de pensamientos de Devin.

Migración con éxito de PostgreSQL a SQLite para el desarrollo local 🥳

Exactamente lo que le había dicho queno hiciera. Se reescribió el esquema Prisma para SQLite, y se cambiaron las cadenas y tipos de conexión (de TIMESTAMP a DATETIME). Lo he pillado a mitad de sesión:

1. Pausa la sesión.
2. git checkout main apps/api/prisma/schema.prisma (restaurar esquema Postgres).
3. Borra el nuevo archivo dev.db.
4. npm run prisma:migrate --workspace=apps/api para volver a aplicar las migraciones Postgres.
5. Reanudó Devin; detectó la reversión y continuó sin quejarse.

Daños: 0,8 ACU y unos diez minutos.

Lista de control de cambio para compañeros de equipo

Aprecio mucho las instrucciones que Devin pone en los PR. Aquí nos lo dijo:

# 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

Instantánea de la arquitectura

En la wiki, encontré este útil diagrama de nuestro nuevo sistema de autenticación:

Con usuarios reales y la base de datos firmemente asentada en Postgres, por fin estamos listos para seguir el progreso de un auténtico aprendiz, enviar versiones preliminares a Vercel y detectar errores de ejecución con Sentry.

Front-End en Vercel, enlaces de previsualización en cada RP

Una vez establecidos los inicios de sesión seguros, el siguiente hito obvio era mostrar al mundo algo sobre lo que se pudiera hacer clic. Decidimos desplegar sólo el front-end Next.js por ahora. API y Postgres permanecerán en mi máquina local hasta que elijamos un host que se ajuste al presupuesto.

Conexión manual de la cuenta (0 ACUs)

Conectar Devin a mi cuenta personal de Vercel mediante integraciones nativas aún no es posible. Así que lo hice manualmente, a través del panel de control de Vercel:

1. Inicia sesión en Vercel y haz clic en "Nuevo proyecto → Importar repositorio Git".
2. Selecciona el repositorio fp-ts-exercises, deja el comando de compilación como npm run build --workspace apps/web, y pulsa Desplegar.
3. Copia el VERCEL_PROJECT_ID resultante y VERCEL_TOKEN en GitHub Secrets.

Deja que Devin actualice el flujo de trabajo CI (0.4 ACU)

Siguiendo mis indicaciones, Devin añadió un único trabajo al final del flujo de trabajo existente y un pequeño paso de terminal que riza la URL generada a Slack:

- 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 }}

Resultado

Empuja una rama → CI verde → Slack ping:

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

Al abrir el enlace se mostraba nuestro patio de recreo, el flujo de autenticación completa y el panel de control del alumno. Aún no es necesario ajustar el entorno en Vercel, porque el front-end se comunica con mi API local a través de http://localhost:4000.

Una mirada más de cerca al Sistema de Secretos de Devin

Antes de la integración con Sentry, eché un vistazo al sistema de secretos de Devin para saber si debía utilizarlo. Devin ofrece una bóveda de "Secretos" integrada para que puedas dar al agente claves API, URL de BD o tokens OAuth sin registrarlos en Git y sin exponerlos en el chat. Piensa en ello como un equivalente ligero a los secretos de las Acciones de GitHub o a las Variables de Entorno de Vercel, pero limitado a los espacios de trabajo en la nube de Devin.

Añadir un secreto

Estos son los pasos que debes seguir para añadir un secreto:

1. Abre Equipo → Secretos en el panel de control de Devin.
2. Haz clic en "Añadir secreto" e introduce un nombre (SENTRY_DSN_WEB ) y su valor.
3. Devin confirma el almacenamiento; la clave ya está disponible como $.SENTRY_DSN_WEB.

Utilizar un secreto en una tarea

Tarea: actualizar API Sentry init; Establecer DSN a $SECRET.SENTRY_DSN_API

Devin sustituye el valor cuando escribe main.ts. En la pestaña del terminal, verás el DSN literal, pero el registro del chat lo oculta.

Pros y contras

Pros:

• No hay riesgo de que se filtren claves en los PR o en los registros de Timelapse.
• Los secretos de organización funcionan en todas las sesiones: una carga, muchos usos.
• Cero coste de crédito para almacenar o recuperar.

Contras:

• Las claves no están disponibles localmente a menos que las copies en .env. Las pruebas fuera de Devin necesitan una configuración manual.
• Sin ámbito por entorno (por ejemplo, "sólo en producción"). Todas las sesiones tienen todos los secretos.

Cuándo utilizarlo

Me resulta más fácil utilizar la bóveda de Devin cuando el propio Devin necesita la clave (por ejemplo, al enviarla a Vercel, al acceder a un registro privado o al cablear Sentry durante la compilación). Yo seguiría utilizando .env / GitHub Actions secrets para todo lo que también se ejecuta en tu terminal de desarrollo local o en los ejecutores de CI.

Integración de Devin con Sentry

Este es el mensaje que utilicé: Añade Sentry a ambas aplicaciones para que todas las excepciones aparezcan en mi panel de control. Utiliza variables de entorno en .env. No cambia ningún otro comportamiento".

Trabajo de Devin (0,6 ACU, una sesión)

Aquí tienes un resumen del resultado:

Mis pasos manuales

Estos son los pasos que di:

1. He copiado los DSN de mi proyecto Sentry en .env.
2. Reinicia ambos servidores de desarrollo.
3. Pulsa http://localhost:4000/graphql con una consulta deliberadamente mala para comprobar que funcionaba. En cuestión de segundos apareció un número en Sentry.

Por qué me salté los secretos de Devin

Por eso me salté la función de secretos de Devin:

• Modelo mental más sencillo: el mismo archivo .env en todas partes.
• Es más fácil ejecutar versiones preliminares en Vercel (las variables de entorno ya están configuradas allí).
• No se quema la ACU para operaciones secretas.

Reflexiones: Dónde brilla Devin y dónde tropieza

Hace cuatro tutoriales, este repositorio era un montón polvoriento de ejercicios de fp-ts; ahora, sí:

• Base de código modernizada: Últimas dependencias, configuración estricta de TS, reglas de lint y Prettier (Parte 1).
• Zona de juegos basada en navegador: Next.js 14 + Editor Sandpack con feedback en vivo de Vitest (Parte 2).
• NestJS + Postgres backend: API GraphQL, migraciones Prisma, anónimo → Seguimiento del progreso JWT (Partes 2 y 4).
• Gasoducto con luz verde: Flujo de trabajo CI que enlaza, comprueba la tipografía, ejecuta Jest y Playwright, y bloquea cada RP que falla (Parte 3).
• Integraciones de equipo: Pings de estado de Slack, análisis de etiquetas de Jira y URL de vista previa en cada rama (Parte 3).
• Observabilidad de la producción: Sentry conectado tanto a la web como a la API, capturando todas las excepciones (Parte 4).
• La vista previa se despliega en: Vercel genera una URL compartible para cada pull request (Parte 4).

Gastamos alrededor de ≈ 70 ACUs en total (~157 $ en el plan Básico) y unos dos días laborables de revisión práctica.

Lo que Devin hace espantosamente bien

Aquí es donde creo que Devin es muy bueno:

Donde un humano sigue ganando al agente

Aquí es donde creo que Devin todavía necesita mejorar:

Mi opinión

Los propios documentos de Devin nunca prometieron un constructor de productos. Esbozan un punto dulce mucho más estrecho y, en retrospectiva, debería haberme quedado dentro de él. La página oficial "página "¿Cuáles son los puntos fuertes de Devin? enumera cuatro titulares:

Los documentos denominan "experimental" al desarrollo de funciones que abarcan la interfaz de usuario, la API y los flujos de datos. Se describen como tareas grandes y abiertas en las que el agente puede "requerir una revisión e iteración humanas significativas". Esto es exactamente lo que vimos cuando Sandpack codificaba las pruebas o cuando el panel de control tenía buen aspecto pero en realidad no calculaba los datos.

Así que, como regla general

Utiliza Devin para cualquier cosa que un programador senior podría automatizar con un script, y mantén el volante para las tareas que necesitan sentido de producto.

Conclusión

Llegamos al final de nuestro tutorial en cuatro partes:

1. Configuración y primera Pull Request (Parte 1)
2. Enviar una rodaja vertical con Devin (2ª parte) 
3. Integraciones, pruebas y CI/CD (3ª parte) 
4. Seguridad, implantación y mantenimiento (4ª parte)

He aquí algunos pasos que podemos dar a partir de ahora:

1. Aloja la API para que las versiones preliminares (y los futuros usuarios) tengan un backend real.
2. Asegurarme de que la funcionalidad básica funciona y arreglar los 30 fallos que sé que hay
3. Pulir la IU
4. Añade más contenidos y ejercicios
5. ¡Libéralo para que la gente lo use!

Si sigues el mismo camino, recuerda: puedes dejar que el agente ponga el hormigón, pero tú sigues teniendo que diseñar la casa. ¡Feliz codificación!