O GitHub é o melhor serviço baseado em nuvem que hospeda um sistema de controle,  permitindo que indivíduos e equipes colaborem em projetos de programação. Criado em 2008, o GitHub se tornou um dos principais serviços para hospedar, revisar e gerenciar projetos de código aberto.

Uma das características mais distintas do GitHub é o gerenciamento de código-fonte. Amplamente utilizado, ele oferece controle de versão, colaboração eficiente e reversão para versões anteriores, se necessário. Ou seja, possibilita que os times trabalhem juntos sem que seus esforços se sobreponham.

No entanto, os desenvolvedores ABAP concentram seus esforços principalmente no ambiente SAP dentro do seu repositório. Assim, para eles, o GitHub é uma terra desconhecida.

Neste artigo, serão explicadas as principais funcionalidades do GitHub, e as limitações de uso como repositório de código ABAP.

1. Clonar repositório

No GitHub

Clonar um repositório no GitHub significa fazer uma cópia local, para sua própria máquina, de um projeto hospedado no GitHub. Isso permite que você trabalhe no código-fonte, faça alterações e contribua para o projeto sem interferir diretamente no repositório original.

No SAP/ABAP

Seria como importar um pacote por uma request através da transação SE80.

Comparativo  e limitações

Clonar um repositório no GitHub é semelhante a importar um pacote por meio de uma solicitação na transação SE80. Porém, há uma diferença crucial: no GitHub, como mencionamos, você cria uma cópia local do projeto em sua máquina. 

No entanto, para os desenvolvedores ABAP que normalmente trabalham diretamente no ambiente do servidor de desenvolvimento, essa prática é limitada. Isso porque o desenvolvimento é feito no próprio servidor, o que restringe a capacidade de codificar localmente e de forma distribuída.

2. Criação de branch

No GitHub

Refere-se a uma cópia separada do código-fonte de um repositório. Ela permite que você trabalhe em novas funcionalidades, correções de bugs ou experimentos. E isso, por sua vez, se dá sem afetar diretamente o código principal, que no caso está no branch “master”.

No SAP/ABAP

Fazendo analogia ao processo do GitHub, seria necessário criar uma cópia do(s) objeto(s) e suas dependências, já que o repositório do ABAP não mantém a integridade do repositório em uma cópia. Posteriormente, realiza-se a codificação, evitando o impacto direto no objeto principal.

Comparativo e limitações

Os branches são valiosos para a colaboração, facilitando que múltiplos desenvolvedores trabalhem em recursos distintos simultaneamente e sem conflitos diretos. Contudo, no contexto do ABAP, sua adoção é restrita. Essa limitação se deve a considerações peculiares ao ambiente SAP e às ferramentas disponíveis nos repositórios ABAP não implementam o conceito de branch. 

A tentativa de simular estes conceitos e métodos de programação no ABAP são manuais e trabalhosos. Além de realizar manualmente a cópia de objetos e sincronizar conflitos entre a versão do objeto e a cópia. Nesse sentido, tal ação é extremamente  trabalhosa e propensa a erros dado a exigência de inúmeras conferências e processos manuais.

3. Commits de alterações

No GitHub

Refere-se ao processo de registrar e salvar alterações feitas em um repositório de controle de versão local para o ambiente de desenvolvimento. Cada commit representa uma etapa na evolução do código-fonte e geralmente inclui a mensagem que descreve as alterações feitas.

No SAP/ABAP

É o processo de salvar e ativar os objetos de desenvolvimento – como programas, classes, tabelas, entre outros – dentro do ambiente de desenvolvimento SAP.

Comparativo e limitações

Um commit no GitHub envolve registrar e salvar alterações feitas em arquivos dentro de um repositório de controle de versão. 

As alterações são geralmente feitas localmente no computador do desenvolvedor e, em seguida, consolidadas. Nos desenvolvimentos ABAP, as alterações são realizadas no ambiente de desenvolvimento SAP. Dessa forma, não são salvas localmente antes de consolidarem-nas em um pacote de transporte.

4. Push de alterações

No GitHub

Consiste na ação de, através de commits, enviar as alterações locais que foram registradas em um repositório GitHub para um repositório remoto. Quando você executa um “push”, você está atualizando o repositório remoto com as alterações que você fez localmente.

No SAP/ABAP

O conceito de “push de alterações” não é aplicável como no GitHub. No ambiente ABAP, as alterações são geralmente realizadas no ambiente de desenvolvimento. Em seguida, transportam-se para outros sistemas, como os de qualidade ou produção.

Tal transporte ocorre através de um processo controlado usando ferramentas como o SAP Transport Management System (TMS) ou GMUD e transporte automatizado do QADEVOPS.

5. Pull de alterações

No GitHub

Quando você executa um “pull”, o GitHub verifica o repositório remoto para ver se houve alterações desde a última sincronização. Se houver, ele baixa essas alterações para o repositório local. Depois disso, tenta mesclá-las automaticamente com o código existente, atualizando o histórico de alterações local.

No SAP/ABAP

Não existe um conceito de “pull de alterações”. No SAP, utilizamos sempre a versão mais atual dos objetos e o conceito de comparação de versões do ambiente. Como já vimos o repositório ABAP não permite programação distribuída.

6. Resolver conflitos

No GitHub

Quando é realizada a mescla de alterações de um branch para outro, pode ocorrer um conflito. Nesse caso, o GitHub sinaliza essa situação e marca as partes conflitantes no código. 

Para resolver o conflito, é necessário examinar as alterações conflitantes, decidir como integrá-las corretamente e então marcar o conflito como resolvido. Isso pode envolver a edição manual do código para mesclar as alterações de forma apropriada.

No SAP/ABAP

Resolvem-se conflitos principalmente durante o processo de transporte de objetos entre os ambientes SAP. Por exemplo: DEV e QA. Quando dois ou mais desenvolvedores modificam o mesmo objeto em sistemas diferentes, pode acontecer um conflito durante o transporte.

Comparativo e Limitações

A SAP fornece funcionalidades básicas de controle de versão, como o sistema de transporte. Apesar disso, a resolução de conflitos no ABAP essencialmente requer intervenção manual por parte dos desenvolvedores. 

Este processo é manual e geralmente mais trabalhoso e propenso a erros do que processos automatizados de resolução de conflitos existentes em outras plataformas de desenvolvimento com controles de versão mais aprimorados.

7. Histórico de alterações

No GitHub

Registro completo de todas as modificações feitas em um repositório de código-fonte ao longo do tempo. Esse histórico inclui informações detalhadas sobre:

• quem fez as alterações;
• quando foram realizadas;
• e quais foram as modificações realizadas em cada arquivo.

No SAP/ABAP

Registro das modificações feitas em objetos de desenvolvimento, como programas, classes, tabelas e outros artefatos de sistema como já vimos são realizadas diretamente no servidor de desenvolvimentos. Essas alterações são relacionadas principalmente nos registros de transporte e nos logs de alterações do sistema. Além disso, são visualizadas em uma tela de comparação entre os ambientes SAP.

8. Rollback automático

No GitHub

Entre as ferramentas de CI, citam-se Azure DevOps, Jenkins, GitLab CI ou GitHub Actions. Elas permitem que você defina etapas de pipeline que são executadas automaticamente em resposta a certos eventos. Você pode configurar seu pipeline de CI para reverter automaticamente as alterações caso haja falhas em testes ou em estágios de implantação.

No SAP/ABAP

E se for necessário realizar um rollback em um ambiente SAP, especialmente em ambientes de produção, geralmente é preferível seguir um processo formal, como criar uma nova request de transporte para reverter as alterações indesejadas. Isso garante que o processo seja documentado, rastreável e submetido às aprovações adequadas.

Comparativo e Limitações

Em quanto em plataformas de desenvolvimento mais sofisticadas, com branchs e pipelines organizadas em repositórios que podem ser copiados e permitem desenvolvimentos distribuídos. No ABAP os desenvolvimentos são centralizados em um servidor de desenvolvimentos e concorrentes. Desta forma no ABAP são poucos os casos em que o Rollback se viabiliza. Na prática é analisar e seguir em frente com os ajustes ai sim seguindo to o compliance e governança exigidos pela SAP.
Nesta hora o QaDevOps apoia na automação e gestão destas práticas liberando os desenvolvedores para atuar nos ajustes e desenvolvimentos necessários.

Conclusão

Como podemos acompanhar ao longo deste artigo as práticas de desenvolvimentos de linguagens de programação como .net, java python entre outras são muito diferentes das práticas disponibilizadas pela SAP na linguagem ABAP. Isto gera grande dificuldade e praticamente impede que as empresas adotem frameworks de trabalhos mais modernos junto com o ABAP.

Como o repositório do ABAP hoje disponibilizado pela SAP é centralizado em um servidor de desenvolvimentos único, este não permite clonagem local do repositório nem desenvolvimentos distribuídos. Sendo assim a adoção do Github como ferramenta global de armazenamentos dos fontes pode causar grandes transtornos aos ambientes SAP por perder o vínculo com o servidor de desenvolvimentos e repositório de fontes também não viabiliza recursos como:

• rollback automático;
• uso de branches para desenvolvimento paralelo;
• e resolução de conflitos. 

Porém, estas limitações do repositório ABAP não nos impediram de aprimorar as práticas de desenvolvimentos ABAP. Através do QaDevOps e

Para aplicar as melhores práticas de desenvolvimento ABAP em seu repositório, oferecemos uma plataforma integrada que automatiza a qualidade, gestão de riscos e o processo de deploy dos seus desenvolvimentos.

Imagine a possibilidade de automatizar todos os fluxos de trabalho durante o ciclo de CI/CD, incluindo deploys automáticos e uma Gestão de Mudanças (Gmud) personalizada. Com nossa plataforma, isso se torna realidade. Diga adeus aos processos manuais e ineficientes e receba uma gestão simplificada e eficaz para seu ecossistema SAP.

Descubra todas as funcionalidades do QaDevOps clicando no link abaixo: https://qametrik.com/produtos/qadevops/