Desenvolvimento de software com Devin: Segurança, implementação e manutenção (Parte 4)

Bem-vindo de volta! Estamos quase lá: O Slack está tocando, o Jira tem tíquetes, os testes são verdes e nossa CI bloqueia todos os PRs desleixados. A parte quatro é o esforço final, em que transformaremos o playground do fp-ts em algo que, em teoria, poderia ser indicado ao público.

Você pode acessar todos os tutoriais da série Devin aqui:

1. Configuração e primeira solicitação pull (parte 1)
2. Enviando uma fatia vertical com Devin (Parte 2)
3. Integrações, testes e CI/CD (Parte 3) 
4. Segurança, implementação e manutenção (Parte 4)

Aqui está o plano para este quarto tutorial:

• Autorização: Não há mais UUIDs anônimos; vamos incluir credenciais NextAuth, cookies JWT e um GqlAuthGuard para que o progresso seja vinculado a usuários reais.
• Olhos na produção: Uma linha de código do Sentry no aplicativo Web, uma na API do Nest e todas as exceções aparecem no painel.
• Ativação por botão de pressão: O front-end é ativado no Vercel com URLs de visualização em cada PR. (Por enquanto, a API permanecerá local, mas vamos falsificar a produção com o Docker).

Também refletiremos sobre essa programação em pares com Devin e veremos onde ela se destaca e onde um ser humano ainda precisa arrumar as pontas soltas antes que o mundo veja o repositório. Você está pronto para a última etapa?

De UUID anônimo a usuários reais

O que pedi a Devin para fazer

Resumindo, pedi a Devin que eliminasse o fluxo de UUID anônimo e me fornecesse uma pilha de autenticação real:

• Provedor de credenciais NextAuth v6 em apps/web
• NestJS AuthModule com hashing Argon2 e cookies JWT
• Migração do Prisma que adiciona uma tabela User e altera Progress.sessionId → userId (não nulo)
• Copie todas as linhas de progresso UUID existentes para um usuário de espaço reservado para que os alunos mantenham seus emblemas
• Não troque o Postgres pelo SQLite

O que você recebeu (em sua maioria, bom)

Aqui está um resumo dos resultados:

Outra migração para o SQLite

Adivinhe o que eu vi aparecer novamente na pequena caixa de pensamento de Devin.

Migração bem-sucedida do PostgreSQL para o SQLite para desenvolvimento local 🥳

Exatamente o que eu havia dito a ele paranão fazer. O esquema do Prisma foi reescrito para o SQLite, e as cadeias de conexão e os tipos foram alterados (de TIMESTAMP para DATETIME). Eu o peguei no meio da sessão:

1. Pausou a sessão.
2. git checkout main apps/api/prisma/schema.prisma (restaurar o esquema do Postgres).
3. Excluiu o novo arquivo dev.db.
4. npm run prisma:migrate --workspace=apps/api para reaplicar as migrações do Postgres.
5. Retomou Devin; ele detectou a reversão e continuou sem reclamar.

Danos: 0,8 ACU e cerca de dez minutos.

Lista de verificação de mudança radical para colegas de equipe

Eu realmente aprecio as instruções que Devin coloca nos PRs. Aqui ele nos disse para fazê-lo:

# 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

Visão geral da arquitetura

No wiki, encontrei este diagrama útil do nosso novo sistema de autenticação:

Com usuários reais instalados e o banco de dados firmemente de volta ao Postgres, estamos finalmente prontos para acompanhar o progresso genuíno do aluno, enviar compilações de visualização para o Vercel e detectar erros de tempo de execução com o Sentry.

Front-end no Vercel, links de visualização em cada PR

Com os logins seguros implementados, o próximo marco óbvio era mostrar ao mundo algo clicável. Decidimos implantar apenas o front-end Next.js por enquanto. A API e o Postgres permanecerão em meu computador local até escolhermos um host que caiba no orçamento.

Conexão manual de conta (0 ACUs)

Ainda não é possível conectar o Devin à minha conta pessoal da Vercel por meio de integrações nativas. Então, fiz isso manualmente, por meio do painel da Vercel:

1. Fiz login no Vercel e cliquei em "New Project → Import Git Repository".
2. Selecione o repositório fp-ts-exercises, deixe o comando de compilação como npm run build --workspace apps/web e clique em Deploy.
3. Você copiou os arquivos VERCEL_PROJECT_ID e VERCEL_TOKEN resultantes para o GitHub Secrets.

Permita que Devin atualize o fluxo de trabalho de CI (0.4 ACU)

Seguindo minha orientação, Devin adicionou um único trabalho à parte inferior do fluxo de trabalho existente e uma pequena etapa do shell que enrola a URL gerada para o 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

Enviar uma ramificação → CI green → Slack ping:

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

Ao abrir o link, você verá nosso playground, o fluxo de autenticação completo e o painel do aluno. Ainda não é necessário nenhum ajuste de ambiente no final da Vercel, porque o front-end conversa com minha API local em http://localhost:4000.

Uma olhada mais de perto no sistema de segredos de Devin

Antes da integração com o Sentry, dei uma olhada no sistema de segredos do Devin para descobrir se deveria usá-lo. O Devin oferece um cofre "Secrets" integrado para que você possa fornecer ao agente chaves de API, URLs de banco de dados ou tokens OAuth sem verificá-los no Git e sem expô-los no bate-papo. Pense nisso como um equivalente leve aos segredos do GitHub Actions ou às variáveis de ambiente do Vercel, mas com escopo para os próprios espaços de trabalho em nuvem do Devin.

Adicionar um segredo

Aqui estão as etapas que você precisa seguir para adicionar um segredo:

1. Aberto Equipe → Segredos no painel de controle do Devin.
2. Clique em "Adicionar segredo" e digite um nome (SENTRY_DSN_WEB ) e seu valor.
3. Devin confirma o armazenamento; a chave agora está disponível em $.SENTRY_DSN_WEB.

Usando um segredo em uma tarefa

Tarefa: atualizar a API Sentry init; definir DSN para $SECRET.SENTRY_DSN_API

O Devin substitui o valor quando você escreve main.ts. Na guia shell, você verá o DSN literal, mas o registro de bate-papo o oculta.

Prós e contras

Pros:

• Não há risco de vazamento de chaves em PRs ou registros de lapso de tempo.
• Os segredos com escopo de organização funcionam em todas as sessões: um upload, muitos usos.
• Custo zero de crédito para armazenar ou buscar.

Contras:

• As chaves não estão disponíveis localmente, a menos que você as copie para .env. Os testes realizados fora do Devin precisam de configuração manual.
• Sem escopo por ambiente (por exemplo, "somente em produção"). Todas as sessões recebem todos os segredos.

Quando usá-lo

Acho mais fácil usar o cofre do Devin quando o próprio Devin precisa da chave (por exemplo, enviando para o Vercel, acessando um registro privado ou conectando o Sentry durante a compilação). Eu continuaria usando .env / GitHub Actions secrets para tudo o que também é executado em seu shell de desenvolvimento local ou executores de CI.

Integração do Devin com o Sentry

Aqui está o prompt que usei: Adicione o Sentry aos dois aplicativos para que todas as exceções apareçam no meu painel. Use variáveis de ambiente em .env. Nenhum outro comportamento muda".

Trabalho de Devin (0,6 ACU, uma sessão)

Aqui está um resumo do resultado:

Minhas etapas manuais

Aqui estão as etapas que segui:

1. Copiei DSNs do meu projeto Sentry para .env.
2. Reiniciei os dois servidores de desenvolvimento.
3. Acesse http://localhost:4000/graphql com uma consulta deliberadamente ruim para verificar se funcionou. Um problema apareceu no Sentry em segundos.

Por que pulei o recurso de segredos de Devin

É por isso que eu pulei o recurso de segredos do Devin:

• Modelo mental mais simples: o mesmo arquivo .env em todos os lugares.
• É mais fácil executar compilações de visualização no Vercel (essas variáveis de ambiente já estão definidas lá).
• Não há queima de ACU para operações de armazenamento secreto.

Reflexões: Onde o Devin brilha e onde ele tropeça

Há quatro partes do tutorial, esse repositório era uma pilha empoeirada de exercícios de fp-ts. Agora, ele tem:

• Base de código modernizada: Dependências mais recentes, configuração estrita do TS, regras do lint e do Prettier (Parte 1).
• Playground baseado em navegador: Next.js 14 + editor Sandpack com feedback Vitest ao vivo (Parte 2).
• NestJS + backend do Postgres: API GraphQL, migrações Prisma, anônimo → JWT, acompanhamento do progresso (Partes 2 e 4).
• Pipeline com luz verde: Fluxo de trabalho de CI que faz a ligação, verifica a digitação, executa o Jest e o Playwright e bloqueia cada PR com falha (Parte 3).
• Integrações de equipe: Pings de status do Slack, análise de rótulos do Jira e URLs de visualização em todas as ramificações (Parte 3).
• Observabilidade da produção: O Sentry foi conectado à Web e à API, capturando todas as exceções (Parte 4).
• A pré-visualização é implementada em: O Vercel cria uma URL compartilhável para cada pull request (Parte 4).

Gastamos cerca de ≈ 70 ACUs no total (~$157 no plano Core) e cerca de dois dias úteis de revisão prática.

O que Devin faz assustadoramente bem

É aqui que eu acho que Devin é muito bom:

Onde um humano ainda vence o agente

É nesse ponto que acho que Devin ainda precisa melhorar:

Minha opinião

Os próprios documentos do Devin nunca prometeram um construtor de produtos. Eles delineiam um ponto ideal muito mais estreito e, em retrospecto, eu deveria ter ficado dentro dele. A página oficial "página "Quais são os pontos fortes de Devin? lista quatro usos de títulos:

Os documentos chamam de "experimental" o desenvolvimento de recursos que abrangem a interface do usuário, a API e os fluxos de dados. Elas são descritas como tarefas grandes e abertas em que o agente pode "exigir revisão e iteração humanas significativas". Isso é exatamente o que vimos quando o Sandpack codificou testes ou quando o painel parecia bom, mas não computava os dados de fato.

Portanto, como regra geral:

Use o Devin para qualquer coisa que um desenvolvedor sênior possa automatizar com um script e mantenha o volante para as tarefas que precisam de um senso de produto.

Conclusão

Chegamos ao final de nosso tutorial em quatro partes:

1. Configuração e primeira solicitação pull (parte 1)
2. Enviando uma fatia vertical com Devin (Parte 2) 
3. Integrações, testes e CI/CD (Parte 3) 
4. Segurança, implementação e manutenção (Parte 4)

Aqui estão algumas das próximas etapas que você pode seguir:

1. Hospede a API para que as compilações de visualização (e os futuros usuários) tenham um back-end real.
2. Certifique-se de que a funcionalidade principal funcione e corrija os 30 bugs que sei que estão lá
3. Aperfeiçoe a interface do usuário
4. Adicionar mais conteúdo e exercícios
5. Liberar para as pessoas usarem!

Se você seguir o mesmo caminho, lembre-se: você pode deixar o agente colocar o concreto, mas você ainda precisa projetar a casa. Boa codificação!