Ciclo de desenvolvimento:

Para toda personalização realizada dentro do ambiente SmartERP, seguimos o seguinte fluxo:

Este processo nos garante uma segurança maior e uma maior transparência no que esta sendo disponibilizado dentro do seu ambiente.

Em termos gerais, após o desenvolvimento em máquina local (testado e homologado pelo desenvolvedor), o desenvolvedor deverá submeter as correções/melhorias para o repositório de fontes remoto. Com a confirmação da gravação dos artefatos, a topologia irá iniciar os processos de avaliação dos fontes - realizada pelo SonarQube (afim de mantermos a qualidade e regras aceitáveis para futuras migrações), compilar o fonte no RPO de específicos do cliente (cada topologia possui um RPO auxiliar exclusivo para cada environment), criar/atualizar o environment de homologação do cliente (este sempre será um espelho da branch criada) e posteriormente disponibilizar o ambiente ao cliente/projeto para testes.

Para realizarmos este processo, utilizamos a ferramenta de GIT para controle dos arquivos fontes e artefatos do FileSystem (protheus_data) do cliente e SonarQube.

Controle de Versão

O controle de versão é um sistema que registra as mudanças feitas em um arquivo ou um conjunto de arquivos ao longo do tempo, de forma que seja possível recuperar versões específicas.

O controle de versão permite reverter arquivos ou um projeto inteiro para um estado anterior, comparar mudanças feitas no decorrer do tempo, descobrir quem foi o último a modificar algo que pode estar causando problemas, quem introduziu um bug e quando isso ocorreu, além de muito mais. Usar um controle de versão, normalmente significa que se algo foi danificado ou se arquivos foram perdidos, facilmente será possível reavê-los. Além disso, você pode controlar tudo sem maiores esforços. 

Para maiores informações sobre o GIT e de como instala-lo, acesse: 8.1.1. SmartERP Protheus - Conhecendo e Instalando o GIT

Com adoção de um controle de versão dentro do SmartERP, precisaremos organizar as branches, afinal, são muitos os problemas que um projeto pode enfrentar: De bugs urgentes que devem ser corrigidos, a criação de inúmeras features em conjunto com releases agrupando os deploys relativos a essas features. Pensando nisso, adotamos o fluxo de trabalho utilizado pelo Git Flow, um modelo de organização de branches criado por Vincent Driessen que mais tarde se tornou uma excelente extensão ao Git, permitindo seu uso de forma fácil com qualquer repositório git

O que é o Git Flow?

Quando estamos trabalhando em times pequenos, é comum adotarmos pouco controle (às vezes até nenhum) sobre o fluxo de branches dos nosso repositórios, porém conforme a complexidade do projeto e equipe vão aumentando coisas que antes eram simples, como um hotfix, começam a se tornar difíceis de controlar.

O Git Flow é um modelo de conjunto de diretrizes que equipes de desenvolvimento podem seguir para organizar as branches.

Como Funciona

O Git Flow trabalha com diretrizes para a organização dos nossos branches, e por esse motivo ele estabelece padrões de nomes e funções para cada tipo de branch, são eles:

• master: contém o nosso código de produção, todo o código que estamos desenvolvendo, em algum momento será “juntado” com essa branch
• develop: contém o código do nosso próximo deploy, isso significa que conforme as features vão sendo finalizadas elas vão sendo juntadas nessa branch para posteriormente passarem por mais uma etapa antes de ser juntada com a master
• feature/*: são branches para o desenvolvimento de uma funcionalidade específica, por convenção elas tem o nome iniciado por feature/, por exemplo: feature/cadastro-usuarios. Importante ressaltar que essas branches são criadas sempre à partir da branch develop
• hotfix/*: são branches responsáveis pela realização de alguma correção crítica encontrada em produção e por isso são criadas à partir da master. Importante ressaltar que essa branch deve ser juntada tanto com a master quanto com a develop
• release/*: tem uma confiança maior que a branch develop e que se encontra em nível de preparação para ser juntada com a master e com a develop (caso alguma coisa tenha sido modificada na branch em questão)

É importante ressaltar, que sempre que uma branch hotfix/ ou release/ é mesclada com a master o Git Flow gera automaticamente tags facilitando assim uma eventual necessidade de mudarmos para uma versão mais antiga.

O processo de trabalho ficaria assim:

Aplicando na prática

Existe um plugin do Git que nos ajuda a executar todos os comandos de criação de branches, tags, etc, facilitando assim todo o processo.

1. Instalando o plugin

O Git Flow não é uma ferramenta padrão do Git, e por esse motivo precisamos antes de tudo realizar a instalação do plugin. No github tem o passo a passo de como instalar em todos os ambientes.

2. Clonando um repositório Git do ambiente SmartERP

Primeiramente vamos criar uma pasta em sua máquina e posteriormente realizar o GIT CLONE deste ambiente.

Em seguida, vamos obter o endereço e as credências para obtenção dos arquivos. Para ambos, devemos acessar o ambiente do TCLOUD e na aba builds copiar o endereço descrito no botão: Clonar repositório (https://git-codecommit.us-east-2.amazonaws.com/v1/repos/smartprotheus-cxxxxxx-repository) e o usuário e senha pelo botão credenciais.

Para maiores informações sobre o painel TCloud, acesse: 4. SmartERP Protheus - Painel Gestão do Ambiente

Dica: Caso trabalhe em diversos clientes que possuam GIT, recomendamos que baixe o repositório já informando o usuário e senha no git clone,

$ git clone usuario:senha@endereço do git

Exemplo: 

• Usuário: [email protected]
• Senha: asdfgh1234qwert
• Endereço do git: https://git-codecommit.us-east-2.amazonaws.com/v1/repos/smartprotheus-cxxxxxx-repository

$ git clone https://joao.dasilva%40.totvs.com.br:[email protected]/v1/repos/smartprotheus-cxxxxxx-repository

Importante: Temos que converter os caracteres especiais para a decimal, pois os caracteres especiais são entendidos como composto do endereço, neste caso, o @ do e-mail fica %40.

Após clonar o ambiente, será realizado o download de todo conteúdo do cliente salvo no repositório. De padrão temos as seguintes pastas/arquivos criados:

Importante: Na criação do repositório remote GIT, automaticamente serão criadas algumas pastas e estas estrutura deve ser mantida. 

• src: Pasta que contêm todos os fontes (.prw) e includes (*.ch) customizados, que serão compilados no RPO do ambiente
• protheus_data: Pasta que contêm todos os artefatos customizados que serão atualizados na RootPath(\proteus_data) do ambiente. Este é utilizado caso o cliente queira manter a versão de um artefato mesmo após a atualização do ambiente. Na prática, a cada atualização realizamos a cópia ou substituição de diversos artefatos dentro do volume do cliente e caso o cliente tenha personalizado um artefato atualizável, este será perdido.
• dictionary.json: Arquivo de configuração que contêm todos os projeto do Master Metadata (dicionários) que devem ser aplicados no ambiente
• .git: A pasta .git é uma pasta oculta e não deve ser alterada;

3. Inicializando o Git Flow

Vamos inicializar o Git Flow no nosso repositório:

$ git flow init

Algumas perguntas referentes à nomenclatura serão feitas, recomendo apenas apertar ENTER e não alterar nenhuma configuração aqui.

Interessante observar que apenas executando o comando acima já foi criado e feito o checkout para a branch develop.

4. Iniciando uma feature branch

Vamos realizar a criação de uma feature para inclusão de um fonte personalizado:

$ git flow feature start testebranch

Após executado o comando acima, vamos entrar na pasta SRC e criar um arquivo teste.prw (apenas para simular o desenvolvimento de uma feature). E após isso vou realizar o commit.

$ cd src
$ touch teste.prw
$ git add .
$ git commit -m "inclusão do fonte para teste da branch"

Caso queira realizar o teste do fonte criado dentro do ambiente SmartERP, precisamos empurrar o que comitamos para o repositório remoto. Até este momento, todas as ações efetuadas foram no nosso repositório clonado em nossa maquina, ou seja, o ambiente SmartERP não sabe que existe este novo fonte para compilar e disponibilizar dentro do ambiente.

Para isto temos que utilizar o comando GIT PUSH

Após isto, basta acessar o painel TCLOUD, acompanhar a build na aba builds e coletar o endpoint para homologação na aba meus ambientes.

Dica: o nome do environment é o mesmo nome da featurebranch criada, ou seja, teremos um endpoint com o nome da featurebranch e o environment do protheus também.

5. Finalizando a feature branch

Agora que já temos nossa feature criada, podemos finalizar a branch e mesclá-la com a develop.

$ git flow feature finish testebranch
$ git push

Se você está seguindo o passo a passo, irá notar que o Git Flow abre o editor de texto para que possamos editar algumas coisas:

• Primeira para editar o texto do merge commit relacionado ao merge entre a release branch 1.0.0 e master (texto opcional)

Feito isso seu código está na develop pronto para ir para produção e sem maiores problemas de versionamento.

Para realizar o processo para a master, basta realizar o processo idêntico ao descrito até agora.

Caso tenha alguma dúvida no processo completo (sem gitflow) acesse: 8.1.2. SmartERP Protheus - Promovendo alterações na prática

• Aprender mais sobre o Git
• Ciclo de Vida
• Como fazer pesquisas no TDN
• FAQs do produto
• Protheus 12
• Tecnologia TOTVS - TOTVSTEC