Versionamento

1. Visão Geral

A área de Versionamento é responsável por gerenciar a integridade, a rastreabilidade e a evolução dos códigos do software ao longo do tempo. O objetivo é estabelecer uma fonte única do projeto, assegurando que o trabalho simultâneo de múltiplos desenvolvedores não gere conflitos destrutivos e que qualquer versão anterior do software possa ser recuperada.

Aqui, vamos definir as regras de colaboração entre o Desenvolvimento e a Entrega, garantindo que o histórico de mudanças seja auditável e organizado.

2. Fundamentos Teóricos

A prática de versionamento nesta organização é fundamentada nas seguintes Áreas de Conhecimento (KAs) propostas pelo SWEBOK v4:

• Software Configuration Management (Cap. 8): O núcleo do versionamento.

• Software Quality (Cap. 12): Utilização de revisões de código (Code Reviews/Pull Requests) como filtro de qualidade antes da integração do código à base principal.

3. Principais Responsabilidades

Arquivo:Fluxo Versionamento git.jpeg

A atuação é contínua durante todo o fluxo de trabalho da equipe:

• 3.1. Na Fase de Codificação (Development)

Nesta etapa, o Versionamento define as regras para os desenvolvedores.

Ação: Estabelecer a Branching Strategy, convenções de nomenclatura para branches e commits e garantir a proteção das branches principais contra escritas diretas.

• 3.2. Na Fase de Integração (Merge)

Essa responsabilidade é crítica. Envolve incorporar novas funcionalidades ao código base sem quebrar o que já funciona.

Ação: Gerenciar os Pull Requests, resolver conflitos de fusão (Merge Conflicts), e assegurar que todo código integrado tenha passado por revisão e aprovação técnica.

4. Integração com o Time

Abaixo detalha-se como a área de Versionamento interage com as outras áreas da Software House:

4.1. Com Engenharia de Requisitos (Leonardo)

• Entrada: IDs das Histórias de Usuário ou Tarefas.

• Ação: Padronização das mensagens de commit para incluir referências aos requisitos (ex: "feat: #123 - Adiciona login").

• Rastreabilidade: Capacidade de listar exatamente quais linhas de código foram alteradas para atender a um requisito específico do Leonardo.

4.2. Com Integrações (Paula)

Entrada: Contratos de Interface e bibliotecas externas.

Ação: Gestão rigorosa de Semantic Versioning (SemVer). O Versionamento garante que mudanças que quebram a compatibilidade resultem em uma troca de versão Major (v1.0.0 -> v2.0.0), alertando os times de integração.

4.3. Com Q&A / Testes (Giovana)

• Entrada: Solicitação de versões estáveis para teste (Release Candidates).

• Ação: Criação de Tags de versão (ex: v1.0.0) e congelamento de código em branches específicas para permitir que o Q&A teste um código candidato sem interferências.

4.4. Com Operações (Samuel)

• Entrada: Política de Releases.

• Saída: Link para a Tag/Commit específico que deve ir para produção.

• Ação: Garantia de que o que está na branch main (ou master) é sempre um código estável e pronto para deploy (Imutabilidade da Release).

Referências e Leitura Recomendada

• SWEBOK v4: 8 (Configuration Mgmt) e 12 (Quality).
• Documentação Git
• Documentação Interna:

1. Engenharia de Requisitos - Leonardo
2. Integração - Paula
3. Q&A - Giovana
4. Operação - Samuel