A garantia de qualidade implica em:

• como está escrito o artefato;
• estar de acordo com as técnicas e as normas de desenvolvimento TOTVS;
• compatibilidade entre o que está sendo personalizado e o que já se encontra no ambiente.

Observação: 

• A regra de negócio não está contemplada no robô de qualidade da TOTVS e, portanto, deve ser avaliado e coberto durante os testes de homologação do cliente, antes da entrada em produção.

Devido as regras de segurança e normalização do ambiente, criamos alguns processos para disponibilização e personalização do ambiente SmartERP Protheus. Acesse o conteúdo abaixo para maiores informações sobre as personalizações:

Image Added

• Aprender mais sobre o Git
• Ciclo de Vida
• Como fazer pesquisas no TDN
• FAQs do produto
• Protheus 12
• Tecnologia TOTVS - TOTVSTEC
• Dev Forum da TOTVS
• TOTVS CodeAnalysis
• Desenvolvimento de Queries no Protheus

Para a realização do processo de guarda e verificação de qualidade, a TOTVS disponibiliza um serviço de armazenagem de artefatos.

Trata-se de uma ferramenta de controle de versão realizado por meio de um Git.

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.

Noções Básicas de Git

Git é um sistema de controle de versão de arquivos. Através dele, podemos desenvolver projetos, onde diversas pessoas podem contribuir simultaneamente, editando e criando novos arquivos e permitindo que os mesmos possam existir sem o risco de suas alterações serem sobrescritas.

Se não houvesse um sistema de versão, imagine o caos quando duas pessoas abrissem um arquivo ao mesmo tempo. Uma das aplicações do Git é justamente permitir que um arquivo possa ser editado ao mesmo tempo por pessoas diferentes. Por mais complexo que isso seja, ele tenta manter tudo em ordem para evitar problemas para os desenvolvedores.

Instalando Git

O Git é um programa que pode ser instalado neste link: https://git-scm.com/book/pt-br/v1/Primeiros-passos-Instalando-Git

Acessando seu repositório de dados Git

Configurando o Git

Existem dois pequenos passos para configurar o GIT para ter um acesso mais simplificado ao repositório ERP.

Sempre que necessário, deve-se fornecer o login e senha ao Portal de repositório ERP. Existem meios para salvar a senha em local seguro, mas vamos pular esta etapa.

Para abrir um terminal GIT no Windows, crie uma pasta no seu sistema e clique com o botão direito do mouse e escolha Git Bash Here.

Em Sistemas Mac/Linux, você já está acostumado a usar o terminal/console, o Git estará lá disponível.

Então, com terminal Git aberto, digite:

$ git config --global user.name "YOUR NAME"

$ git config --global user.email "YOUR EMAIL ADDRESS"

Estas configurações ficam alocadas no arquivo ~/.gitconfig, onde o ~ é o diretório home.

No Windows, ficam em c:\Usuarios\<username>\.gitconfig.

Iniciando o projeto

Até agora, o Git está configurado para utilizar o repositório ERP e o projeto está criado. Precisamos trazer este projeto para o Git, este processo se chama clonar.

Dica: Quando quiser começar um projeto utilizando Git, você o cria no repositório ERP e o clona na sua máquina.

O comando para clonar o projeto é git clone "url", veja:

git clone https://repo-cxxxx.totvs.com.br/<username>/cxxxx.git

(Este link você poderá coletar diretamente em seu painel de serviços TCLOUD)

Ao executar o git clone, o projeto é "baixado" para a máquina e uma pasta com o nome do projeto é criada.

Comandos iniciais do Git

Com o repositório na máquina, verificaremos quatro comandos iniciais importantíssimos:

$ git add <arquivos...>

Este comando adiciona o(s) arquivo(s) em um lugar que chamamos de INDEX, que funciona como uma área do Git, no qual os arquivos possam ser enviados ao Repositório ERP. É importante saber que ADD não está adicionando um arquivo novo ao repositório, mas sim dizendo que o arquivo (novo ou não) está sendo preparado para entrar na próxima revisão do repositório.

$ git commit -m "comentário qualquer"

Este comando realiza o que chamamos de commit, que significa pegar todos os arquivos que foram adicionados pelo comando add, no INDEX e criar uma revisão com um número e um comentário, que será vista por todos.

$ git push

Push (empurrar) é usado para publicar todos os commits para o repositório ERP. Neste momento, é solicitada a pedido a senha.

$ git status

Exibe o status do repositório atual.

Errei a mensagem do commit, como conserto?

Imagine que você tenha errado a mensagem que escreveu no commit ou simplesmente queira melhorar a descrição do seu trabalho.

Se você já "comitou" a mensagem, mas ainda não fez o "push" das suas modificações para o servidor, pode usar a flag --amend: 

$ git commit --amend

O git commit --amend modifica a mensagem do commit mais recente, ou seja, o último commit.

Além de mudar a mensagem do commit, também é possível adicionar ou retirar arquivos. 

O git cria um commit totalmente novo e corrigido.

Trabalhando com branches

No Git, o conceito de branch é muito simples e fácil de usar.

Quando é necessário criar uma branch?

Imagine que o código esteja pronto, tudo funcionando perfeitamente, mas surge a necessidade de alterar algumas partes dele como forma de melhorá-lo. Além disso, é necessário manter estas alterações tanto no computador pessoal quanto do trabalho.

Por exemplo: Se você começa a alterar os arquivos em casa, pára na metade da implementação e precisa terminar no trabalho, como você iria "comitar" tudo pela metade e deixar as personalizações incompletas?

Para isso existe o conceito de branch, que é justamente ramificar o seu projeto em dois, como se cada um deles fosse um repositório, e depois juntá-lo novamente.

Em projetos que usam Git, é possível ter branches locais, presentes apenas na máquina do programador e branches remotas, que apontam para outras máquinas.

Por padrão, a branch principal é chamada master, tanto no repositório local quanto no remoto. Idealmente, a master é uma branch estável, isto é, o código nessa branch estará testado e pronto para ser entregue.

Para listar as branches existentes no repositório Git, basta executar:

$ git branch

Criando uma branch

Uma prática comum é ter no repositório, branches novas para o desenvolvimento de funcionalidades que ainda estão em andamento, contendo os commits do que já foi feito até então.

Para criar uma branch nova, de nome especifico a partir do último commit da master, execute:

$ git branch especifico

Ao criar uma nova branch, ainda não estamos automaticamente nela. Para selecioná-la, execute:

$ git checkout especifico

Criando e selecionando uma branch

É possível criar e selecionar uma branch com apenas um comando:

$ git checkout -b especifico

Para visualizar o histórico de commits de todas as branches, execute:

$ git log –all

Para uma representação gráfica baseada em texto do histórico, há a opção:

$ git log --graph

Juntando commits de outra branch

Como liberar as melhorias e novas funcionalidades?

É preciso mesclar o código de uma branch com a branch master.

Em geral, os sistemas de controle de versão têm um comando chamado merge, que permite fazer a junção de uma branch em outra, de maneira automática.

Vamos dizer que temos o seguinte cenário: a master tem os commits A e B. Então:

1. Cria-se uma branch especifica;
2. Implementa-se uma nova funcionalidade;
3. Realiza-se o commit D.
4. Retorna-se à master, obtém-se o repositório remoto (as mudanças feitas por um outro membro do time);
5. Recebe-se o commit C.

Image Removed

Se estivermos na branch master, podemos fazer o merge das alterações que estão na branch especifica da seguinte maneira:

$ git merge especifico

Ao realizar o merge, as alterações da branch especifica são colocadas na branch master e é criado um commit M, apenas para o merge.

O git,até mesmo abre um editor de texto para que seja possível definir a mensagem desse commit de merge.

Os comandos git log --graph ou gitk exibem o gráfico de commits da master:

Image Removed

Para normalizarmos os nomes das branches, convencionaremos a utilização da seguinte sintaxe:

$ git checkout -b feature/nova_branch

Aplicando na prática o git no projeto

Processo de Inovação no ambiente SmartERP

Para iniciar um processo de personalização dentro do ambiente do cliente, deve-se primeiramente, criar uma referência do projeto do cliente na máquina local do desenvolvedor. Para isto, clona-se o repositório com o seguinte comando:

$ git clone https://repositorio_do_cliente.totvs.com.br (este link será fornecido pelo cliente no início do projeto)

Após, será solicitado o usuário e senha do repositório, que devem ser fornecidos pelo cliente.

Feita a clonagem do repositório do cliente, deve-se criar uma nova branch de trabalho, para isto devemos utilizar os seguintes comandos:

$ git checkout -b feature/minha-inovacao

O nome da branch deve seguir o conceito do projeto que será executado dentro do cliente. Recomendamos separar o projeto por frente de trabalho, em ciclos pequenos de desenvolvimento. Desta forma, a promoção das personalizações fica mais simples.

A partir deste ponto, o desenvolvedor irá codificar as personalizações solicitadas pelo cliente em máquina local.

Como o desenvolvimento poderá demorar, é recomendável que de tempos em tempos seja feita a gravação dos dados dentro da branch criada, pois assim, garantimos que não ocorram inconvenientes como perda de informações e/ou retrabalho.

Para isto, utilizamos os seguintes comandos:

$ git add --all

$ git commit -m "Descricao da alteracao"

$ git push origin feature/minha-inovacao

Estes comandos servem para "empurrar os artefatos para dentro da branch" e, com isto, o robô de análise de código entrará em ação para avisar sobre qualquer ocorrência fora do padrão de desenvolvimento TOTVS.

Neste momento, provisionaremos um ambiente de desenvolvimento para a branch criada, para que o desenvolvedor realize a homologação das personalizações realizadas.

Ao término do processo de desenvolvimento, o desenvolvedor deverá "empurrar os artefatos gravados dentro da branch" para a MASTER. Este processo chama-se pull request.

Acesse a página do repositório e pressione o botão New pull request, ao lado esquerdo da página.

Image Removed

É possível modificar a branch na próxima tela. Em qualquer site, selecione o repositório, no menu suspenso, e a branch apropriados.

Depois de ter escolhido, por exemplo, a branch master do repositório original, no lado esquerdo, e a nova branch, do fork no lado direito, aparecerá a seguinte uma tela:

Image Removed

O repositório vai alertar de que é possível mesclar as duas branches, porque não há código concorrente. Adicione um título, um comentário e, em seguida, pressione o botão Create pull request.

Neste ponto, os mantenedores do repositório original decidirão se aceitam ou não o pull request. Eles podem solicitar que você edite ou revise o código antes de aceitar o pull request.

Conclusão do desenvolvimento

Ao término do processo, um pull request deve ter sido criado, para o repositório do cliente.

Depois disso, certifique-se de atualizar e fazer um rebase do código, enquanto espera que ele seja revisado.

O robô de qualidade e/ou o responsável pelo projeto poderá pedir que você refaça o código. Então, esteja preparado!

Image Removed

• Tire as suas dúvidas acessando às FAQs do produto.

Image Removed

• TECNOLOGIA TOTVS - TOTVSTEC
• Como fazer pesquisas no TDN
• Ciclo de Vida
• Aprender mais sobre o Git

Image Removed