Antigamente, com o Protheus, tínhamos um processo manual de troca de RPO (Repositório de Objetos).
Com o tempo, começaram a surgir arquivos .bat, .java, e assim por diante, que começaram a automatizar essa troca no RPO (Repositório de Objetos).
Mais tarde, quando finalmente desenvolvemos um script em PowerShell (disponível em https://github.com/charlesreitz/managerRPO), entramos na fase de testes e automatização. Durante esse período, integramos nosso script ao Jenkins e ao Git (Gitea), garantindo que o projeto estivesse completamente sincronizado com o ambiente de produção.
Sim, é verdade! Costumamos implantar programas diretamente no ambiente de produção, sem um processo de testes formal com CI/CD, mas passando por vários testes e analises dos usuários. No entanto, esse cenário é bastante específico, pois o ERP com o qual trabalhamos é altamente customizável e requer atualizações frequentes.
O cliente com o qual implementamos esse sistema possui uma equipe experiente, que faz entregas diárias no ambiente de produção. Isso se deve ao fato de muitas regras de negócio da empresa estarem diretamente ligadas ao repositório do cliente, tornando essas entregas bastante comuns.
Você pode se perguntar se isso é arriscado, e a resposta é sim, é arriscado. No entanto, devido ao amplo conhecimento da equipe em relação ao processo, o risco é consideravelmente reduzido.
Mas e se a equipe for substituída? A empresa ficaria em apuros? É possível que o ambiente se torne instável, pois todo o conhecimento sobre o sistema está nas mãos das pessoas. Isso está errado? ...
Eu sou um defensor dos testes automatizados, mas acredito que, em uma equipe enxuta focada em entregas, suporte e melhorias, seja difícil implementar um processo rigoroso de testes automatizados. No entanto, é importante equilibrar a agilidade com a segurança e considerar opções para mitigar os riscos em caso de mudanças na equipe.
