Integração contínua
continua aparecendo de vez em quando, e já existem alguns excelentes
blogs
sobre o tema. A SAP também fornece uma ótima visão geral em
O que é Integração Contínua e Entrega Contínua?
, descreve a IC como:
A integração contínua (IC)
descreve um processo de desenvolvimento de software, no qual vários membros da equipe integram suas contribuições com frequência em uma única linha principal. Antes de cada integração, as mudanças são verificadas por meio de compilações e testes automatizados. Dessa forma, é possível detectar erros o mais rápido possível e prevenir problemas de integração antes de concluir o desenvolvimento.
Basicamente, a IC ajuda o desenvolvedor a verificar o desenvolvimento
antes
de concluí-lo.
Paisagem
Em uma paisagem SAP típica, os desenvolvedores fazem alterações no DEV e
depois
que o desenvolvimento é concluído, as alterações são movidas para o QAS para testes e, se bem-sucedidas, as alterações são movidas para o PRD.
Os desenvolvedores dependem de um sistema DEV operacional para realizar desenvolvimentos, e o QAS também deve funcionar para verificar o desenvolvimento, o que geralmente envolve etapas manuais.
No recente TechEd, a SAP sugeriu recentemente o seguinte para uma configuração de IC,
DEV208
Onde o sistema QA é usado para realizar os testes de IC, isso corresponde ao "Cenário 2" em
Suporte completo à IC em ABAP AS
Os desenvolvedores
Fazem Commit cedo e frequentemente
, e
cada alteração será compilada
, acionando a IC, o que significa:
-
O sistema QA mudará continuamente e os objetos possivelmente serão revertidos. No ABAP, as reversões não são 100% confiáveis, por exemplo, um teste unitário pode ter modificado o estado do sistema, deixando assim o sistema QA em um estado desconhecido.
-
A IC é acionada
antes
que os desenvolvimentos sejam concluídos, possivelmente movendo código com defeito para o QA, que não passou por nenhum controle de qualidade.
-
Os testes manuais no QA serão nulos, uma vez que o estado do sistema muda continuamente. No entanto, isso pode funcionar em um processo em cascata, se todos os testes forem realizados após todo o desenvolvimento, mas vai em direção oposta à Implementação Contínua.
Em geral, isso resulta em um processo automatizado
prejudicial
para quebrar o sistema QAS, em vez de evitar erros por meio da automação e ajudar os desenvolvedores.
Ter resultados de teste nulos pode ser o compromisso certo para algumas organizações, mas também existem
várias alternativas
, como adicionar um sistema adicional para lidar com a IC.
Pessoalmente, estou avançando para uma configuração (
Cenário 9
), onde a
análise estática
e os
testes unitários