Histórico da Página

Cada componente em execução do Protheus é separado dentro de um pod, onde temos:

• License Server

• DbAccess
• LockServer
• AppServer
• Execução do ERP
• Execução do Configurador
• Execução do Portal
• Execução do REST
• Execução do WebService
• FileSystem (protheus_data)
• Banco de dados
• Serviço de customização

Cada componente listado acima, reflete em uma imagem (docker) que fica armazenada dentro do gcr.io da conta da engenharia (https://gcr.io/eng-protheus).

Utilizamos os componentes que ficam armazenados no endereço: https://arte.engpro.totvs.com.br/engenharia/bundles/SmartERP/base/imagem/componentes/.

Neste endereço temos todos os componentes abertos para que o time de engenharia do Smart ERP realize a atualização dos componentes sempre que houver a solicitação pelos times de TEC, FRAME e Produto.

Dentro das pastas temos uma subdivisão entre os tipos de ambientes (produção, sistêmico e tecnologia). 

Para cada um deles, temos a separação dos componentes para que um não interfira nos testes de outros ambientes. Ex. Estamos atuando em uma feature no ambiente de TEC com binários pré-release e no ambiente do Sistêmico estamos utilizando o binário oficial para a homologação.

Em cada folder, existe um arquivo chamado VERSION. Neste arquivo informamos a versão do componente a ser gerado.

IMPORTANTE: Para a geração do RPO que utilizamos nos ambientes do SMART (Produção), copiamos o artefato na pasta  https://arte.engpro.totvs.com.br/engenharia/bundles/smarterp/base/topologia/rpo_smarterp/ e para o sistemico utilizamos a pasta https://arte.engpro.totvs.com.br/engenharia/bundles/smarterp/base/topologia/rpo_sistemico/
A montagem base do RPO do sistêmico é o D-1 da versão 12.1.2210 e compilado os artefatos utilizados pelo SMARTERP.

Após termos os componentes atualizados, compactamos os componentes no formato tar.gz e disponibilizamos no bucket no Arte. Para saber os nomes corretos dos artefatos, recomendo entrar no folder https://arte.engpro.totvs.com.br/engenharia/bundles/smarterp/espelho/ do componente a ser atualizado, copiar o nome exato de lá. Lembrando que o subfolder do componente é a versão que utilizamos para o componente. É uma forma simples de versionamento de componentes.

Conforme mencionado acima, o versionamento dos componentes são realizados através de folders dentro do folder no Arte, após copiado o artefato para um novo FOLDER, coletamos o nome do FOLDER e "linkamos" este componente com a versão da imagem a ser gerada. 

As imagens estão dispostas em repositórios dentro do GITEA (https://code.engpro.totvs.com.br/smarterp/), separados por componentes/imagens a serem utilizados. Cada repositório possui um artefato chamado component-versions.mk e dentro dele informamos/linkamos o componente que disponibilizamos no Arte. Com a atualização do arquivo, geramos uma BRANCH de versão com a finalidade de gerarmos a versão de uma nova imagem. 

O processo é realizado de forma automática, com a finalização do PUSH da branch, através Jenkins  (https://james.engpro.totvs.com.br/view/all/job/smarterp/). (Sugiro que realizem o acompanhamento da build no jenkins até a finalização).

Importante: Utilizamos o processo de GITFLOW para todos os repositórios do SmartERP, ou seja, devemos sempre utilizar a branch develop para iniciar o processo de inovação/fix e gerar uma nova branch com os commits gerados. Ao término do processo de construção e homologação dos componentes do repositório, abrimos uma PR para a branch develop e após aprovação de pelo menos um dos responsáveis pelo repositório é que deverá ser realizado o merge com a develop. Com a conclusão e homologação em develop, deverá ser aberto um PR para mergear com a MASTER. Este processo é para garantirmos que não iremos subir coisas não testadas na imagem e também para aglutinarmos várias correções antes de subirmos para a master. A pessoa que abriu o PR é que deverá realizar o MERGE.

Para realizarmos o processo de atualização e/ou disponibilização de componentes em nosso cluster, utilizamos um “orquestrador” chamado HELM. O Helm (https://helm.sh/) faz o empacotamento dos templates a serem utilizados no cluster e usa um formato de empacotamento chamado CHART . Um único chart pode ser usado para implantar algo simples, como um pod, ou algo complexo, como uma pilha completa de aplicativos como o PROTHEUS e assim por diante.

Os templates irão definir quais os componentes queremos instalar no Kubernetes e como eles devem ser configurados. É com base neles que o Helm identifica o que deve ser criado, atualizado ou excluído.

Para a montagem dos templates, utilizamos o repositório https://github.com/cloud104/smarterp

que terá as versões de componentes e imagens a serem utilizadas dentro do cluster. Este repositório está restrito ao time de Arquitetura do Cloud e ao SRE.

Para informarmos os componentes dentro do chart, devemos realizar a alteração de dois arquivos:
https://github.com/cloud104/smarterp/blob/master/charts/smarterp/values.yaml e https://github.com/cloud104/smarterp/blob/master/VERSION
O primeiro arquivo é onde informamos as imagens geradas no Protheus:

E o segundo é onde informamos a versão do chart.

Importante: Utilizamos o processo de GITFLOW para todos os repositórios do SmartERP, ou seja, devemos sempre utilizar a branch develop para iniciar o processo de inovação/fix e gerar uma nova branch com os commits gerados. Ao término do processo de construção e homologação dos componentes do repositório, abrimos uma PR para a branch develop e após aprovação de pelo menos um dos responsáveis pelo repositório é que deverá ser realizado o merge com a develop. Com a conclusão e homologação em develop, deverá ser aberto um PR para mergear com a MASTER. Este processo é para garantirmos que não iremos subir coisas não testadas na imagem e também para aglutinarmos várias correções antes de subirmos para a master. A pessoa que abriu o PR é que deverá realizar o MERGE.