Image Removed

Image Added

O Microsiga Protheus é um ERP que possui  possui uma grande flexibilidade para realizarmos customizações e personalizações. Estes , que referem-se tanto em artefatos compilados dentro do repositório de fontes (RPO), quanto dentro das estruturas de pastas de instalação do Protheus.

No modelo de implantação do do Microsiga Protheus ERP on-premisse (dentro de sua casa), todos os artefatos customizados/personalizados são de total responsabilidade do cliente, isto quer dizer que , tanto a guarda quanto , as manutenções e a garantia de da qualidade dos artefatos remete-se ao são de critério adotado pelo cliente e/ou time de projeto.

No modelo de implantação do ERP em Cloud, passamos a guardar e realizar a verificação da qualidade destes artefatos, com isto, além que garantir que nunca percamos um artefato, também passamos a garantir a do SmartERP Protheus, a TOTVS guarda e verifica a qualidade dos artefatos. Desta forma, a TOTVS garante que os artefatos não sejam perdidos, além da qualidade do que é disponibilizado em seu no ambiente produtivo.

Para realizarmos este processo de guarda e verificação de qualidade, passamos a disponibilizar um serviço de armazenagem de artefatos. Este trata-se de uma ferramenta de controle de versão realizado através 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 você possa recuperar versões específicas.

O controle de versão permite reverter arquivos para um estado anterior, reverter um projeto inteiro para um estado anterior, comparar mudanças feitas ao decorrer do tempo, ver quem foi o último a modificar algo que pode estar causando problemas, quem introduziu um bug e quando, e muito mais. Usar um controle de versão normalmente significa que se você estragou algo ou perdeu arquivos, poderá facilmente 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 deles podemos desenvolver projetos na qual diversas pessoas podem contribuir simultaneamente no mesmo, editando e criando novos arquivos e permitindo que os mesmos possam existir sem o risco de suas alterações serem sobrescritas.

Se não houver um sistema de versão, imagine o caos entre duas pessoas abrindo o mesmo arquivo ao mesmo tempo. Uma das aplicações do git é justamente essa, 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 nós 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 2 pequenos passos para configurar o seu GIT para ter um acesso mais simplificado ao repositório ERP. Aqui estaremos estabelecendo que, sempre que necessitar, você irá fornecer o seu 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, basta criar uma pasta no seu sistema e, nela, clicar com o botão direito do mouse e escolher 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 o seu terminal git aberto, vamos digitar:

$ 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 seu diretório home. No Windows, ele fica em c:\Usuarios\<username>\.gitconfig.

Iniciando o projeto

Então o que temos até agora é o git configurado para utilizar o repositório ERP e o projeto criado. Precisamos trazer este projeto para o nosso git, e este processo se chama clonar. Então, quando você quiser começar um projeto utilizando git, você o cria no repositório ERP e 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 fazer o git clone, o projeto é baixado para a sua máquina, e uma pasta com o nome do projeto é criada.

Comandos iniciais do git

Com o repositório na sua máquina, vamos verificar 4 comandos iniciais que farão parte da sua vida a partir de agora:

$ 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 (sendo 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 estão naquele lugar INDEX que o comando add adicionou 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 seus commits para o repositório ERP. Neste momento, será pedido a sua senha.

$ git status

Exibe o status do seu repositório atual

Errei a mensagem do commit, como arrumo?

Imagine que você tenha errado a mensagem que escreveu no commit ou simplesmente queira melhorar a descrição do seu trabalho. Você já comitou a mensagem, mas ainda não fez o push das suas modificações para o servidor. Nesse caso você usa a flag --amend. Fica assim:

$ git commit --amend

O git commit --amend modifica a mensagem do commit mais recente, ou seja, o último commit feito por você no projeto. Além de você mudar a mensagem do commit, você consegue adicionar arquivos que você se esqueceu ou retirar arquivos comitados por engano. 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. Mas quando que temos que criar um branch? Imagine que o seu código está pronto, tudo funcionando perfeitamente, mas surge a necessidade de alterar algumas partes dele como forma de melhorá-lo. Além disso, você precisa manter estas alterações tanto no computador de casa quanto do trabalho. Com isso temos um problema, se você começa a alterar os arquivos em casa, para 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 2, como se cada um deles fosse um repositório, e depois juntá-lo novamente.

Em projetos que usam Git, podemos ter tanto branches locais, presentes apenas na máquina do programador, quanto 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 será uma branch estável, isto é, o código nessa branch estará testado e pronto para ser entregue.

Para listar as branches existentes em seu 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, faça:

$ git branch especifico

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

$ 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, podemos fazer:

$ 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

E como fazemos para 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: nossa master tem os commits A e B. Então, criamos uma branch especifico, implementamos uma nova funcionalidade e realizamos o commit D. Depois, voltamos à master e, ao obter do repositório remoto as mudanças feitas por um outro membro do time, recebemos o commit C.

Image Removed

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

$ git merge especifico

Quando fizermos o merge, as alterações da branch especifico são colocadas na branch master e é criado um commit M só para o merge. O git até mesmo abre um editor de texto para que possamos definir a mensagem desse commit de merge.

Se visualizarmos o gráfico de commits da master com os comandos git log --graph ou gitk, teríamos algo como:

Image Removed

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 normalizarmos os nomes das branches, iremos convencionar a utilização da seguinte sintaxe:

$ git checkout -b feature/nova_branch

Aplicando na prática o git no meu projeto

Processo de Inovação no ambiente SmartERP

Para iniciarmos um processo de personalização dentro do ambiente do cliente, devemos primeiramente criar uma referência do projeto do cliente na máquina local do desenvolvedor, para isto, vamos clonar 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)

Feito isto, será solicitado o usuário e senha do repositório do cliente. Estes serão fornecidos pelo cliente.

Após a clonagem do repositório do cliente, devemos 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. Recomentamos separar o projeto por frente de trabalho, cujo possua 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 solicitada pelo cliente em máquina local.

Como o desenvolvimento poderá demorar, é recomendável que de tempos em tempos se realize a gravação dos dados dentro da branch criada, pois desta forma garantimos que não tenhamos 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 irá entrar em ação e avisar sobre qualquer ocorrência fora do padrão de desenvolvimento TOTVS.

Neste momento, iremos provisionar 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 desenvolvimento, o desenvolvedor deverá empurrar os artefatos gravados dentro de sua branch para a MASTER. Para isto, o desenvolvedor deverá realizar um processo chamado de pull request.

Você deverá entrar na página do repositório e pressionar o botão “New pull request” no lado esquerdo da página.

Image Removed

Você pode modificar a branch na próxima tela. Em qualquer site, você pode selecionar o repositório apropriado no menu suspenso e a branch apropriada.

Depois de ter escolhido, por exemplo, a branch master do repositório original no lado esquerdo, e a nova-branch do seu fork do lado direito, você deve ver uma tela assim:

Image Removed

O repositório vai lhe alertar de que é possível mesclar as duas branches porque não há código concorrente. Você deve adicionar um título, um comentário e, em seguida, pressionar o botão “Create pull request”.

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

Conclusão do desenvolvimento

Ao termino do processo, deverá ter sido criado um pull request para o repositório do cliente. Depois disso, você deve se certificar de atualizar e fazer um rebase do seu 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 seu código, então você deve estar preparado para isso.

Se você estiver interessado em aprender mais sobre o Git, recomendamos que acesse o site do git (https://git-scm.com/).

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

Image Removed