Me explique o que acontece entre um pull request mergeado e aquele código rodando em produção no seu time.

No merge, o CI roda checagem de tipos, lint, testes unitários e de integração contra um banco de verdade, depois constrói um artefato imutável marcado com o commit. Aquele artefato vai para staging automaticamente, os smoke tests rodam, e então ele vai para produção atrás de um rollout gradual com health checks e rollback automático. Comportamento arriscado fica atrás de uma feature flag, para lançar código e lançar funcionalidade continuarem sendo eventos separados.

No último time em que eu estive, fazer merge na main disparava o CI: checagem de tipos, lint, testes unitários, depois testes de integração contra um container de Postgres, uns sete minutos de ponta a ponta. Se aquilo passava, a gente construía uma imagem de container marcada com o SHA do commit, e aquela imagem exata é o que segue adiante; nada é reconstruído por ambiente, porque aí você está entregando algo que você nunca testou. Ela ia para staging automaticamente, rodava uma suíte curta de smoke contra endpoints reais, e então ia para produção como um rolling deploy com health checks, observando taxa de erro e latência por alguns minutos com rollback automático se qualquer uma cruzasse um limiar. As migrações rodavam como um passo separado antes do deploy e eram sempre retrocompatíveis, então um rollback do código nunca deixava o schema desamparado. Qualquer coisa visível ao usuário saía atrás de uma flag, desligada por padrão, depois para usuários internos, depois para uma porcentagem. Essa distinção importava mais que tudo, porque significava que um lançamento ruim era uma chave de configuração e não um deploy de emergência às nove da noite.