Questão de Engenharia de Software — Github e Gitlab — FCC 2025

Gestão de Branches e Boas Práticas de Versionamento

Gabarito: letra E. A organização eficiente do versionamento em equipes que adotam DevOps/DevSecOps exige a criação de ramificações específicas para novas funcionalidades, correções e releases, alinhando-se às boas práticas de versionamento, como o GitFlow. As demais alternativas contrariam princípios fundamentais do DevOps, como automação, integração contínua e validação em todas as etapas do pipeline.

O versionamento de código é a prática de gerenciar e controlar as alterações feitas em um projeto de software ao longo do tempo. Ferramentas como Git, GitHub e GitLab permitem que múltiplos desenvolvedores trabalhem simultaneamente, rastreiem cada modificação e mantenham um histórico completo. A organização eficiente desse processo é crucial para a qualidade, a colaboração e a rastreabilidade do código.

Uma das estratégias mais consagradas para organizar o versionamento é o GitFlow. Nesse modelo, o repositório é estruturado com branches (ramificações) que têm papéis bem definidos:

• Main/Master: contém o código estável, pronto para produção.

• Develop: onde o desenvolvimento é integrado, servindo como base para as features.

• Feature branches: ramificações temporárias criadas para desenvolver novas funcionalidades, isolando o trabalho em andamento.

• Release branches: preparam uma nova versão para produção, permitindo ajustes finais e correções de bugs.

• Hotfix branches: corrigem bugs críticos em produção, de forma rápida e isolada.

Essa estrutura permite que a equipe trabalhe de forma paralela e organizada, sem que alterações incompletas ou experimentais afetem a estabilidade do código principal. A alternativa E reflete exatamente essa prática, ao mencionar a criação de ramificações específicas para funcionalidades, correções e releases.

No contexto de DevOps e DevSecOps, a automação é um pilar central. Os pipelines de CI/CD automatizam a integração, os testes e a implantação, garantindo feedback rápido e detecção precoce de falhas. A gestão de branches deve estar integrada a esses pipelines, de modo que cada merge ou push em uma branch específica dispare automaticamente as validações necessárias. Qualquer abordagem que sugira processos manuais, validações apenas em fases finais ou registro informal de alterações vai contra os princípios de automação e melhoria contínua.

A banca explora a confusão entre práticas que parecem razoáveis, mas que contrariam os fundamentos do DevOps. A pegadinha está em alternativas que propõem centralização excessiva, processos manuais ou simplificação inadequada, quando a resposta correta é aquela que reflete a organização estruturada e automatizada do versionamento.

Guarde o critério decisivo: a gestão de branches deve ser organizada e estruturada, com ramificações específicas para cada tipo de trabalho, e integrada à automação do pipeline. É exatamente nesse ponto que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que o fluxo Git baseado em branches centraliza o trabalho em main, utilizando branches secundárias apenas em situações de exceção. Isso contraria a prática recomendada, que é justamente o oposto: o trabalho é organizado em branches específicas (features, releases, hotfixes), e a main (ou master) é mantida estável, recebendo apenas código validado e integrado. A centralização excessiva em main sem ramificações adequadas dificulta o trabalho paralelo e aumenta o risco de conflitos e instabilidade.

Alternativa B — ❌ Incorreta

Propõe que o merge entre branches seja conduzido manualmente, priorizando decisões da equipe técnica, ainda que sem validações automatizadas vinculadas ao pipeline. Isso vai diretamente contra o princípio da automação no DevOps. Os merges devem ser validados automaticamente por pipelines de CI/CD, que executam testes, análises estáticas e outras verificações antes da integração. A automação garante feedback rápido e reduz erros humanos, sendo essencial para a qualidade e a segurança do código.

Alternativa C — ❌ Incorreta

Sugere que o versionamento de código seja adaptado de forma simplificada para projetos internos, com registro informal de alterações e controle local de mudanças. Essa abordagem é inadequada, pois mesmo projetos internos se beneficiam de boas práticas de versionamento, como branches organizadas, commits descritivos e integração contínua. O registro informal e o controle local dificultam a rastreabilidade, a colaboração e a auditoria, além de contrariar a cultura de automação e transparência do DevOps.

Alternativa D — ❌ Incorreta

Afirma que pipelines de CI/CD devem executar validações principalmente em ambientes de homologação, sendo dispensáveis na etapa de publicação em produção. Isso é um erro grave. As validações automatizadas devem ocorrer em todas as etapas do pipeline, incluindo a publicação em produção. A automação na etapa de produção é fundamental para garantir que apenas código testado e aprovado seja implantado, reduzindo riscos e permitindo implantações frequentes e confiáveis. Dispensar validações na publicação em produção seria um retrocesso e aumentaria a probabilidade de falhas.

Alternativa E — ✅ Correta ⟵ GABARITO

A alternativa correta afirma que a gestão de branches deve ser organizada com a criação de ramificações específicas para novas funcionalidades, correções e releases, alinhando-se às boas práticas de versionamento. Isso corresponde exatamente ao modelo GitFlow, que estrutura o repositório com branches dedicadas para cada tipo de trabalho, garantindo isolamento, organização e integração controlada. Essa prática é amplamente recomendada e se alinha aos princípios de DevOps e DevSecOps, que valorizam a automação, a colaboração e a qualidade contínua.

Gabarito: letra E