Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Precisa de ajuda?

Livesearch
spaceKeyPROT
sizelarge
placeholderEstou procurando por ...
typepage
labelssmarterp

Section
Painel












O Microsiga Protheus ERP possui uma grande flexibilidade para customizações e personalizações, 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 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, as manutenções e a garantia da qualidade dos artefatos são de critério adotado pelo cliente e/ou time de projeto.

No modelo de implantação do Microsiga Protheus ERP em cloud, 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 no ambiente produtivo.


Aviso
titleImportante:

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 avaliada e coberta durante os testes de homologação do cliente, antes da entrada em produção.
Deck of Cards
id01
Card
id03
labelInstalando o TDS-VSCode

Uma das ferramentas utilizadas pelo desenvolvedor TOTVS é o VisualStudio (https://code.visualstudio.com/docs). Trata-se de uma ferramenta de desenvolvimento que suporta diversas linguagens de programação (inclusive o ADV/PL e TL++).

Aqui demonstramos como instalar e configurar o plugin de desenvolvimento TOTVS.

Conector de Widget
urlhttps://www.youtube.com/watch?v=MwIu01Ztfvg

Conector de Widget
urlhttps://www.youtube.com/watch?v=Cz4N0XWCXHY


Card
defaulttrue
id01
labelPersonalizando via fonte (ADV/PL)

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.


Deck of Cards
id02
Card
defaulttrue
idC00
labelNoçõ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.

Para o SmartERP Protheus, seguiremos o conceito do Git Flow.

Git Flow, trata-se de um modelo de organização de branches desenvolvido especialmente para o Git. Por ser primariamente um modelo de organização de branches, isso significa que o Git Flow estabelece algumas regras de nomenclaturas para tipos de branches enquanto, ao mesmo tempo, define o que cada tipo de branch faz. Para referência, segue uma lista dos tipos de branches definidos pelo Git Flow e suas respectivas descrições:

  • Branch master - É a branch que contém código em nível de produção, ou seja, o código mais maduro existente na sua aplicação. Todo o código novo produzido eventualmente é juntado com a branch master, em algum momento do desenvolvimento;
  • Branch develop - É a branch que contém código em nível preparatório para o próximo deploy. Ou seja, quando features são terminadas, elas são juntadas com a branch develop, testadas (em conjunto, no caso de mais de uma feature), e somente depois as atualizações da branch develop passam por mais um processo para então ser juntadas com a branch master;
  • Branches feature/* - São branches no qual são desenvolvidos recursos novos para o projeto em questão. Essas branches tem por convenção nome começando com feature/ (exemplo: feature/new-layout) e são criadas a partir da branch develop (pois um recurso pode depender diretamente de outro recurso em algumas situações) e, ao final, são juntadas com a branch develop;
  • Branches hotfix/* - São branches no qual são realizadas correções de bugs críticos encontrados em ambiente de produção, e que por isso são criadas a partir da branch master, e são juntadas diretamente com a branch master e com a branch develop (pois os próximos deploys também devem receber correções de bugs críticos, certo?). Por convenção, essas branches tem o nome começando com hotfix/ e terminando com o próximo sub-número de versão (exemplo: hotfix/2.31.1), normalmente seguindo as regras de algum padrão de versionamento.
  • Branches release/* - São branches com um nível de confiança maior do que a branch develop, e que se encontram em nível de preparação para ser juntada com a branch master e com a branch develop (para caso tenha ocorrido alguma correção de bug na branch release/* em questão). Note que, nessas branches, bugs encontrados durante os testes das features que vão para produção podem ser corrigidos mais tranquilamente, antes de irem efetivamente para produção. Por convenção, essas branches tem o nome começando com release/ e terminando com o número da próxima versão do software (seguindo o exemplo do hotfix, dado acima, seria algo como release/2.32.0), normalmente seguindo as regras do versionamento semântico, como mencionado acima.


O processo de trabalho ficaria assim:


Aviso

A Branch master sempre reflete o que está na produção do cliente, ou seja, se houver um commit de artefatos nesta branch, automaticamente entenderemos que precisamos promovê-las para a PRODUÇÃO. Portanto, utilize com muita "sabedoria" esta branch.

A Branch hotfix será gerada todas as vezes que forem encontrados erros críticos em produção. Sempre que ocorrer a criação desta branch, devemos executar um merge das correções na branch master e na branch develop sempre que concluir o desenvolvimento. Se esquecer de realizar este merge, você poderá perder as personalizações em produção ou em desenvolvimento.

A Develop é a branch que contém todos os novos desenvolvimentos solicitados pelo cliente. Todos os commits realizados nesta branch, serão promovidos para o ambiente de Develop do cliente, podendo assim, ser homologado pelo cliente.

As Features são branchs locais de desenvolvimento para que o Dev possa construir seus códigos e testar em tempo de desenvolvimento, sem a necessidade de concorrência com outros Devs. Estas features geraram um ambiente espelho da produção para homologação do desenvolvedor. Atualmente, temos disponíveis até 5 features branchs dentro do ambiente do cliente.

Card
idC01
labelInstalando o GIT

Instalação

O Git pode ser instalado tanto via linha de comando como por meio de download. Para obter o Git em sua máquina confira o passo a passo neste link: https://git-scm.com/book/pt-br/v1/Primeiros-passos-Instalando-Git

Configurando o usuário Git

Nesta etapa vamos configurar o nome de usuário e e-mail que o Git irá utilizar sempre que realizarmos uma alteração em um arquivo de código fonte, estes dados serão importantes no futuro, pois dentro do processo de submeter um código fonte para aprovação e aplicação em um ambiente, o responsável por esta avaliação irá checar estas informações.

Para concluir esta etapa de configuração, basta executar dois comandos cujo objetivo é informar ao Git qual o nome de usuário da pessoa que está utilizando a ferramenta e qual seu e-mail.

Os comandos devem ser executados em um terminal, caso você esteja utilizando Windows, ao instalar o Git será instalado uma ferramenta de terminal chamada Git Bash.

  1. Para abrir o Git Bash, execute o Windows Explorer.
  2. Acesse uma pasta de sua preferência, clique com o botão direito e escolha a opção Git Bash Here.



Com o terminal Git aberto, digite:

Bloco de código
$ git config --global user.name "Seu usuário"

$ git config --global user.email "Seu e-mail"


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

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

Card
idC02
labelIniciando um projeto

Baixando um Repositório

Após configurar o usuário e e-mail, pode-se baixar uma cópia local do repositório. 

O primeiro passo é obter as credências e a url para obtenção dos arquivos.

Todos os repositórios para customização do SmartERP Protheus são protegidos e sua cópia somente pode ocorrer mediante o usuário possuir um par de chaves (credencial + senha) que serão utilizados sempre que enviar suas alterações para o servidor.


Aviso
titleAtenção

Não distribua seu par de chaves, caso perca ou suspeite que a segurança foi comprometida, solicite um novo par imediatamente.


Em posse do par de chaves e da url utilize o comando git clone:

Bloco de código
git clone git.totvs.com/v1/repos/smartprotheus-XXXXXXX-repository


(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:

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, 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.


Bloco de código
$ 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.


Bloco de código
$ git push

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


Bloco de código
$ git status

Exibe o status do repositório atual.

Errei a mensagem do commit, como corrijo?

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

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

Bloco de código
$ 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.


Card
idC03
labelTrabalhando com Branches

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 entregar 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:

Bloco de código
$ 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:

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 específico

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, execute:

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
Card
idC04
labelReunindo Commits

Reunindo 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.


















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

Bloco de código
$ 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:















Aviso
titleImportante

Caso a gravação dos artefatos seja realizada diretamente na branch MASTER, consideraremos 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 os códigos sejam validados no ambiente produtivo.


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

Bloco de código
$ git checkout -b feature/nova_branch
Card
idC05
labelAplicando na prática

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:

Bloco de código
$ 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:

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. 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:

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 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 deverá ser efetuado através de um merge com a branch master. Para realizar isto, deve-se resolver todos os conflitos que surgirem.

Card
id04
labelPromovendo as alterações para o seu ambiente

No exemplo abaixo, demonstramos toda a esteira de subida de uma melhoria ou correção para dentro do ambiente do cliente.


Passos para realização deste processo:

  1. O repositório do cliente é clonado.
  2. Uma nova rotina é implementada dentro da máquina local.
  3. É executado o comit do os novos artefatos dentro do git local.
  4. Os artefatos são copiados para dentro do repositório remoto (ambiente SmartERP).
  5. O retorno do SonarCube é "checado".


HTML
<script>
	function linksToBlank(){
		var links = document.getElementsByTagName("a");
        var l = 0;
        for (var i = 0, l = links.length; i < l; i++) {
           links[i].target = "_blank";
        }
    }
	window.onload = linksToBlank;
</script>