Considere a seguinte situação hipotética:
Uma universidade possui um sistema acadêmico desenvolvido em PHP com framework próprio.
Atualmente, o deploy é feito manualmente via FTP (File Transfer Protocol) para o servidor de
produção. Em períodos de matrícula, erros de publicação causam indisponibilidade do sistema.
A equipe decidiu implementar um pipeline de CI/CD (Integração Contínua/Implantação
Contínua). O repositório está no GitLab e os servidores utilizam Linux. É obrigatório garantir:
versionamento rastreável, execução automática de testes antes do deploy e controle formal
sobre liberações para produção.
Assinale a alternativa que atende de forma CORRETA aos requisitos técnicos e de governança
para o novo processo de deploy:

Question

Considere a seguinte situação hipotética:
Uma universidade possui um sistema acadêmico desenvolvido em PHP com framework próprio.
Atualmente, o deploy é feito manualmente via FTP (File Transfer Protocol) para o servidor de
produção. Em períodos de matrícula, erros de publicação causam indisponibilidade do sistema.
A equipe decidiu implementar um pipeline de CI/CD (Integração Contínua/Implantação
Contínua). O repositório está no GitLab e os servidores utilizam Linux. É obrigatório garantir:
versionamento rastreável, execução automática de testes antes do deploy e controle formal
sobre liberações para produção.
Assinale a alternativa que atende de forma CORRETA aos requisitos técnicos e de governança
para o novo processo de deploy: Alternativa A: Criar um pipeline no GitLab CI, que execute testes na criação de branches de feature e
realizar o deploy em produção, a partir da branch principal, sempre que houver atualização
validada pelo desenvolvedor responsável no GitLab CD. Ou Alternativa B: Configurar um pipeline no GitLab CI para executar testes automatizados a cada merge request, exigir aprovação para merge na branch principal e realizar deploy em produção, a
partir de tags versionadas geradas após a aprovação.  Ou Alternativa C: Configurar pipeline para executar testes a cada commit na branch principal, realizar
deploy automático após a conclusão bem-sucedida do job de build, em seguida, gerar
artefato versionado com o registro do deploy no GitLab CD. Ou Alternativa D: Implementar pipeline no GitLab CI com etapas de build e testes automatizados, gerar
artefato versionado e permitir que a equipe de infraestrutura realize o deploy
manualmente, utilizando o artefato mais recente aprovado.

Qconcursos · Accepted Answer

Alternativa [B] Configurar um pipeline no GitLab CI para executar testes automatizados a cada merge request, exigir aprovação para merge na branch principal e realizar deploy em produção, a
partir de tags versionadas geradas após a aprovação.  Gabarito: BFundamento decisivo: O ponto decisivo era identificar a única alternativa que reunia teste automatizado antes da liberação, rastreabilidade por versão e aprovação formal para produção.Tema central: CI/CD com governança de liberaçãoAnálise das alternativasAErradaEstá errada porque coloca os testes na criação de branches de feature e prevê deploy da branch principal com validação pelo desenvolvedor responsável, sem controle formal claro de liberação nem uso de tag para rastrear a versão promovida.BCertaA alternativa B está correta porque estrutura o fluxo de CI/CD com os três mecanismos pedidos. Os testes automatizados no merge request garantem validação antes da promoção da mudança; a exigência de aprovação para merge na branch principal cria o ponto formal de controle de liberação; e o deploy em produção a partir de tags versionadas fornece rastreabilidade objetiva da versão efetivamente liberada. Esse encadeamento atende, ao mesmo tempo, ao requisito técnico de teste prévio e aos requisitos de governança de aprovação formal e versionamento rastreável.CErradaEstá errada porque os testes ocorrem apenas na branch principal e o deploy automático acontece após o build bem-sucedido, sem controle formal prévio de liberação para produção. Além disso, o artefato versionado é gerado depois do deploy.DErradaEstá errada porque, embora tenha build, testes e artefato versionado, mantém o deploy manual com base no artefato mais recente aprovado, sem descrever mecanismo formal de liberação equivalente à aprovação de merge somada a tag de release.Pegadinha da questãoA confusão explorada foi fazer parecer que automação de testes ou artefato aprovado bastariam. Não bastam: a questão cobrava também controle formal de liberação e rastreabilidade explícita da versão de produção, melhor representada por aprovação de merge e tag versionada.Dica para questões semelhantesQuando o enunciado exigir governança de deploy, verifique separadamente: teste prévio, ponto formal de aprovação e mecanismo explícito de rastreabilidade da release.Deploy a partir da branch principal não equivale, por si só, a versão rastreável de produção; tag versionada atende melhor esse requisito.Validação informal do desenvolvedor ou uso do artefato mais recente não substituem um fluxo formal de liberação descrito no processo.Se a alternativa atender bem ao CI, mas não mostrar como a produção é formalmente liberada e identificada por versão, ela fica incompleta.

🎯 Saiba o que estudar

🎯 Saiba o que estudar

Considere a seguinte situação hipotética: Uma universidade ...

Gabarito comentado

Gabarito: B

Clique para visualizar este gabarito

Questões de assuntos semelhantes

Provas relacionadas