Sistemas de Controle de Versão (SCV), tais como o Mercurial, o GIT e o SVN, são ferramentas indispensáveis para apoiar as melhores práticas de desenvolvimento de sistemas. Os SCVs atualmente disponíveis possuem grande flexibilidade para se adaptar ao fluxo de trabalho de um time e suas práticas de desenvolvimento. No GIT, essa customização do fluxo de trabalho para um time ou projeto é comum, e muitos desses fluxos de trabalho utilizam uma abordagem conhecida como ramificação de recurso (Feature Branch). Uma possível limitação dessa abordagem seria o(a):
- A)diminuição da velocidade de desenvolvimento. A necessidade de utilização de rebase quando uma funcionalidade é finalizada aumenta a complexidade do desenvolvimento;
Errada, porque o uso de rebase pode aumentar a complexidade em alguns cenários, mas isso não é a limitação principal cobrada aqui.
- B)indisponibilidade de dados de auditoria. Existe perda parcial do histórico do repositório quando é realizado o merge de um ramo (Branch);
Errada, porque o merge não elimina o histórico de auditoria do repositório; o Git preserva rastreabilidade das alterações.
- C)impacto na integração contínua. Se o ciclo de entrega de funcionalidade de um time é longo, aumentam os riscos e desafios dos merges e integrações;
Certa, porque ciclos longos em feature branches aumentam conflitos, dificultam merges e prejudicam a integração contínua.
- D)menor qualidade funcional. O novo fluxo de trabalho dificulta a elaboração de testes de aceitação em função da separação de funcionalidades em diferentes ramos (Branches);
Errada, porque a separação em branches não reduz a qualidade funcional nem impede a elaboração de testes de aceitação.
- E)menor qualidade do código. O novo fluxo de trabalho dificulta a execução de revisão de código (Code Review) pela imposição de pull requests e merge reviews.
Errada, porque pull requests e code review tendem a melhorar, e não piorar, a qualidade do código.
Gabarito: C
A estratégia de Feature Branch no Git é aquela em que você cria um ramo para desenvolver uma funcionalidade específica e só depois integra tudo ao ramo principal. Isso ajuda a organizar o trabalho, isolar mudanças e permitir que várias pessoas avancem ao mesmo tempo sem bagunçar o código principal. É quase como trabalhar em mesas separadas e só juntar tudo no final. O ponto fraco dessa abordagem aparece quando o ciclo de entrega fica longo. Se cada funcionalidade demora muito para ficar pronta, os ramos começam a se afastar demais entre si e do branch principal, o que aumenta o risco de conflitos na hora do merge. A integração fica mais trabalhosa, os conflitos ficam mais chatos e o time passa a gastar energia “apaziguando” branches em vez de entregar valor. Por isso o gabarito é a letra C: a feature branch pode impactar negativamente a integração contínua quando as entregas são longas, porque dificulta merges frequentes e integrações constantes. A doutrina de engenharia de software e boas práticas de DevOps recomendam justamente o contrário: branches curtos, integrações frequentes e automação para reduzir atrito. Em resumo: feature branch é útil, mas não é mágica. Se o time demora demais para integrar, o Git começa a cobrar a conta em forma de conflitos, retrabalho e atraso na esteira de integração.