Questão de Engenharia de Software — Métricas de Software — CESPE / CEBRASPE 2023

12 Factors: Build, Release e Execução

Gabarito: Certo (C). A afirmativa está correta porque os 12 fatores (12-Factor App) preconizam que cada release deve ter um ID único e que os estágios de build, release e execução devem ser estritamente separados, impossibilitando alterações no código em tempo de execução. Essa é uma das práticas centrais da metodologia, que visa garantir consistência e reprodutibilidade entre ambientes.

Os 12 fatores (ou 12-Factor App) são uma metodologia criada por Adam Wiggins, da Heroku, para construir aplicações web modernas, escaláveis e de fácil manutenção. O fator 10, chamado "Dev/prod parity" (paridade entre desenvolvimento e produção), e o fator 11, "Logs", são frequentemente citados, mas o que a questão aborda é o fator 10, que trata da separação estrita entre os estágios de build, release e execução. Vamos entender cada um:

• Build (Compilação): é o estágio em que o código-fonte é transformado em um artefato executável (um pacote, um binário, um container). Aqui, o código é compilado, as dependências são baixadas e os assets são gerados.

• Release (Liberação): é o estágio em que o artefato do build é combinado com a configuração específica do ambiente (variáveis de ambiente, chaves de API, etc.) para criar um release. Cada release tem um ID único (como um timestamp ou um número de versão) e é imutável — uma vez criado, não pode ser alterado.

• Execução (Runtime): é o estágio em que o release é executado no ambiente de produção. Aqui, a aplicação roda e atende às requisições dos usuários.

A separação estrita entre esses estágios é fundamental. Se um release é imutável, não é possível fazer alterações no código em tempo de execução, pois isso quebraria a rastreabilidade e a consistência. Se um problema é encontrado em produção, a solução é criar um novo release a partir de um novo build, não alterar o código em execução. Isso garante que o que está rodando em produção é exatamente o que foi testado e aprovado. A questão afirma que "Release deve sempre ter um ID de Release exclusivo" — isso é verdade, pois cada release é uma combinação única de artefato e configuração. E afirma que "torna-se impossível fazer alterações no código em tempo de execução, pois não há como propagar essas alterações de volta ao estágio de Build" — também é verdade, pois o release é imutável e a execução não tem como alterar o código-fonte. A pegadinha aqui é que muitos candidatos podem pensar que é possível "corrigir" um problema em produção alterando o código diretamente, mas a metodologia dos 12 fatores proíbe isso. A única forma de corrigir é criar um novo build e um novo release. Essa é uma distinção importante entre o modelo tradicional (onde se altera o código em produção) e o modelo moderno de DevOps/12 fatores.

Item — ✅ CERTO

A afirmativa está correta. Os 12 fatores (12-Factor App) estabelecem que:

1. Cada release deve ter um ID exclusivo: isso é verdade, pois cada release é uma combinação única de artefato (build) e configuração. O ID permite rastrear exatamente o que está rodando em produção.

2. Separação estrita entre Build, Release e Execução: a metodologia define esses três estágios como distintos e sequenciais. Não há como voltar da execução para o build.

3. Impossibilidade de alterar o código em tempo de execução: como o release é imutável, não é possível propagar alterações de código de volta ao estágio de build. Qualquer correção exige um novo build e um novo release.

Portanto, a afirmativa está Certa. Gabarito: Certo (C)