Gostaria de acrescentar uma perspectiva de desenvolvedor a essa discussão.
Ao longo dos últimos anos trabalhando com Genesys Cloud, já tive a oportunidade de atuar individualmente e com diferentes equipes, tanto em projetos prioritários quanto em múltiplos projetos executados em paralelo.
O único cenário com o qual ainda não trabalhei diretamente foi uma esteira totalmente automatizada de CI/CD. Mesmo assim, em todas as experiências que tive, o fator mais importante para uma implantação segura sempre foi possuir uma documentação clara, detalhada e previamente validada pelo time.
Essa documentação pode assumir diferentes formatos, dependendo do projeto, como:
- Documento de visão e requisitos.
- Diagramas no Miro ou Draw.io.
- Protótipos no Figma.
- Especificações funcionais e técnicas.
- Inventário das configurações e dependências.
- Plano de implantação e rollback.
- Evidências e cenários de teste.
Quando existem ferramentas capazes de promover fluxos e configurações automaticamente entre organizações, o uso de ambientes separados de desenvolvimento, homologação e produção oferece ganhos evidentes de governança e segurança.
Por outro lado, quando essas ferramentas não estão disponíveis, manter uma organização exclusiva para desenvolvimento ainda traz benefícios, mas pode reduzir significativamente a velocidade de implantação. Nesse cenário, muitas configurações precisam ser recriadas, ajustadas ou validadas manualmente na organização de destino.
Já trabalhei com planos detalhados de troca de fluxos nos roteamentos, tanto para executar pessoalmente uma mudança e seu possível rollback quanto para permitir que outro desenvolvedor conduzisse a implantação.
Para mim, um bom plano de mudança precisa permitir que outra pessoa consiga:
- Entender o estado atual da produção.
- Identificar exatamente o que será alterado.
- Executar as etapas na ordem correta.
- Validar o resultado após a implantação.
- Retornar ao estado anterior caso algo falhe.
Uma das principais lições que aprendi trabalhando com Genesys Cloud é que devemos sempre manter documentados tanto o estado atual da produção quanto as alterações propostas.
Também considero essencial possuir uma cobertura de testes elevada. Os testes não devem validar apenas a nova funcionalidade, mas também incluir cenários regressivos para garantir que jornadas, roteamentos e integrações já existentes não tenham sido afetados.
Na minha experiência, ferramentas e automação aceleram bastante o processo, mas documentação, revisão e testes continuam sendo a base para reduzir riscos durante a promoção de mudanças entre ambientes.
________________________________________________________________________________
I would like to add a developer's perspective to this discussion.
Over the past few years working with Genesys Cloud, I have had the opportunity to work independently and with different teams, both on high-priority projects and on multiple projects running in parallel.
The only scenario I have not yet worked with directly is a fully automated CI/CD pipeline. Even so, in all my previous experiences, the most important factor for a safe deployment has always been having clear, detailed documentation that was reviewed and validated by the team.
Depending on the project, this documentation may include:
- Vision and requirements documents.
- Miro or Draw.io diagrams.
- Figma prototypes.
- Functional and technical specifications.
- Configuration and dependency inventories.
- Deployment and rollback plans.
- Test scenarios and evidence.
When tools are available to automatically promote flows and configurations between organizations, using separate development, non-production, and production environments provides clear governance and risk-reduction benefits.
However, when these tools are not available, having a dedicated development organization still provides value, but it can significantly reduce deployment speed. In that situation, many configurations must be manually recreated, adjusted, or validated in the destination organization.
I have worked with detailed plans for switching flows within routing configurations, both when I was responsible for executing the change and potential rollback, and when another developer needed to perform the deployment.
In my opinion, a good change plan should allow another developer to:
- Understand the current production state.
- Identify exactly what will change.
- Execute the steps in the correct order.
- Validate the result after deployment.
- Restore the previous state if something goes wrong.
One of the most important lessons I have learned while working with Genesys Cloud is that both the current production configuration and the proposed changes should always be documented.
I also believe that high test coverage is essential. Testing should not only validate the new functionality but should also include regression scenarios to ensure that existing journeys, routing behaviors, and integrations have not been affected.
In my experience, tools and automation can greatly accelerate the process, but documentation, peer review, and testing remain the foundation for reducing risk when promoting changes between environments.
------------------------------
Matheus Mendonca
------------------------------