Questão de Arquitetura de Computadores — Pipeline — FCPC 2025
Arquitetura de Computadores›Pipeline
Código
qg456742
Banca
FCPC
Órgão
UFC
Ano
2025
Nível
Superior
Cargo
Analista de Tecnologia da Informação / Área: Arquitetura e Desenvolvimento de Sistemas – Front-End
Em um projeto, um analista de TI precisa garantir que uma nova feature seja integrada sem conflitos com o código existente. Após a implementação, a feature precisa passar por testes automatizados antes de ser incorporada ao branch principal, assegurando que não introduza erros. Assinale a alternativa que apresenta a opção mais eficiente para alcançar essa integração de forma segura e automatizada.
ACriar um pipeline no GitLab CI para validar e testar automaticamente o código da nova feature antes do merge no branch principal.
BConfigurar scripts de integração contínua no GitLab para compilar o código e realizar o merge automaticamente após cada commit.
CRealizar o merge manual da feature no branch principal e, em seguida, rodar testes de unidade locais para garantir a integridade do código.
DUsar o Jenkins apenas para compilar o código e delegar a responsabilidade dos testes para o ambiente de produção.
Revelar gabarito e comentário▾
GabaritoA — Criar um pipeline no GitLab CI para validar e testar automaticamente o código da nova feature antes do merge no branch principal.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Integração Contínua e Pipelines CI/CD
Gabarito: letra A. A prática de Integração Contínua (CI) estabelece que, antes de mesclar uma nova funcionalidade ao branch principal, o código deve ser validado por testes automatizados. A criação de um pipeline no GitLab CI que executa esses testes automaticamente antes do merge é a abordagem mais eficiente e segura.
A banca testa o conhecimento do fluxo correto de CI/CD: automatizar a validação antes da integração, evitando que código defeituoso chegue ao branch principal. As demais alternativas falham ao propor integração sem testes adequados ou testes em estágio inadequado.
1Commit da feature
2Pipeline automatizado
3Testes de validação
4[+] Merge no branch principal
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
Criar um pipeline no GitLab CI que valide e teste automaticamente o código antes do merge segue exatamente o princípio de CI/CD: execução automatizada de testes como etapa obrigatória antes da integração. Isso garante que o branch principal permaneça estável.
Alternativa B — ❌ Incorreta
A alternativa propõe realizar o merge automaticamente após cada commit, sem validação prévia. Isso contraria o objetivo da CI, que é justamente testar antes de integrar. Fazer merge automático sem testes pode introduzir erros no branch principal.
Alternativa C — ❌ Incorreta
Realizar o merge manual e depois executar testes locais é inseguro: o merge já foi feito, potencialmente afetando o branch principal com código sem validação. Além disso, testes locais não substituem a automação e podem ser inconsistentes.
Alternativa D — ❌ Incorreta
Usar Jenkins apenas para compilar e delegar os testes para o ambiente de produção é altamente arriscado. Testes em produção podem causar indisponibilidade ou expor falhas aos usuários. A prática correta é testar em ambiente de homologação antes de qualquer implantação.
NÃO CAIA NESSA!
A alternativa B é a principal armadilha: ela menciona "integração contínua" e "scripts", mas erra ao fazer o merge automaticamente sem testes. O candidato pode associar CI a automatização e esquecer que a validação deve preceder a integração.
PEGA ESSA DICA!
Em questões de CI/CD, lembre-se da sequência: commit → testes automatizados → merge (se testes passarem). Nunca inverta a ordem. Ferramentas como GitLab CI, Jenkins ou GitHub Actions seguem esse mesmo padrão.