Você monta o Change Set clicando componente por componente, faz upload, espera, e torce para não ter esquecido uma dependência. Meia hora depois descobre que faltou um campo e recomeça. Esse fluxo funciona, mas cobra caro em tempo e em erro humano. O sf CLI resolve o mesmo deploy em segundos, e você não precisa virar desenvolvedor para começar.
Para migrar do Change Set para o sf CLI, cinco comandos bastam: sf org login web conecta a
org, sf project retrieve start baixa metadados, sf project deploy start sobe as
mudanças, sf org list mostra suas conexões e a flag --dry-run simula antes de
gravar. Com eles você já faz tudo o que o Change Set fazia, mais rápido.
Por que sair do Change Set
O Change Set não vai ser desligado, então ninguém está com prazo correndo. O que pesa é produtividade. Ele é manual (você seleciona cada componente na mão), é lento (o upload entre orgs conectadas leva minutos), não guarda histórico do que mudou e não dá para automatizar. Quando o projeto cresce, cada release vira um ritual de clique que ninguém consegue auditar depois. O sf CLI ataca exatamente esses quatro pontos.
Os 5 comandos que já valem a troca
Depois de instalar o CLI, o primeiro passo é conectar a org. Este comando abre o navegador, você faz login normal, e a org fica salva com um apelido:
sf org login web --alias producao --instance-url https://login.salesforce.com
Para trazer metadados da org para a sua máquina, o retrieve equivale a "baixar o Change Set".
Você aponta o que quer por tipo de metadado:
sf project retrieve start --metadata "Flow" "CustomObject:Pedido__c" --target-org producao
Para enviar a mudança para outra org, o deploy é o equivalente ao upload do Change Set, só que
em segundos. Sempre simule antes com --dry-run, que valida tudo sem gravar nada:
sf project deploy start --metadata "Flow:Aprovacao_Pedido" --target-org producao --dry-run
Tirou o --dry-run, ele grava de verdade. Por fim, sf org list mostra todas as
orgs conectadas e qual é a padrão, para você nunca fazer deploy no lugar errado. São cinco comandos, e
quatro deles você usa no mesmo dia.
O que você NÃO precisa aprender ainda
A migração trava quando o admin acha que precisa dominar tudo de uma vez. Não precisa. Deixe para depois:
scratch orgs, o modelo de source tracking, unlocked packages, integração com pipeline de CI e a estrutura
completa do sfdx-project.json. Nada disso é pré-requisito para mover metadados entre orgs.
Comece fazendo pelo CLI os mesmos deploys que você já fazia pelo Change Set. O resto entra quando fizer
sentido, não antes.
Onde o CLI abre portas que o Change Set nunca teve
Assim que os metadados estão em arquivos na sua máquina, coisas novas ficam possíveis. Você pode commitar
esses arquivos num repositório e finalmente ter histórico de quem mudou o quê. Pode revisar uma alteração
antes de subir. E, quando estiver pronto, dá para
versionar até relatórios e dashboards no Git,
algo que o Change Set trata como caixa-preta. Se você escreve queries, o CLI também encurta o ciclo de testar
SOQL dinâmico sem injeção direto do terminal
com sf data query.
O erro que eu já vi travar a primeira migração
Na Vetra Distribuidora, a empresa fictícia que uso como org de demonstração deste portfólio, testei esse
onboarding do zero e o tropeço mais comum apareceu logo: o admin faz o retrieve de um objeto,
mas esquece que o metadado tem dependências. Baixou o objeto, não baixou o Record Type, e o
deploy falha na outra org com uma mensagem de referência quebrada. A lição prática é a mesma
que valia no Change Set, só que agora visível: pense no conjunto de metadados, não na peça solta. A
diferença é que o CLI te mostra o erro em segundos e você corrige a linha do comando, sem remontar nada na
mão. Para os termos que aparecem aqui, o glossário de Salesforce
resolve as definições rápidas.
Perguntas frequentes
Preciso saber programar para usar o sf CLI?
Não. É uma linha de comando de administração, não de programação. Para mover metadados você usa comandos
prontos como sf project deploy start e sf project retrieve start. Não é preciso
escrever Apex nem dominar Git para dar os primeiros passos.
O Change Set vai deixar de funcionar?
Não há data de desligamento anunciada. Ele continua na interface do Setup. Ninguém é obrigado a trocar. O ponto é o limite: Change Set é lento, manual e sem histórico. O CLI faz os mesmos deploys em segundos e permite versionar o que mudou.
Qual a diferença entre sfdx e sf CLI?
O sf é a versão atual, que substituiu o antigo sfdx. Os comandos ficaram mais
curtos, de sfdx force:source:deploy para sf project deploy start. Tutoriais com
sfdx ainda funcionam, mas prefira aprender pelos comandos novos.
É seguro fazer deploy direto em produção pelo sf CLI?
É, desde que você valide antes. O deploy start aceita --dry-run, que simula sem
gravar, e você escolhe a org de destino explicitamente. O risco não é maior que o do Change Set, e o
controle é bem maior.