Questão de Engenharia de Software — Geral — FCC 2025
Engenharia de Software›Geral
Código
fc150527
Banca
FCC
Órgão
TRF 4
Ano
2025
Cargo
AJ TRF4
Na implantação de um novo sistema de gestão processual, a equipe de analistas de um tribunal foi orientada a adotar práticas alinhadas aos princípios de DevOps e DevSecOps, além de estabelecer um fluxo organizado de versionamento de código-fonte utilizando Glt e Gitlab. No planejamento do pipeline de integração contínua e entrega contínua (CI/CD), optou-se por implementar uma estratégia de ramificação baseada no Gitflow para gerenciar versões de produção e desenvolvimento simultaneamente. Considerando essas práticas, a estruturação adequada desse fluxo envolve
Aa utilização de branches especificas como "develop" para integração de novas funcionalidades e "master/main" para versões estáveis de produção.
Ba manutenção de uma branch principal voltada à estabilização do código, combinada com merges diretos de funcionalidades em produção sempre que aprovadas.
Ca criação de fluxos de entrega contínua estruturados por desenvolvedor, com controle individual de versão descartando a dependência de branches colaborativas.
Da definição de pipelines segmentados por ambiente, com branches de longa duração integrando demandas operacionais e funcionais em ciclos contínuos.
Eo uso de uma abordagem centralizada em uma única branch de desenvolvimento principal, com validações manuais antes da publicação das versões.
Revelar gabarito e comentário▾
GabaritoA — a utilização de branches especificas como "develop" para integração de novas funcionalidades e "master/main" para versões estáveis de produção.
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”.
Gitflow: estratégia de ramificação para CI/CD
Gabarito: letra A. A alternativa A descreve corretamente o Gitflow, que utiliza branches específicas como develop para integrar novas funcionalidades e master/main para versões estáveis de produção. Essa é a essência do modelo: separar o desenvolvimento contínuo da estabilidade do que já está em produção.
O Gitflow é um modelo de ramificação (branching model) para Git, criado por Vincent Driessen, que organiza o fluxo de trabalho em torno de branches com papéis bem definidos. Ele é especialmente útil em cenários onde há desenvolvimento contínuo e releases planejadas, como no caso de um sistema de gestão processual em um tribunal. A ideia central é que o código em master/main esteja sempre em estado de produção, enquanto o desenvolvimento ativo acontece em develop e em branches auxiliares.
A estrutura do Gitflow envolve:
master/main: contém o código de produção, sempre estável e pronto para deploy. Cada commit nessa branch representa uma versão publicada.
develop: branch de integração, onde as funcionalidades são mescladas e testadas antes de irem para produção.
feature/*: branches criadas a partir de develop para desenvolver novas funcionalidades. Ao concluir, são mescladas de volta em develop.
release/*: branches criadas a partir de develop para preparar uma nova versão, permitindo correções finais e ajustes antes do merge em master.
hotfix/*: branches criadas a partir de master para correções urgentes em produção, que são mescladas tanto em master quanto em develop.
Esse modelo contrasta com abordagens mais simples, como o trunk-based development, onde todos trabalham em uma única branch principal. O Gitflow é mais adequado quando há necessidade de gerenciar múltiplas versões simultaneamente, como releases planejadas e correções de emergência.
A pegadinha da questão está em confundir o Gitflow com outras estratégias de ramificação ou com práticas de CI/CD que não envolvem branches específicas. A banca explora a tentação de escolher alternativas que mencionam conceitos vagos de DevOps, mas que não correspondem à estrutura real do Gitflow.
Guarde a distinção central: no Gitflow, develop é a branch de integração de novas funcionalidades, e master/main é a branch de produção estável. É exatamente esse par que separa a alternativa correta das demais.
Alternativa A — ✅ Correta ⟵ GABARITO
A alternativa A descreve com precisão o Gitflow: a branch develop é usada para integrar novas funcionalidades, enquanto master/main é reservada para versões estáveis de produção. Essa é a estrutura fundamental do modelo, que permite desenvolvimento contínuo sem comprometer a estabilidade do que já está publicado.
Alternativa B — ❌ Incorreta
A alternativa B menciona "merges diretos de funcionalidades em produção sempre que aprovadas", o que contraria o Gitflow. Nesse modelo, funcionalidades são desenvolvidas em branches feature/*, mescladas em develop e, posteriormente, em release/* antes de chegarem a master. Não há merge direto de funcionalidades em produção; isso seria uma característica de outras estratégias, como o trunk-based development com deploy contínuo.
Alternativa C — ❌ Incorreta
A alternativa C propõe "controle individual de versão descartando a dependência de branches colaborativas", o que é o oposto do Gitflow. O Gitflow depende de branches colaborativas e de um fluxo de integração bem definido. A ideia de branches individuais sem colaboração não corresponde a nenhuma prática recomendada de versionamento em equipe.
Alternativa D — ❌ Incorreta
A alternativa D fala em "branches de longa duração integrando demandas operacionais e funcionais em ciclos contínuos", o que não descreve o Gitflow. No Gitflow, as branches feature/* são de curta duração, e a integração é feita em develop. A descrição é vaga e não corresponde à estrutura específica do modelo.
Alternativa E — ❌ Incorreta
A alternativa E propõe "uma abordagem centralizada em uma única branch de desenvolvimento principal", o que é o oposto do Gitflow. O Gitflow é caracterizado por múltiplas branches com papéis distintos, não por uma única branch central. Essa descrição se aproxima mais do trunk-based development, mas mesmo assim com validações manuais, o que não é o foco do Gitflow.