Com o objetivo de nos organizarmos em relação aos nossos diversos ambientes de desenvolvimento, utilizaremos metodologias já adotadas em empresas de tecnologia para versionamento de código em todas as aplicações da Caplink.
Introdução
Para este fim, usaremos a ferramenta GIT como nosso sistema de controle de versão de código, hospedada em um cloud provider chamado GitLab.
Metodologias que utilizaremos
As metodologias a seguir devem servir como um guia para nos auxiliar na organização de nossos projetos usando o git. Devemos poder adaptá-las para nossa realidade em cada projeto, idealmente utilizando das boas práticas já testadas por times maiores.
São as seguintes:
Cada metodologia abaixo traz formas diferentes de organizarmos o fluxo do trabalho através do uso de branches com suas convenções específicas.
Metodologia github-flow
Para projetos menores ou que não possuem a necessidade de um controle rigoroso para cada ambiente, recomendamos utilizar o github-flow .
Os projetos que hoje utilizam algo semelhante são:
Organização do controle de versão
Branches - Master (ou Main)
- É a única branch permanente nessa metodologia. Atualizações realizadas nas Feature Branches, após revisadas, engatilham o CICD e as atualizações vão para staging.
- Caso faça sentido pro projeto, um determinado momento no histórico pode ser escolhido pelo time para ir para produção. Ainda definido se iremos fazer isso com tags ou somente com o controle da pipeline.
Branches - Feature
- Cada funcionalidade a ser desenvolvida é uma branch temporária que deve durar até essa funcionalidade estar em produção. Essa branch deve conter em seu título o título do card no clickup e seu código (hash)
Tags
- Ainda avaliando se vamos usar o sistema de tags para esses projetos.
Metodologia git-flow
Seguiremos o modelo git-flow (link) para projetos que possuem um nível de complexidade que exige um controle mais rigoroso sobre o versionamento do que está sendo lançado em produção, visando facilitar esse processo conforme esses projetos crescem em complexidade.
Os seguintes projetos irão usar essa metodologia:
Organização do controle de versão
Branches - Master (ou Main) - Permanente
- É uma branch permanente que guarda código que está rodando no servidor de produção
- Cada tag marcará um momento no histórico em que os commits deverão ir para o servidor produção
Branches - Release (nome customizado)
- Deve possuir o nome “release-{versão}”
- Exemplo: “release-v0.2”
- Commits nessa branch já são funcionalidades que devem estar em correto funcionamento, e podem ser testadas para ir para produção
- Cada commit desta branch deverá engatilhar uma tarefa no CICD e enviar automaticamente o código para o servidor staging
- Quando o teste for realizado, deverá ser pedido um MR para production. Cada release realizado deve (manualmente por ora) estar ligado à uma tag (versão) para produção
Branches - Develop - Permanente
- É uma branch permanente que permanece em constante atualização pelo time de desenvolvimento
- Cada commit nessa branch irá engatilhar o CICD e atualizar automaticamente o servidor de desenvolvimento.
- Fica à responsabilidade do time de desenvolvimento lidar com merges caso necessário.
- Quando essa branch estiver com o código estável, ou seja, passou por code review, torna-se possível a realização do merge para release
Branches - Feature branches
- Nós tratamos cada card no clickup como uma branch. Isso permite que o escopo de uma funcionalidade esteja bem delimitado. Ao terminar a funcionalidade e ela estar em um estado “estável”, ela deverá ser movida para a branch develop e a branch excluída.
Branches - Hotfix
- Trataremos branches urgentes da mesma forma que feature branches, seguindo a nomenclatura do clickup e delegando a priorização dessas features para lá.
Tags
- Deve sempre acompanhar um release na master. Sempre usaremos annotated tags para descrever momentos no histórico em que ‘pacotes de entregas’ foram realizados.