Image Added
Image Removed em construção
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. Aviso |
---|
| A garantia de qualidade refere-se há como está escrito o artefato, se foi seguido 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 robô de qualidade, este, deve ser avaliado e coberto durante os testes de homologação do cliente, antes da entrada em produção. |
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ã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 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 GitGit é 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 gitO 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 gitConfigurando o gitExistem 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 projetoEntã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 gitCom 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: 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 ou retirar arquivos comitados por engano. O git cria um commit totalmente novo e corrigido. Trabalhando com branchesNo 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: 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, faça: Bloco de código |
---|
$ git branch especifico |
Ao criar uma nova branch, ainda não estamos automaticamente nela. Para selecioná-la: 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 fazer: 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 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. Se estivermos na branch master, podemos fazer o merge das alterações que estão na branch especifico 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: Informações |
---|
Importante: 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: $ git checkout -b feature/nova_branch Aplicando na prática o git no meu projetoProcesso de Inovação no ambiente SmartERPPara 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. 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: 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 projetoAo 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
Image Removed
Atualizado recentemente |
---|
Informações |
---|
Por motivos de segurança e normalização, não será possível executar ações como: - Alteração de dicionário de dados;
- Execução de Upddistr;
- Execução de Rup´s;
- Aplicar pacotes (.ptms) expedidos pelo produto (Em breve: Estaremos liberando a opção de aplicação de pacotes de parceiros) ;
- Compilar fontes diretamente no RPO;
- Acesso ao monitor do Dbaccess;
- Acesso direto ao banco de dados;
- Execução de querys, updates, deletes e etc.
Isto deve-se ao modelo de disponibilização do SmartERP Protheus. Todas as ações listadas exigem uma parada no ambiente e execução exclusiva e devido aos agentes de monitoramento do ambiente, estas ações não poderão ser executadas sem que haja a interrupção do mesmo. Para maiores informações sobre o modelo de disponibilização, acesse: 2. SmartERP Protheus - Arquitetura SmartERP |
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:
Exibir filhos |
---|
all | true |
---|
depth | 3 |
---|
style | h4 |
---|
sort | title |
---|
excerptType | simple |
---|
|
Image Added
|