Estratégia de ambientes
Mapa de sandboxes, scratch orgs e UAT alinhado ao ritmo real de trabalho.
CI/CD e DevOps para Salesforce
A release deixa de ser um evento estressante quando tem processo.
Construímos um pipeline de entrega governado para Salesforce: uma única fonte de verdade no Git, ambientes definidos, testes automatizados, portões de qualidade e caminho de rollback — para que cada mudança chegue à produção de forma previsível e documentada.
Pipeline de entrega
Como uma mudança vai do desenvolvimento à produção
O diagrama mostra o pipeline completo, do ambiente onde a mudança é escrita até os controles após a entrada em produção.
Governed Release Pipeline
Origem
Onde a mudança nasce
- Scratch org / sandboxDesenvolvimento isolado
- Metadados no GitFonte única de verdade
- Branch por demandaRastreável ao requisito
Integração
O que roda sozinho
- Pull requestRevisão obrigatória
- Análise estáticaPMD e padrões
- Testes ApexCobertura e qualidade
Portões de qualidade
O que bloqueia a promoção
- Cobertura mínimaLimite acordado
- Suíte de regressãoCenários críticos
- Aprovação do negócioUAT documentada
Release
Como se chega à produção
- Deploy automatizadoMesmo artefato
- Dados de ambienteAmbientes consistentes
- Janela de releasePlanejada e anunciada
Controle
O que acontece depois
- Rollback planejadoCaminho de volta claro
- Monitoramento e alertasLimites definidos
- Notas de versãoDocumentadas por release
Contexto
O que realmente determina o resultado
Na maioria das organizações os incidentes de release não vêm de código ruim, e sim da ausência de processo. As mudanças são feitas direto no ambiente, ninguém sabe exatamente o que foi enviado e não existe uma volta atrás organizada.
CI/CD no Salesforce não é apenas ferramenta. É um acordo sobre o que conta como mudança aprovada, quem aprova, quais verificações precisam passar e o que acontece quando algo falha.
O resultado correto não é mais automação por si só, mas uma cadência maior com menos surpresas — e cada versão explicável, reproduzível e reversível.
Áreas de trabalho
O que fazemos na prática
Metadados no Git
Estrutura de repositório, branches e política de merge sustentável para a equipe.
Pipeline automatizado
Build, testes e deploy com GitHub Actions, Azure DevOps ou Gearset.
Portões de qualidade
Cobertura, análise estática e aprovação do negócio como condição de promoção.
Dados de ambiente
Conjuntos de teste consistentes sem copiar dados sensíveis de produção.
Release e rollback
Janelas de release, notas de versão e caminho de volta definido antes.
Modelo de maturidade
Onde a organização está hoje
A maioria fica entre o nível 1 e o 3. O salto mais significativo é adotar o Git como fonte de verdade.
| Nível | Como se parece | Risco principal | Próximo passo |
|---|---|---|---|
| 1 — Manual | Change sets e edições diretas em produção | Sem registro e sem volta | Levar os metadados para o Git |
| 2 — Parcialmente governado | Git existe, mas o deploy é manual | Divergência entre ambientes | Automatizar o deploy |
| 3 — Automatizado | Um pipeline roda a cada pull request | Testes fracos que aprovam tudo | Definir portões de qualidade reais |
| 4 — Governado | Portões de qualidade bloqueiam a promoção | Releases atrasadas por processo pesado | Focar a suíte de regressão |
| 5 — Contínuo | Releases frequentes com rollback conhecido | Acomodação operacional | Monitoramento e revisões periódicas |
1 — Manual
- Como se parece
- Change sets e edições diretas em produção
- Risco principal
- Sem registro e sem volta
- Próximo passo
- Levar os metadados para o Git
2 — Parcialmente governado
- Como se parece
- Git existe, mas o deploy é manual
- Risco principal
- Divergência entre ambientes
- Próximo passo
- Automatizar o deploy
3 — Automatizado
- Como se parece
- Um pipeline roda a cada pull request
- Risco principal
- Testes fracos que aprovam tudo
- Próximo passo
- Definir portões de qualidade reais
4 — Governado
- Como se parece
- Portões de qualidade bloqueiam a promoção
- Risco principal
- Releases atrasadas por processo pesado
- Próximo passo
- Focar a suíte de regressão
5 — Contínuo
- Como se parece
- Releases frequentes com rollback conhecido
- Risco principal
- Acomodação operacional
- Próximo passo
- Monitoramento e revisões periódicas
Como trabalhamos
Etapas de execução
- 01
Mapeamento da situação
Ambientes, ferramentas, cadência e pontos reais de falha.
- 02
Desenho do pipeline
Branches, ambientes e portões de qualidade adequados à equipe.
- 03
Montagem da infraestrutura
Repositório, automação e primeiras verificações em teste.
- 04
Execução em paralelo
O novo pipeline convive com o processo atual até estabilizar.
- 05
Transição da equipe
Procedimentos, permissões e treinamento por papel.
- 06
Controle contínuo
Medição de cadência, falhas e tempo de recuperação.
Continue a partir daqui
Serviços e guias relacionados
Perguntas frequentes
Perguntas comuns
É preciso uma equipe grande para justificar CI/CD?
Não. Uma equipe de duas ou três pessoas já se beneficia, porque o valor principal é previsibilidade e rastreabilidade, não volume. Uma equipe pequena recebe apenas um pipeline mais simples.
Trabalhamos sobretudo com Flow e configuração. Faz sentido?
Sim. Mudanças de configuração e automação são metadados como qualquer outro e estão entre as causas mais frequentes de incidentes. Geri-las no Git dá visibilidade total.
Quais ferramentas vocês usam?
A escolha depende da organização. GitHub Actions ou Azure DevOps combinam com equipes técnicas; Gearset ou Copado funcionam melhor quando predomina a configuração.
Quanto tempo leva a implantação?
Um pipeline básico entra em operação em poucas semanas. A ampliação para portões completos e regressão é gradual, para não travar o desenvolvimento.
Próximo passo
Estruturar o processo de release
Mapeamos como seus ambientes e releases funcionam hoje e definimos o pipeline adequado ao seu ritmo.
Próximo passo
Estruturar o processo de release
Mapeamos como seus ambientes e releases funcionam hoje e definimos o pipeline adequado ao seu ritmo.