Estrutura do Repositório

Quando iniciamos um projeto, podemos seguir algumas práticas recomendadas para organizar o repositório para uma melhor contribuição da equipe e uma estrutura de projeto mais elegante.

Utilizamos para a criação dos repositórios GIT, conforme configuração dos servidores, que são mantidos pelo 60pportunities.

Nomenclatura do Repositório¶

Por padrão iremos impedir que certos caracteres sejam incluídos no nome do repositório.

Embora não haja uma maneira errada de nomear um repositório, alguns nomes são melhores queoutros.

O comprimento do repositório não deve conter mais de 64 caracteres Unicode e não pode seridêntico a nenhum outro nome de repositório Git no projeto.

Todas essas sugestões estão sendo seguidas pelo criador automático.

Usando isso como diretriz, dividimos o repositório em 3(três) seções separadas porunderscore. Esse formato consiste em seções que definem:

• PRODUTO, FINALIDADE e ESTRUTURA DA LINGUAGEM.

• Deve se perceber as seguintes características: Descritivo, Legibilidade, Consistência, Contextual, Extensibilidade, Reuzabilidade e Sucinto.

mindmap
  root((repositorio))
    Monolito
      RepositorioAPP
         README.md
         package.json
         utils
           DigitoCpf.java
         libs
           jdbc.jar
         Documentacao
           Excel
           Word
    Monorepo
      Repositorio
        diretorioshared
        diretorioapps
        package.json
        webpack.config.js
        yarn.lock
    Polyrepo
      RepositorioDocumentacao
         Excel
         Word
      RepositorioFrontEnd
         html
         css
         js
      RepositorioBackEnd
         java
            src
            test

Monorepo¶

É um único repositório que armazena todo o seu código e recursos para cada projeto;

O repositório contém mais de um projeto lógico (por exemplo, um cliente iOS, Android e umaplicativo da Web);

Esses projetos provavelmente não estão relacionados, estão conectados livremente oupodem ser conectados por outros meios (por exemplo, via dependência ferramentas degerenciamento).

O repositório é grande de várias maneiras:

• Número de commits;
• Número de ramificações e/ou tags;
• Número de arquivos rastreados;
• Tamanho do conteúdo rastreado (conforme medido observando o diretório .git do repositório);
• Empresas usam monorepo, porque ele tem bons benefícios relacionados à manutenção de código, integração, reutilização de código, refatoração e mudanças em larga escala;
• Código compartilhado: Reutilize código de validação, componentes de interface do usuário e tipos na base de código;
• Reutilize o código entre o back-end e o front-end;
• Revisões de código mais eficaz: A maioria dos desenvolvedores agora entende a plataforma de ponta a ponta, levando a que mais bugs sejam identificados e corrigidos noestágio de revisão do código;
• Mudanças atômicas: Mude a API de um servidor e modifique os clientes que consomem essa API no mesmo commit. Você pode alterar um componente de botão em uma biblioteca compartilhada e os aplicativos que usam esse componente no mesmo commit. Isso evita o incômodo de tentar coordenar confirmações em vários repositórios;
• Compartilhamento de componentes comuns: Os desenvolvedores têm uma visão do que está acontecendo em todos os serviços e podem efetivamente criar componentes comuns;

Ferramentas Monorepo¶

Multirepo ou Polyrepo¶

Refere-se à organização de seus projetos, cada um em seus próprios repositórios separados. Esta é a arquitetura mais comum em uso e pode ser vista em grandes empresas e possui algumas vantagens:

• Propriedade: Como a base de código imita a arquitetura, uma pequena equipe pode possuir e desenvolver e implantar de forma independente a pilha completa de um microsserviço.
• Melhor escala: Bases de código menores são mais fáceis de gerenciar e levam a menos instâncias de ""Ninguém gosta de um conflito de mesclagem. (merge hell)"".
• Clones pequenos: A maioria dos SCMs, incluindo git, não oferece suporte à clonagem de partes de um repositório. Para grandes bases de código, clones, pulls e pushs levam uito tempo, o que é ineficiente.
• Controle de acesso: Pode ser aplicado no nível do projeto, pois cada funcionário tem acesso a uma pequena seção de projetos.

Modelo de Ramificação¶

Ao começar, é melhor manter as coisas simples e, portanto, inicialmente o GitHub Flow ou o desenvolvimento baseado em Trunk podem funcionar melhor. Eles também são ideais para equipes menores que exigem a manutenção de apenas uma única versão de um lançamento.

• Não existe estratégia perfeita;
• A estratégia que você escolher dependerá da sua equipe e da natureza e complexidade do seu projeto e por isso deve ser avaliada caso a caso;

Estratégias Branch¶

A maior vantagem de um branch Git é que ele é 'leve', o que significa que os dados consistem em uma série de snapshots, portanto, a cada commit que você faz, o Git tira uma foto da aparência dos seus arquivos naquele momento earmazena uma referência para esse snapshot.

Isso significa que essas ramificações não são apenas cópias do sistema de arquivos, mas simplesmente um ponteiro para o commit mais recente.

Um branch é essencialmente uma referência ou um ponteiro para o último commit em umdeterminado contexto.

À medida que você cria novos commits no novo branch, o Git cria novos ponteiros para rastrear as alterações. As ramificações do Git, então, podem ser vistas como um ponteiro para um instantâneo de suas alterações.

As ramificações do Git permitem que os desenvolvedores diverjam da ramificação principal criando ramificações separadas para isolar alterações de código.

• O branch padrão no Git é o branch main;
• Diversas estratégias de ramificação são usadas NÃO há um modelo correto ou errado;

Gitando¶

Id	emoji	Tipo	Descricao
✨		feat	Introduzir novos recursos
🐛		bug	Corrigir bug
🚑		hotfix	Correção crítica
📝		docs	Adicionar ou atualizar documentação
🌀		refactor	Refatorar código
⏪		revert	Reverter alterações
🔨		script	Adicione ou atualize scripts de desenvolvimento
🔖		release	Tags de lançamento/versão
🚮	:trash:	deadcode	Remover código morto
🔇		rmlog	Remover registros

Solicitações Pull Request¶

Escrever boas descrições de solicitações pull request é uma ótima maneira de ajudar os revisores a saber o que esperar ao revisar o código e documentações obrigatórias.

Um modelo de solicitação pull é um arquivo contendo texto Markdown que é adicionado à descrição da solicitação pull quando a solicitação pull é criada.

O Azure Repos permite criar diversos tipos de templates, porem iremos utilizar Modelos de pull request para específicas branches.

Template de Documentos¶

Verifique se já há no repositório(s) os templates criados para as branches:

• No Azure-Devops: <repository root>/.azuredevops/pull_request_template/branches/;
• No GitHub: <repository root>/.github/ISSUE_TEMPLATE/;

Exemplo de Template¶

#  Inclusão da funcionalidade cadastrar funcionario

## Descrição
Termindo o desenvolvimento em golang da tela de cadastramento de fornecedor.

## Contexto
-

## Mudanças Propostas
-

## Impacto nas Tabelas e Dados
Criado a tabela XXXXXXXXX

## Testes Realizados
Foram realizados os testes conforme atachado no material:

## Screenshots (se aplicável)
Se possível e relevante, adicione capturas de tela que mostrem o resultado ou comportamentoapós a execução do código PL/SQL.

## Problemas Relacionados
Adicione links para problemas (issues) relacionados a este Pull Request, se houver.

## Checklist
- [ ] O código PL/SQL foi revisado quanto à segurança e otimização, seguindo os padrõesSQUALE;
- [ ] Os comentários no código estão atualizados e são claros para facilitar a compreensão;
- [ ] As queries de exemplo foram testadas e fornecem resultados corretos;
- [ ] A documentação foi atualizada para refletir as mudanças implementadas, se aplicável;
- [ ] Os testes automatizados foram executados e estão passando;
- [ ] Testes manuais foram realizados para verificar as mudanças;
- [ ] Todos os testes foram documentados;
- [ ] Aprovado por revisor (ou revisores) da equipe de especialistas em Banco de DadosOracle;

## Notas do Revisor (não preencha)
Esta seção será preenchida pelo revisor durante a análise do Pull Request.

• Após a validação do pessoal de Qualidade, este deverá efetuar um cherry-pick, da branch de qualidade para a sprint.
• Após a validação do pessoal de Qualidade, este deverá efetuar um cherry-pick, da branch de sprint para a main.
• Em resumo:
  • Durante o sprint, todas as alterações de código são enviadas para esse branch;
  • E sempre que o código quiser ser testado no ambiente de desenvolvimento, basta criar Pull Request para o branch qualidade;