Ciclo de vida do código — Git, deploy, ambiente de desenvolvimento x produção
Todo código passa por um caminho, do rascunho na sua máquina até o que o usuário final realmente acessa.
Git
Deploy
Desenvolvimento x produção
00 — GIT
Um histórico de versões do código, com volta garantida
Gité uma ferramenta que guarda o histórico de mudanças de um projeto de código. Cada "commit" é uma foto salva do projeto naquele momento, com uma mensagem descrevendo o que mudou. Um "branch" é uma cópia paralela do código, usada pra experimentar ou construir algo novo sem afetar a versão principal — quando pronta, essa cópia pode ser unida de volta ("merge"). A vantagem central é simples: se algo quebrar, sempre existe uma versão anterior salva pra voltar.
Metáfora: é como salvar versões numeradas de um documento importante — em vez de sobrescrever o arquivo original a cada mudança, cada versão fica preservada, e é sempre possível abrir uma versão antiga se a mais recente tiver um problema.
Nesta própria sessãoAntes de você mexer nas ilustrações dos módulos 3 a 10, foi feito um commit de checkpoint — exatamente pra garantir que, se algo desse errado durante a edição, sempre existiria essa versão salva pra voltar.
reconhecer 1 — gitpendente
Qual é a vantagem central de commitar mudanças no Git com frequência?
AO código fica automaticamente mais rápido
BSempre existe uma versão anterior salva, pra voltar caso algo dê errado
CCommits substituem a necessidade de testar o código
01 — DEPLOY
Levar o código novo até onde o usuário realmente acessa
Deploy é o processo de levar uma versão nova do código do ambiente onde foi escrita até o servidor que atende usuários reais — visto desde o Módulo 9, geralmente envolvendo um build (transformar o código-fonte num formato otimizado pra rodar) e reiniciar o processo que serve a aplicação.
Metáfora: escrever o código é como preparar um prato novo na cozinha. Deploy é o momento de efetivamente levar esse prato até a mesa do cliente — até lá, por melhor que esteja, ninguém além de quem cozinhou consegue prová-lo.
Lição real deste próprio projetoRodar só "npm run build" nunca é suficiente — é obrigatório rodar "pm2 restart saindo-do-zero" logo depois, porque o processo do PM2 não recarrega sozinho quando o build muda em disco. Foi exatamente esse detalhe que fez o Módulo 3 "sumir" do site na primeira tentativa de deploy.
reconhecer 2 — deploypendente
Depois de rodar um build novo do projeto, o que ainda falta pra essa mudança aparecer de fato em produção (neste projeto)?
ANada, o build já atualiza o site sozinho
BReiniciar o processo do PM2, pra ele carregar os arquivos novos gerados pelo build
CRecriar o domínio do zero
02 — DESENVOLVIMENTO X PRODUÇÃO
O mesmo código, dois contextos com regras diferentes
O ambiente de desenvolvimento, visto no Módulo 11, roda o mesmo código-base do ambiente de produção — mas com dados de teste, sem consequência real se algo quebrar, e frequentemente com ferramentas extras de depuração ligadas. Produção roda com dados reais, precisa ficar no ar de forma estável, e qualquer erro afeta usuários de verdade na hora em que acontece.
Metáfora: é a diferença entre dirigir num simulador e dirigir na rua — os comandos são os mesmos, mas só na rua um erro tem consequência real pra outras pessoas.
Por que isso importaAo validar uma sugestão da IA que mexe em dados ou infraestrutura, a pergunta certa é sempre "isso foi testado em desenvolvimento antes de tocar produção" — o mesmo princípio do ambiente de staging, visto no Módulo 11.
reconhecer 3 — desenvolvimento x produçãopendente
O que normalmente diferencia o ambiente de desenvolvimento do de produção, além dos dados usados?
AProdução geralmente roda o mesmo código, mas precisa de estabilidade e afeta usuários reais imediatamente se algo falhar
BDesenvolvimento e produção sempre usam linguagens de programação diferentes
CProdução nunca reflete o mesmo código escrito em desenvolvimento
desafio final do módulo 13: Você acabou de rodar npm run build na VPS depois de uma mudança de código, e o site em produção continua mostrando a versão antiga. Qual é o passo que provavelmente falta, e por quê?
desafio finalpendente
Escolha a alternativa mais coerente com os conceitos deste módulo.
ARodar "pm2 restart" no processo da aplicação — o build sozinho não faz o processo já em execução recarregar os arquivos novos
BTrocar o domínio do site, já que o build não teria efeito nenhum
CNada — builds em produção sempre aparecem automaticamente, sem precisar de mais nenhum passo