em em construção
O Microsiga Protheus é um ERP que possui uma grande flexibilidade para realizarmos customizações e personalizações. Estes 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 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 qualidade dos artefatos remete-se ao critério adotado pelo cliente e/ou time de projeto. No modelo de implantação do ERP em Cloudcloud, passamos a guardar e realizar a verificação da qualidade destes artefatos, com isto. Desta forma, além que garantir que nunca percamos um artefato, também passamos a garantir garantimos a qualidade do que é disponibilizado em seu ambiente produtivo.
Aviso |
---|
| A garantia de qualidade refere-se há implica em: - como está escrito o artefato
, se foi seguido - ;
- se estão de acordo com as técnicas e as normas de desenvolvimento TOTVS
e - ;
- se não há incompatibilidade entre o que está sendo personalizado e o que já se encontra no ambiente.
Cabe lembrar que a regra de negócio não está contemplada em nosso no robô de qualidade da TOTVS, este, que deve ser avaliado e coberto durante os testes de homologação do cliente, antes da entrada em produção. |
Para realizarmos este a realização do processo de guarda e verificação de qualidade, passamos a disponibilizar TOTVS disponibiliza um serviço de armazenagem de artefatos. Este trataTrata-se de uma ferramenta de controle de versão realizado através de um gitGit. Controle de VersãoO 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 seja possível recuperar versões específicas. O controle de versão permite reverter arquivos para ou um estado anterior, reverter um projeto inteiro para um estado anterior, comparar mudanças feitas ao no decorrer do tempo, ver descobrir quem foi o último a modificar algo que pode estar causando problemas, quem introduziu um bug e quando isso ocorreu, e além de muito mais. Usar um controle de versão, normalmente significa que se você estragou algo foi danificado ou perdeu se arquivos foram perdidos, poderá facilmente será possível reavê-los. Além disso, você pode controlar tudo sem maiores esforços.
Noções Básicas de GitGit é um sistema de controle de versão de arquivos. Através deles dele, podemos desenvolver projetos na qual , onde 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 houvesse um sistema de versão, imagine o caos entre quando duas pessoas abrindo o mesmo abrissem um arquivo ao mesmo tempo. Uma das aplicações do git 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 os desenvolvedores. Instalando gitGitO git 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 gitGitConfigurando o gitGitExistem 2 dois pequenos passos para configurar o seu GIT para ter um acesso mais simplificado ao repositório ERP. Aqui estaremos estabelecendo Sempre que , sempre que necessitar, você irá necessário, deve-se fornecer o seu login e senha ao portal 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 crie uma pasta no seu sistema e , nela, clicar clique com o botão direito do mouse e escolher escolha Git Bash Here. Em sistemas mac/linux Sistemas Mac/Linux, você já está acostumado a usar o terminal/console, o git Git estará lá disponível. Então, com o seu terminal git Git aberto, vamos digitardigite: Bloco de código |
---|
$ 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 ficam em c:\Usuarios\<username>\.gitconfig. Iniciando o projetoEntão o que temos , até agora é , temos o git Git configurado para utilizar o repositório ERP e o projeto criado. Precisamos trazer este projeto para o nosso gitGit, e este processo se chama clonar. Dica: Então, quando você quiser começar um projeto utilizando gitGit, você o cria no repositório ERP e clona na sua máquina. O comando para clonar o projeto é git clone "url", veja: Bloco de código |
---|
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 executar o git clone, o projeto é "baixado" para a sua máquina , e uma pasta com o nome do projeto é criada. Comandos iniciais do gitGitCom o repositório na sua máquina, vamos verificar 4 quatro comandos iniciais que farão parte da sua vida a partir de agoraimportantíssimos: Bloco de código |
---|
$ git add <arquivos...> |
Este comando adiciona o(s) arquivo(s) em um lugar que chamamos de INDEX, que funciona como uma área do git 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. Bloco de código |
---|
$ git commit -m "comentário qualquer" |
Este comando realiza o que chamamos de “commit” 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. Bloco de código |
---|
$ git push |
Push (empurrar) é usado para publicar todos os seus os commits para o repositório ERP. Neste momento, será pedido a sua senha. Bloco de código |
---|
$ 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ê Se você já "comitou" a mensagem, mas ainda não fez o "push" das suas modificações para o servidor. Nesse caso você usa , pode usar a flag --amend. Fica assim: Bloco de código |
---|
$ 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 também é possível adicionar ou retirar arquivos comitados por engano. O git cria um commit totalmente novo e corrigido. Trabalhando com branchesNo gitGit, o conceito de branch é muito simples e fácil de usar. Mas quando que temos que criar um Quando é necessário criar uma 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 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 2dois, 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á 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: Bloco de código |
---|
$ git branch |
Criando uma branchUma 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 da master, façaexecute: Bloco de código |
---|
$ git branch especifico |
Ao criar uma nova branch, ainda não estamos automaticamente nela. Para selecioná-la, execute: Bloco de código |
---|
$ git checkout especifico |
Criando e selecionando uma branchÉ possível criar e selecionar uma branch com apenas um comando: Bloco de código |
---|
$ git checkout -b especifico |
Para visualizar o histórico de commits de todas as branches, podemos fazerexecute: Bloco de código |
---|
$ git log –all |
Para uma representação gráfica baseada em texto do histórico, há a opção: Bloco de código |
---|
$ git log --graph |
Juntando commits de outra branchE como Como fazemos para liberar as melhorias e novas funcionalidades? É preciso mesclar o código de uma branch com a branch master 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 Bnossa master tem os commits A e B. Então, criamos uma branch especifico branch especifico, implementamos uma nova funcionalidade e realizamos o commit D commit D. Depois, voltamos à master eà master e, ao obter do repositório remoto, as mudanças feitas por um outro membro do time, recebemos o commit C commit C. ![](/download/attachments/515688107/image2019-9-22_14-53-17.png?version=1&modificationDate=1569174797723&api=v2)
Se estivermos na branch master, podemos fazer o merge das alterações que estão na branch especifico branch especifica da seguinte maneira: Bloco de código |
---|
$ 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:
![](/download/attachments/515688107/image2019-9-22_14-52-44.png?version=1&modificationDate=1569174764370&api=v2)
Aviso |
---|
| Caso realize a gravação dos artefatos diretamente na branch MASTER, iremos considerar que o código gravado deverá ser promovido para o ambiente produtivo, ou seja, a utilização de branchs diferentes da MASTER irá nos garantir que não haja códigos não validados no ambiente produtivo. |
Para normalizarmos os nomes das branches, iremos convencionar a utilização da seguinte sintaxe: Bloco de código |
---|
$ git checkout -b feature/nova_branch |
Aplicando na prática o git no meu projetoProcesso 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: Bloco de código |
---|
$ 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: Bloco de código |
---|
$ 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:
Bloco de código |
---|
$ 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. ![](/download/attachments/515688107/image2019-9-22_14-52-26.png?version=1&modificationDate=1569174747183&api=v2)
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: ![](/download/attachments/515688107/image2019-9-22_14-52-11.png?version=1&modificationDate=1569174731780&api=v2)
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 desenvolvimentoAo 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/). ![](/download/attachments/515688107/image2019-9-19_16-46-30.png?version=1&modificationDate=1569174013953&api=v2)
![](/download/attachments/515688107/image2019-9-19_16-45-50.png?version=1&modificationDate=1569174013887&api=v2)
![](/download/attachments/515688107/image2019-9-19_16-45-18.png?version=1&modificationDate=1569174013820&api=v2)
Atualizado recentemente |
---|
max | 6 |
---|
spaces | PROT |
---|
hideHeading | true |
---|
theme | sidebar |
---|
labels | smarterp |
---|
|
|